Un file .sqlite può essere incluso nella struttura del progetto ME? per il successivo confezionamento in .ex5
Se sì, come si comporta il programma .ex5 quando la dimensione del file.sqlite aumenta? in un programma .ex5 già compilato
Grazie per la nuova funzionalità.
Considero il buon aiuto sulla nuova funzionalità come la chiave del successo nel padroneggiarla. Mi mancano davvero gli esempi di lavoro nell'aiuto stesso.
Si prega di prestare attenzione anche alle seguenti carenze che ho trovato:
1) La descrizione della funzione DatabaseExecute non è vera, ma copiata daDatabasePrepare.
2) Descrizione incompleta del primo parametro della funzioneDatabaseRead:intdatabase,// handle del database ottenuto in DatabaseOpen;
PoichéDatabasePrepare fornisce informazioni più complete:Crea un handle di query, che può poi essere eseguito con DatabaseRead().
3) Le funzioniDatabaseTransactionXXX generano davvero le liste di errore GetLastError() date o eseguono un "errore di follow-up da un fallimento precedente"?
4) Non vengono fornite informazioni per le funzioni DatabaseTransactionXXX sulla gestione delle transazioni annidate.
5) C'è un refuso nella descrizione del parametro della funzioneDatabaseColumnName(deve essere "per ottenere il nome del campo")
string&name// riferimento alla variabile per ottenere il nome dellatabella
Grande notizia, Renat! È sorta una domanda.
Un file .sqlite può essere incluso nella struttura del progetto ME?
Se è così, come si comporta il programma .ex5 quando la dimensione del file .sqlite aumenta? in un programma .ex5 già compilato
Molto probabilmente permetteremo l'inclusione di risorse e questi file saranno automaticamente estratti sul disco al primo avvio del programma.
Cioè, non ci sarà alcun rigonfiamento della base all'interno di ex5. Il file può essere gestito solo su disco.
Le basi possono essere tenute sia su disco che solo in memoria, usando il flag DATABASE_OPEN_MEMORY.
Ho ragione di capire che questo è un meccanismo ufficiale di scambio di dati tra i terminali MT5 (invece di uccidere i file SSD) e tra i programmi all'interno del terminale (invece di risorse)?
Grazie per la nuova funzionalità.
Penso che un buon aiuto per la nuova funzionalità sia la chiave del successo per padroneggiarla. Mi mancano davvero gli esempi di come lavorare nell'aiuto stesso.
Si prega di prestare attenzione anche alle seguenti carenze che ho trovato:
1) La descrizione della funzione DatabaseExecute non è vera, ma copiata da DatabasePrepare.
2) Descrizione incompleta del primo parametro della funzioneDatabaseRead:intdatabase, // handle del database ottenuto in DatabaseOpen;
Poiché DatabasePrepare fornisce informazioni più complete: s crea un handle di query, che può poi essere eseguito con DatabaseRead().
3) Le funzioniDatabaseTransactionXXX generano davvero gli elenchi di errori dati GetLastError() o eseguono un "errore di follow-up da un fallimento precedente"?
4) Non vengono fornite informazioni per le funzioni DatabaseTransactionXXX sulla gestione delle transazioni annidate.
5) C'è un refuso nella descrizione del parametro della funzione DatabaseColumnName (deve essere "per ottenere il nome del campo")
string&name// riferimento alla variabile per ottenere il nome dellatabella
L'aiuto è già stato parzialmente aggiornato, date un'altra occhiata. Questa è ancora la prima versione dell'aiuto e sarà aggiornata.
Non ci sono transazioni annidate in SQLite, quindi non c'è bisogno di provare a farle.
Gli esempi sono presentati nel topic, non c'è niente di complicato. Più tardi faremo un articolo e una classe wrapper nella libreria standard.
Ho capito bene che questo è un meccanismo ufficiale di scambio di dati tra i terminali MT5 (invece di file che uccidono SSD) e tra i programmi all'interno del terminale (invece di risorse)?
Smettete di diffondere palesi sciocchezze su "uccidere gli SSD" da parte di utenti incompetenti.
No, queste sono basi di file - possono essere scambiate, ma è rischioso accedervi simultaneamente da diversi esperti a causa dell'accesso potenzialmente monopolistico quando le basi sono aperte allo stesso tempo.
I database aperti "in-memory-only by DATABASE_OPEN_MEMORY flag" sono disponibili solo per un programma specifico e non sono condivisi con nessuno.
Applicazioni di database:
- Memorizzazione delle impostazioni e degli stati dei programmi MQL5
- Archiviazione di massa dei dati
- Utilizzando i dati preparati esternamente
. Per esempio, esportando i dati da Metatrader in SQLite, in Python ha calcolato questi dati utilizzando pacchetti matematici pronti all'uso e ha messo il risultato anche in formato SQlite.
L'editor di database in ME sarà, beh, molto utile, grazie.
No, queste sono basi di file - possono essere scambiate, ma è rischioso accedervi simultaneamente da diversi EA a causa dell'accesso potenzialmente monopolistico quando le basi sono aperte allo stesso tempo.
Python ha una libreria chiamataSqlite3Worker, per un I/O thread-safe quando si lavora con un database da più thread.
Forse ha senso pensare al porting dell'implementazione su mql, per permettere un lavoro asincrono con il database di più Expert Advisors.
Bene, o prendere in prestito l'idea e implementare il proprio I/O asincrono.

Python ha la libreriaSqlite3Worker, per un input/output thread-safe, quando si lavora con il database da più thread.
Forse c'è un punto per considerare l'implementazione del porting a mql, per consentire il lavoro asincrono con il database di più Expert Advisors.
Bene, o prendere in prestito l'idea e implementare il proprio I/O asincrono.
Avete visto la tabella delle prestazioni qui sopra? Spesso è più veloce in MQL5 che in C++.
Abbiamo il multithreading, naturalmente, e tutto è corretto.
La domanda riguarda qualcos'altro - cosa succede se diversi programmi/processi accedono indipendentemente allo stesso file di database. Non un singolo programma (MQL5), ma diversi programmi indipendenti che non sanno l'uno dell'altro e non usano lo stesso handle di database.

- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
Nella build 2265 abbiamo implementato le normali funzioni di database basate su SQLite 3.30.1:
Dato che siamo concentrati al massimo sulle prestazioni, ecco i risultati dei test LLVM 9.0.0 vs MQL5. Tempo in millisecondi, meno è meglio è:I database possono essere tenuti sia su disco che in memoria solo con il flag DATABASE_OPEN_MEMORY. Avvolgere inserti/modifiche massicci in transazioni DatabaseTransactionBegin/Commit/Rollback velocizza le operazioni di centinaia di volte.
La velocità in MQL5 è assolutamente la stessa del C++ nativo con uno dei migliori compilatori. Una suite di benchmark per il replay è allegata.
Abbiamo anche implementato una funzione unica DatabaseReadBind che permette di leggere i record direttamente nella struttura, il che semplifica e velocizza le operazioni di massa.
Ecco un semplice esempio: