Discussing the article: "Market Simulation: First Steps with SQL in MQL5 (III)"

Check out the new article: Market Simulation: First Steps with SQL in MQL5 (III).

In the previous article, we looked at an example of implementing a class in MQL5 to provide basic support. Its purpose is specifically to allow SQL code to be stored in a separate script file. This way, we won't need to write the same SQL statements as string literals in the MQL5 source code. Although this solution is functional, there are some aspects of it that we can and should improve.

In the previous article, Market Simulation: First Steps with SQL in MQL5 (II), we looked at an example of implementing a class in MQL5 to provide basic support. Its purpose is precisely to allow us to include SQL code within a script file. This way, we won't need to write the same SQL statements as string literals in the MQL5 source code. Although this solution is functional, there are some aspects of it that we can and should improve to make working with SQL more enjoyable—or, at the very least, more convenient—as we use MQL5 more extensively.

However, in today's article, we won't limit ourselves to just these improvements, since this task can be completed fairly quickly and won't cause any major inconvenience. In addition, we'll explore how to embed SQL script files in an executable created in MQL5. This is because many people may want to embed SQL code in the final executable so that users cannot modify or even delete it without fully understanding its purpose.

In addition, if we embed the file—which, in this case, would be an SQL script—in the executable, we'll have one less problem when sharing the program with another user. This is because the executable itself will already contain the data expected and required to perform the task at hand. I'm not going to tell you not to do it, and I won't be the one to stop you from doing it. The decision to embed a file—which, in this case, would be an SQL script—in the executable is entirely up to you as the programmer. That's because every case is unique and requires a tailored approach to arrive at the right solution.


Author: Daniel Jose

Thanks, Daniel. It’s a good idea to keep the SQL script editable while you are developing it and embed it when distributing the program. One thing that caught my attention was your statement about how reporting the failed line will help locate the error. However, this does not undo previously successful statements. For a database setup script, this means some tables may be created successfully and some may be left uncreated. Would you consider adding code to the class to control database transactions so a failure to create a table, for instance, would cause the changes made within the transaction to be rolled back?