"SQLite: MQL5'te SQL veritabanlarıyla yerel olarak çalışma" makalesi için tartışma - sayfa 7

 
Renat Fatkhullin:

Yarın betada 2840 olacak:

  • SQLite 2.35.2 sürümü

  • Farklı uygulamalardan açık bir veritabanı ile çalışmaya izin veren kalıcı WAL modu (daha önce MetaEditor terminal ile paralel çalışamıyordu).

Çok mutluyum, teşekkürler
 
Edgar Akhmadeev:
Çok mutluyum, teşekkür ederim

Beta 2840 mevcuttur, lütfen deneyin.

 
Renat Fatkhullin:

Yarın betada 2840 olacak:

  • SQLite 2.35.2 sürümü

  • Farklı uygulamalardan açık bir veritabanı ile çalışmaya izin veren kalıcı WAL modu (daha önce MetaEditor terminal ile paralel çalışamıyordu)

  • istatistiksel fonksiyonların genişletilmesi
    örnek:
  • yeni̇ matemati̇k fon ksi̇yonlari
  • JSON desteği de dahil edilmiştir

    Yeni json türünü daha sonra veritabanı oluşturma sihirbazına dahil edeceğiz.



Renat, çok teşekkür ederim!!!
Bu kadar hızlı beklemiyordum, çok memnun oldum))))))
 
fxsaber:

Bunu kim çözdü, lütfen böyle bir görevin uygulamasını gösterin.

  1. İki Terminal vardır.
  2. Bir sembolün gerçek zamanlı kotasyonlarını Terminal1'den Terminal2'nin ilgili özel sembolüne aktarmak gerekir.
fxsaber:

Bu görev çerçevesinde, her iki durumda da (Terminal2'deki tabanı okurken ve Terminal1'deki tabana yazarken) işlem mekanizması aracılığıyla engellenmesi gerektiğini doğru anlıyor muyum?

Veritabanının güncellendiğini belirlemenin en ucuz yolu nedir?

Temelde yanlış. Siz 1 yazar, n okuyucu şemasına sahip dağıtık bir istemci-sunucu uygulamasını tarif ediyorsunuz. Bu tür sistemleri (ve genel olarak herhangi bir dağıtık sistemi) tasarlarken, veri organizasyonu ve bunlara erişim için kilitsiz yollar kullanarak kilitlerden kaçınmaya çalışmalısınız. Kullanılan teknoloji kilitleme olmadan yapmanıza izin vermiyorsa, o zaman belki de göreviniz için en iyi çözüm değildir. Ancak, diğer görevler için teknoloji harika olabilir.
Sizin durumunuzda, tam teşekküllü bir sunucu kurmak (bunu istemciyle aynı makinede yapabilirsiniz) ve mesaj kuyruğuna alıntılar yazmak, örneğin Kafka'ya bakmak daha iyidir. İstemci bu alıntıları gerekli dizinden okuyacaktır. Bu, kilitsiz bir veri erişim şemasıdır.

fxsaber:

Yani veri alışverişinin dosyalar aracılığıyla olandan daha az olasılığı olduğu ortaya çıkıyor?

Kategorik olarak hayır. Dosyalar aracılığıyla paylaşım hiç de atomik değildir, bu nedenle hem okuyucu hem de yazar tarafında kilit gerektirir. Bu, çıkmaza girmenin ve bulunması zor ve anlaşılmaz hataları yakalamak için kaybolmanın en kesin yoludur.

 
Vasiliy Sokolov:

Temelde yanlış. Siz 1 yazar, n okuyucu şemasına sahip dağıtık bir istemci-sunucu uygulamasını tarif ediyorsunuz. Bu tür sistemleri (ve genel olarak herhangi bir dağıtık sistemi) tasarlarken, veri organizasyonu ve bunlara erişim için kilitsiz yollar kullanarak kilitlerden kaçınmaya çalışmalısınız. Kullanılan teknoloji kilitleme olmadan yapmanıza izin vermiyorsa, o zaman belki de göreviniz için en iyi çözüm değildir. Ancak, diğer görevler için teknoloji harika olabilir.
Sizin durumunuzda, tam teşekküllü bir sunucu kurmak (bunu istemciyle aynı makinede yapabilirsiniz) ve mesaj kuyruğuna alıntılar yazmak, örneğin Kafka'ya bakmak daha iyidir. İstemci bu alıntıları gerekli dizinden okuyacaktır. Bu, kilitsiz bir veri erişim şemasıdır.

Kategorik olarak hayır. Dosyalar aracılığıyla paylaşım hiçbir şekilde atomik değildir, bu nedenle hem okuyucu hem de yazar tarafında kilitler gerektirir. Bu, bir çıkmaza girmenin ve görülmesi zor ve anlaşılmaz hataları yakalamakta kaybolmanın en kesin yoludur.

Bu kadar detaylı bir yanıt için teşekkürler! Ne yazık ki, o sırada hangi sorunu çözdüğümü tamamen unutmuşum. Bu yüzden konuyla ilgili düşüncelerimi paylaşamıyorum.

 
Renat Fatkhullin:

Beta 2840 kullanılabilir, lütfen deneyin.

Renat, günaydın!

StringFormat'ta da bir sorun fark ettim, içine oldukça büyük bir girdi veri dizesi yerleştirildiğinde, örneğin 3-4 deyim içeren bir kaynak dosyasından, örneğin %d, %s, %lld, %s, birkaç ikame varyantını kontrol ettim, sadece 4003 hatasıyla sonuçlanan büyük miktarda girdi verisi meselesi.

Projelerde geçici olarak StringReplace işlevine geçtim, giriş dizesindeki büyük verilerle doğru şekilde çalışıyor.
 
Öğrendim, paylaştığınız için teşekkürler.
 
DataBasePrepare dosyasında bazı hatalar var. "Çift "i dize ile değiştireceğim, bu doğru mu?
 

Bu çözümle ilgili sorular

- Aynı sqlite veritabanını eşzamanlı olarak kullanan birden fazla EA ile ilgili herhangi bir sorun var mı?

- MT5 çökerse, bazı veriler kaybolabilir mi? Diske ne sıklıkla veri yazıyor?

 

İyi günler, sevgili geliştiriciler!

"DatabaseExport" fonksiyonu hiçbir şekilde çalışmak istemiyor...parametrelerde tablo adını belirttiğimde 5601 hatası veriyor (sorgu yürütme hatası, ancak sorguyu yürütmüyorum),

ve SQL sorgusu belirttiğimde, 4022 hatası veriyor ( program yürütme iptali), muhtemelen MQL işlevi içinde hata, kütüphanemdeki kodun bir parçası:


//+------------------------------------------------------------------+
void CSQLite::DataBaseToFile(void)
  {
   uint flags=DATABASE_EXPORT_COMMON_FOLDER | DATABASE_EXPORT_QUOTED_STRINGS;

   long count_rows=0;

   string tables[],
          file_name,
          separator=";",
          query="SELECT name FROM sqlite_master WHERE tbl_name <> 'sqlite_sequence' AND type='table'";

   int total=GetValuesFromDataBase(query,tables); // ТУТ ВСЕ ОК, СПИСОК ТАБЛИЦ ИЗ БАЗЫ ПОЛУЧЕН.

   if(m_handle==NULL)
      Open();

   for(int i=0; i<total; i++)
     {
      file_name=StringFormat("%s.%s",m_name,tables[i]);
      count_rows=DatabaseExport(m_handle,tables[i],file_name,flags,separator); // ОШИБКА ПОСЛЕ ВЫПОЛНЕНИЯ ДАННОЙ ФУНКЦИИ
      Print(StringFormat("Export file: %s, rows: %lld",file_name,count_rows));

      if(count_rows<0)
         Print("DB: ", m_name,", Table: ",tables[i], ", Import failed with code ", GetLastError());
      else
         if(count_rows>0)
            Print(StringFormat("Import file: %s, rows: %lld",file_name,count_rows));
     }

   Finalize();
  }
//+------------------------------------------------------------------+