Support Board
Date/Time: Tue, 10 Nov 2026 12:09:56 +0000
Post From: DTC paper-only attestation and service-change command binding (2980)
| [2026-11-10 08:10:11] |
| User526199 - Posts: 1 |
|
We are evaluating a local DTC integration with a dedicated Trading Evaluator installation (Sierra Chart 2980 / build 58935, DTC 8). Discovery is strictly read-only; no order, cancel or replace has been submitted. 1. Is there a supported machine-readable way to prove that an exact trade account belongs to the server-side Trading Evaluator? Do ServiceCodeForSelectedDataTradingService and GetTradeAccountData provide that proof, and what precisely does m_IsSimulated mean for Evaluator accounts versus internal Sim accounts and live services? 2. On a service/account/simulation change or reconnect, does Sierra invalidate existing local DTC authority before any command can use the new destination? Please include commands already received or queued for upstream dispatch: can they ever be retargeted, or are they permanently bound/rejected? Does the guarantee cover submit, held OCO children, modify and cancel, and which versions? How are origin account/service/order IDs checked after reconnect or ID reuse; can an unavailable explicit account fall back to another account? 3. If the local DTC interface does not provide this guarantee, is there a supported atomic service/account check-and-dispatch mechanism in ACSIL or a server-enforced paper-only/session-bound facility? Main-thread study execution alone does not specify queued-command behavior. We are asking for the supported contract, not permission to test live routing. 4. Is there a public monotonic service/connection generation or synchronous pre-change hook, including change-away-and-back? How can an ACSIL observer prove trading-session readiness and current-session account-data freshness, rather than only market-data connectivity or cached values? |