OnTicaretİşlem - sayfa 7

 
fxsaber :

Kabul ediyorum. Ancak ne yazık ki MT5'te, MT4'ün aksine ticaret ortamı gerçeğe uygun olmayabilir. Örneğin, bekleyen bir emir birkaç milisaniye için yürütüldüğünde, hiçbir yerde olmayabilir. Ve OnTradeTransaction bile burada yardımcı olmaz.

Belki OnTrade, anladığım kadarıyla, zaten işlemler bazında terminalin kendisinde üretilir.

Yoksa OnTrade işleyicisinde gecikme tetiklendiğinde yeni bir açık pozisyon tespit etmemenin mümkün olduğunu mu söylemek istiyorsunuz?

 
Aleksey Mavrin :

Belki OnTrade, anladığım kadarıyla, zaten işlemler bazında terminalin kendisinde üretilir.

Yoksa OnTrade işleyicisinde gecikme tetiklendiğinde yeni bir açık pozisyon tespit etmemenin mümkün olduğunu mu söylemek istiyorsunuz?

Herhangi bir Açık işlevinde. Bu anlamda MT5 bir deliktir. Yama yapmaları pek olası değil.

 
fxsaber :

Herhangi bir Açık işlevinde. Bu anlamda MT5 bir deliktir. Yama yapmaları pek olası değil.

Eğer öyleyse, bu üzücü. OnTrade'in anlamı pratik olarak kaybolur. Kontrol etmek zorunda kalacak. İdeal olarak, bekleyen tetiklendiğinde, OnTrade yaklaşık olarak kaç kez çağrılmalıdır:

duraklar için:

- bir piyasa emri yarattı ve gönderdi

- bekleyen sipariş tarihe taşındı

- sipariş tamamlandı anlaşma kaydedildi

- piyasa emri tarihe geçti

- pozisyon oluşturuldu

sınırlayıcılar için:

- limit etkinleştirilir, işlem kaydedilir

- bekleyen sipariş tarihe taşındı

- pozisyon oluşturuldu

Öncekilerin değil de sonuncunun zaten bir konumu olması gerektiğini varsayarsak, olmaması mantıklı, değil mi?

OnTrade'de, tüm ticaret durumlarını - anlaşmaları, pozisyonları, emirleri - kontrol etmek için işlevleri çağırdım. Şu ana kadar her şey yolunda görünüyor, ancak çok karmaşık ticaret işlemlerim olmadı.

 
fxsaber :

oh-yo, neden foruma girdim, çözülmemiş o kadar çok sorun var ki))

Teşekkürler, bir bakacağım. Vurgulananı okurken, bence bu bir sorun değil, bir özellik. Veritabanlarında ve aslında, işlem kavramı TÜMÜ anlamına gelir.

sorguyu yürütmek VE DOĞRU DB'Yİ BAKIMI için gerekli işlemler tamamlanmıştır ve işlemden sonra veritabanı ile çalışabilirsiniz, herhangi bir hata olmayacaktır.

Eylemlerden herhangi biri varsa (ve hatta herhangi bir tabloya satır yazmak için de birden fazla yapılması ve öncekilerin başarıyla tamamlandığından emin olunması gerekir)

başarısız olursa, değişiklikler geri alınır ve işlem başarısız olur. Neden ben, muhtemelen MT'den bir DBMS seviyesi beklememeniz gerektiği gerçeğine :)

Burada, tüm ara işlemlere bakılmalı ve kontrol edilmelidir, yine bir yerde bu daha fazla esneklik sağlar.

Ama bence, her şey mantıklı - sunucu önce emrin yerine getirildiğini bildirir, terminal onu arşive siler, ardından (daha sonra) sunucu bir pozisyon açtığını veya bir hata nedeniyle açılmadığını bildirir. , o zaman sıfır-sıfır olmalıdır.

Kontrol edeceğim ve sonuçlar hakkında daha fazla yazacağım.

 
Aleksey Mavrin :

Ama bence, her şey mantıklı - sunucu önce emrin yerine getirildiğini bildirir, terminal onu arşive siler, sonra (daha sonra) sunucu bir pozisyon açtığını bildirir

Tarihte ve şimdikiler arasında bir düzen yoktur. Ve pozisyon yok. Yani, hiçbir şey yok.

 
Aleksey Mavrin :

Ama bence, her şey mantıklı - sunucu önce emrin yerine getirildiğini bildirir, terminal onu arşive siler, ardından (daha sonra) sunucu bir pozisyon açtığını veya bir hata nedeniyle açılmadığını bildirir. , o zaman sıfır-sıfır olmalıdır.

Bu forumda veya başka bir yerde admin Renat'ın (belki de Hızlı forum) yazılarını okuduğumu söylemeyeceğim, ancak siparişin sunucuda geçtiğine dair tek kontrolün marj gereksinimlerini sağlamak olduğunu yazmış gibi görünüyor. emir, bağlayıcı aracılığıyla borsaya “uçar”, daha sonra emir yürütme belirsizliği olan durum, prensipte mümkündür, sunucu emrin hangi fiyatta yürütüldüğünü bilmiyor

 
fxsaber'ın verdiği örneğe ek olarak, pratikte hem gecikmeler arasında hem de açık pozisyonlar arasında bir biletin olduğu bir durum daha var. durum birkaç milisaniye boyunca da devam ediyor (ancak son sürümlerde kontrol etmedim). doğrulama mekanizması farklı olmalı, önceden hazırlanın :)
 
Igor Zakharov :
fxsaber'ın verdiği örneğe ek olarak, pratikte hem gecikmeler arasında hem de açık pozisyonlar arasında bir biletin olduğu bir durum daha var. durum birkaç milisaniye için de devam ediyor (ancak son sürümlerde kontrol etmedim). doğrulama mekanizması farklı olmalı, önceden hazırlanın :)

Bu durumu MT4 danışmanları için her şeyin MT4'teki gibi MT5'te kalacak şekilde ele alıyorum. Ancak hayali siparişlerle - eklemeniz gerekir.

 

"normal" robotlarda, tarif ettiğim durumu hiç fark etmedim; ama bir tanesinde bir güvenlik sistemi yapmam istendi: koşul, pozisyonların her zaman kilitli olmasıydı (gerçek pozisyonlar veya bekleyen bir emir ), yani. Alınacak lot sayısı satılacak lot sayısına eşittir. Bu vaka beni ilk beşte siparişleri / pozisyonları / anlaşmaları saymanın nüanslarıyla tanıştırdı.

fark, kendime açıkladığım gibi, :), aracıdan bir yanıt alan dördü, önce "tablolarını" açık siparişler ve geçmişle senkronize eder ve ardından kullanıcıyı aracının yanıtı hakkında bilgilendirir. beşi hemen bu cevabı bize yayınlar ve paralel olarak "tablolarını" düzenler (ve tüm mql programları bu "tablolardan" verileri okur). Milisaniye zamanlayıcısını yakaladığımız an bu andır. Ama o zaman, neden bununla test cihazında karşılaşmıyoruz?

Sonuçta, anlaştım...

Neden: