Discussion of article "How to Access the MySQL Database from MQL5 (MQL4)" - page 12
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
There are a lot of third-party GUIs/IDEs for it - and sqlite itself is just a pure database engine and API for embedding it in applications...
API is really for everything, including NET. I'll look for GUI - you might like it).
https://www.mql5.com/en/articles/862
Thanks, read it. There's a very good point there by the author of the current article, who came along,..... and spoilt everything).
The possibility of using it is there and that's good. Another thing is that SQLite should not be used for serious projects. In any case, I would not recommend it. I myself have faced the problem of collisions on it more than once. For example, if a trading robot is attached to different charts, but uses the same base, and the access is to one general-purpose table (say registration/change sessions, accounts), then in any case you will get an error like "table locked". And it doesn't matter that all transactions are completed, cursors are closed and the database was opened in shared mode. This problem is known to SQLite developers as well.
In my opinion, MS Access is the best of file databases with SQL support. No matter how much you scold the small-soft people, but I left SQLite for MS Access and I don't regret it at all. OleDB driver Jet 4.0 is installed even with Win98, so that projects work on all OC Windows.
I have already written earlier that Access is probably really the best, which is what I use. In extreme case MS SQL Server, especially now there is a freely distributed version. And MySQL is too bulky, only the server distribution ~450 MB
Thanks, I read it. There's a very good point there by the author of the current article, who came in,..... and ruined everything).
The possibility of using it is there and that's good. Another thing is that SQLite should not be used for serious projects. In any case, I would not recommend it. I myself have faced the problem of collisions on it more than once. For example, if a trading robot is attached to different charts, but uses the same base, and the access is to one general-purpose table (say registration/change sessions, accounts), then in any case you will get an error like "table locked". And it doesn't matter that all transactions are completed, cursors are closed and the database was opened in shared mode. This problem is known to SQLite developers as well.
In my opinion, MS Access is the best of file databases with SQL support. No matter how much you scold the small-soft people, but I left SQLite for MS Access and I don't regret it at all. OleDB driver Jet 4.0 is installed even with Win98, so that projects work on all OC Windows.
I have already written earlier that Access is probably really the best. In extreme case MS SQL Server, especially now there is a freely distributed version.
MS Access is one of the worst options. On VDS it barely moves. What can not be said about the same SQLite - it is very fast. There is a problem (but it is the same with MySQL and in general with any other) - now the model is "one Expert Advisor=one trade and plus somewhere there are indicators, chart and terminal", but it can easily change, plus everything in code-base is not designed for competitive work, it implies monopoly use of the resource, there is no necessary blocking, synchronisation and so on. And by the way it is from the section of perversions - to run more than one Expert Advisor (even if they are instances of the same) on a real account.
And if you want reliability with plushes - put Oracle (you will be surprised, but for the needs of robots it is free) and APEX, write a connector to it..And another option - to drive data through Web-Request to REST model.
PS/ why argue - until MQ will not roll out a generalised connector to SQL all attempts to work correctly with DBMS are doomed to failure. This is the very case when a component is not realisable by community forces
And if you want reliability with pluses - put Oracle (you will be surprised, but for the needs of robots it is free) and APEX, write a connector to it..And another option is to drive data through Web-Request to REST model.
Yes, I know about Oracle. I even have a couple of their certificates lying around. Unfortunately, they are not useful.
As for Access, it is not so slow. I used it to translate quotes into TS (connection: terminal - base - TS). History, current quotes, states, logs, etc. in the database. And this is for intrade. There were no complaints about the database speed.
I am afraid that SQLite will not work for a similar problem statement, for the reasons stated by Eugeniy Lugovoy.
Yeah, I know about Oracle. I even have a couple of their certificates lying around. Unfortunately, they didn't come in handy.
As for Access, it is not so slow. I used it to translate quotes into TS (connection: terminal - base - TS). History, current quotes, states, logs, etc. in the database. And this is for intrade. There were no complaints about the database speed.
I'm afraid that SQLite will not work for a similar problem statement, for the reasons stated by Eugeniy Lugovoy.
if it's not a secret, what mechanism was used in TC to read out data from Assets ?
TC - standard C# ADO.NET. C buffers, their updates and writing to the database. Terminal writes data to the database via (can't remember) - either ODBC, but more likely via Jet. I'll look later if you are interested. Terminal has inbuilt export to the database (any, if the driver is on the computer).
PS Looks like OLEDB
.
Greetings, everyone! Guys I haven't looked here for a long time. It's really hot here on discussions :) Let me explain myself :)
A couple of years ago I was involved in projects where the requirements were quite different (additional market analysis by third-party software, publication on the web with history preservation, application of genetic algorithms, trade emulation, etc.), but it was expedient to have the data in the database. Since the requirements were different, the choice of DBMS was corresponding. And in the end I decided to write MT4 RDBMS drivers for each DBMS in order to use native drivers, but not ODBC/OLEDB. I.e. for mysql - libmysql, for oracle - OCI/Instant client, for SQLite - its DLL with api, but for Microsoft databases (Access/MS SQL) there is only OLEDB option. All this has been written and exists until now, here I just formed the article for MySQL bases, because for the post-Soviet space it is still closer in my subjective opinion.
In general, with databases I worked long enough and densely, and, the emergence, development and popularity of SQLite could not but affect me :) I wrote a rapper under v3 and in a separate thread everything is ok (i.e. when one chart weighs EA), however, when testing on several charts I unexpectedly got a table lock. I specially wrote test EAs to update data (rows) only by its own symbol, i.e. the table is the same but the rows are different so as not to cause loc. the result - table loc. And this is despite the fact that the vrapper itself uses mutexes to perform operations, ie until one update is not completed (+autocommit), the other will not start. simply put - the lock to occur nowhere, except inside the SQLite. I searched the forums and found that there is indeed such a problem. I have rewritten the ripper under OLEDB (the structure of all rippers is almost identical, except for the commands to call the API of the required DBMS) and checked on MS Access.... same scripts - no problems. MS SQL - no problems, PostgreSQL - no problems, connected to Oracle - also all ok.
And although it was quite a long time ago, but the feeling of SQLite remained ... I didn't experiment any more. The only similar database (file and compact with SQL) I remember was MSSQL Compact Edition, but my hands did not reach the implementation in this direction.
In the end I have two projects left - one for MySQL (including MariaDB) and one for OLEDB, which although limits the possibilities compared to native drivers (for example, the same DBMS Oracle), but they are quite enough to implement production projects. In this respect I value stability + performance of the solution, well, and plus minimisation of maintenance costs. Well, if it will be necessary to switch to another DBMS in the future, the costs will be minimal - if you simplify, you only need to rewrite queries taking into account the syntax of the new subdatabase, and in general, the logic of the project will not be affected.
Thank you all and good luck!
I took the trouble to "check out of the box" - it doesn't work.
Greetings Pavel,
Please provide the following information about your environment:
- Version and bitness of the operating system
- Version, build and bitness of the terminal
- MySQL version
It is quite strange that kernel does not contain a function to create a mutex, and libmysql does not contain a function to determine the number of rows affected by the operation...
I will try to create a similar environment and check.
win 7 x64 - mt5 x64 latest version (v5 b1455)
I can't get to MySQL, but it's not a pity.
Server: Localhost via UNIX socket
Server type: Percona Server
Server Version: 5.5.35-33.0-log - Percona Server (GPL), Release rel33.0, Revision 611
Protocol Version: 10
User: ***
Server encoding: UTF-8 Unicode (utf8)