A trade-management script cannot protect a position it has identified incorrectly. In MetaTrader 4, OrderSelect() determines which order’s properties subsequent MQL4 calls read. Selecting by ticket differs from selecting by position in the order pool, and a successful selection does not establish that the order belongs to the strategy running the script.
For mt4 trading, these distinctions become consequential when several CFDs share an account, orders close while a loop is running, or a broker updates a position. Five selection errors can quietly change which exposure receives a stop, reduction, or exit.
Pool Position Numbers Can Shift During a Closing Loop
SELECT_BY_POS addresses an order’s current position in the selected pool, not a permanent identity. When a script closes an order, the pool shrinks and remaining positions may be renumbered. A loop that increments forward can skip a position after removing the preceding one. The order in which positions are returned is not guaranteed to follow opening time or ticket number.
A reverse loop reduces some removal-related errors, but a safer design records eligible tickets first and verifies each one again before acting. Check the current pool size and whether the routine changes the pool it is traversing.
Missing Symbol and Magic-Number Filters Can Touch Another Strategy
Selecting an order successfully says nothing about who owns it. A generic trailing-stop script that examines every open order can modify a manually placed CFD or a position managed by another Expert Advisor. During volatile trading, one strategy’s protective level may be replaced by another’s assumptions about acceptable loss.
Filter by OrderSymbol(), OrderMagicNumber(), and order type, with explicit rules for manual positions that commonly use magic number zero. Review those conditions whenever scripts are reused across charts.
A Stale Selection Can Apply the Wrong Risk Calculation
MQL4 copies order details into the program environment when OrderSelect() succeeds. Those values do not automatically refresh each time the broker changes the order. Imagine a hypothetical short European bank-share CFD of 600 shares entered at €27.50. A separate process closes 400 shares, leaving 200, while a management script still uses the previously selected volume of 600.
If the script calculates a €0.80 adverse-move risk using the stale quantity, it reports €480 instead of the remaining position’s €160. An automatic hedge sized against that estimate could introduce €320 of excess notional price-move sensitivity. Partial-close ticket behavior can also vary, so reselect the current live order and confirm its volume before calculating an offset.
Mixing Trade and History Pools Can Misclassify Closed Orders
MODE_TRADES contains open market orders and pending orders, while MODE_HISTORY contains closed and canceled records available in the terminal’s loaded account history. A routine searching only the live pool may interpret a missing ticket as an execution failure, even though the trade closed normally. Conversely, selecting an old history record can supply an obsolete price to a new decision.
For mt4 trading scripts that reconstruct realized results, inspect OrderCloseTime() and the relevant pool rather than inferring status from a failed live lookup. History availability also depends on the account history loaded in the terminal.
Failed Selection Can Leave Old Order Data in Use
A call to OrderSelect() can fail because a ticket no longer exists in the expected pool or the order list has changed. If the code ignores the Boolean result, subsequent property reads may reflect previously copied data instead of the intended order. More logging alone will not fix a routine that continues after selection failure.
Before opening a CFD position under automated management, run a demo test with multiple symbols, a partial close, and a canceled pending order. Confirm that every modification first selects a live ticket successfully and verifies symbol, magic number, type, and current volume.
