Discusión sobre el artículo "Integración de un experto en MQL y bases de datos (SQL Server, .NET y C#)"

 

Artículo publicado Integración de un experto en MQL y bases de datos (SQL Server, .NET y C#):

El artículo describe cómo añadir a los expertos en MQL5 la posibilidad de trabajar con el servidor de bases de datos Microsoft SQL Server. Usaremos la importación de funciones de DLL. Para crear la DLL, se utilizará la plataforma Microsoft .NET y el lenguaje C#. Los métodos utilizados en el artículo, aunque con algunos cambios poco significativos, funcionan también para los expertos escritos en MQL4.

En los foros nos encontramos periódicamente con usuarios que preguntan cómo integrar en los expertos escritos en MQL 5 el trabajo con bases de datos. El interés por este tema no es nada sorprendente. Las bases de datos son muy útiles como recursos a la hora de guardar datos. A diferencia de los logs del terminal, los datos de las bases no desaparecen en ninguna parte. Son fáciles de clasificar y filtrar, permitiendo elegir solo las necesarias. Con la ayuda de una base de datos podemos transmitir al experto la información necesaria, por ejemplo, un cierto comando. Y lo más importante, los datos recibidos pueden ser analizados desde distintos puntos de vista y procesados estadísticamente. Por ejemplo, para averiguar el promedio y los beneficios totales durante un tiempo específico para cada pareja de divisas, basta con escribir una solicitud en una línea, lo que ocupará literalmente un minuto. Ahora imagine cuánto tiempo le llevaría calcularlo manualmente usando la historia de la cuenta en el terminal comercial.

Por desgracia, no existen medios estándar para interactuar con los servidores de bases de datos en los terminales MetaTrader. El problema se resuelve con la importación de funciones desde archivos DLL. La traea es compleja, pero asumible.

Iniciamos el experto, cambiando en los parámetros los datos de la línea de conexión por los parámetros de acceso a nuestro servidor de base de datos. Si lo hemos hecho todo bien, el experto mostrará en el log las siguientes entradas:

2018.07.10 20:36:21.428    MqlSqlDemo (EURUSD,H1)    Conexión con la base de datos establecida.
2018.07.10 20:36:22.187    MqlSqlDemo (EURUSD,H1)    Creado recuadro en la base de datos.
2018.07.10 20:36:22.427    MqlSqlDemo (EURUSD,H1)    Datos escritos en el recuadro.
2018.07.10 20:36:22.569    MqlSqlDemo (EURUSD,H1)    Número leído desde la base de datos: 1
2018.07.10 20:36:22.586    MqlSqlDemo (EURUSD,H1)    Línea leída desde la base de datos: Test

 La conexión a la base de datos, la ejecución de los comandos SQL, la escritura y lectura de datos: todo se realiza con éxito.

Autor: Сергей Ткаченко

 
MetaQuotes Software Corp.:

El artículo Integración de MQL Expert Advisor y Bases de Datos (SQL Server, .NET y C#) ha sido publicado:

Autor: Sergey Tkachenko

Gracias por el artículo, hace poco discutimos en el foro cómo conectar C# DLL a MQL5 directamente. Antes utilizaba una DLL en C++. Sergey, ¿se puede utilizar Entity Framework con esta tecnología? Especialmente CodeFirst es de interés.

 

Por desgracia, no puedo decir nada sobre Entity Framework: nunca he trabajado con él. Y tengo poca experiencia con las relativamente nuevas tecnologías C# y .NET.

Si tuviera que hacerlo, lo intentaría. Es de suponer que funcionará. Especialmente si no usas funciones avanzadas dentro de funciones estáticas exportadas, sino que las envuelves en funciones privadas de algunas clases auxiliares y las aplicas allí. En uno de mis proyectos utilicé clases de System.Collections.Generic.

 
Сергей Ткаченко:

Lamentablemente, no puedo decir nada sobre Entity Framework: nunca he trabajado con él. Y tengo poca experiencia con las relativamente nuevas tecnologías C# y .NET en general.

Si tuviera que hacerlo, lo probaría. Es de suponer que funcionará. Sobre todo si no usas funciones avanzadas dentro de funciones estáticas exportadas, sino que las envuelves en funciones privadas de algunas clases auxiliares y las aplicas allí. Yo usé clases de System.Collections.Generic en uno de mis proyectos.

Ya veo, tengo experiencia, lo probaré si tengo ocasión. En general, ¿has notado alguna desventaja de exportar funciones de archivos .NET DLL a código no administrado? Quiero decir que Renat F. jura mucho sobre estas cosas. Él da los argumentos más generales a nivel de historias de miedo.

¿Has notado las desventajas? Por ejemplo, menor rendimiento, mayor consumo de memoria, etc.

 

Sólo podemos hablar de las desventajas en comparación con otra cosa.

Si comparamos los EAs que utilizan la exportación de funciones desde DLL con aquellos EAs que no lo hacen y trabajan en MQL puro - entonces todo depende de la implementación de un EA en particular y qué tareas realiza. Si hay dos EAs que hacen exactamente lo mismo - entonces es difícil de decir. Supongo que el que utiliza DLL será más rápido debido a una mejor optimización del código por los compiladores al construir DLLs. Pero eso es sólo una suposición, porque no he comparado directamente. Normalmente he hecho en DLL sólo lo que es más difícil o imposible de hacer en MQL (por ejemplo, el trabajo con la base de datos descrita en el artículo). Por lo tanto, mis Asesores Expertos hechos con y sin acceso a DLL realizaban tareas diferentes.

Los Asesores Expertos que utilizan DLL tienen una desventaja - menos fiabilidad. A veces, aunque raramente, obtienen el error "Access violation at 0x08364576" (los dígitos de la dirección de memoria son diferentes). Los robots basados en MQL puro no tienen tales errores. Por supuesto, todo depende de una DLL en particular - cómo se implementa, lo complejo que es, si todos los lugares potencialmente peligrosos en términos de errores de memoria se han comprobado. Pero mis Asesores Expertos tienen una situación en la que todo funciona bien durante dos o tres meses, y luego al reiniciar uno de los cinco Asesores Expertos que se ejecutan en una MT tiene este error en el registro. En el caso de MQL puro esto no sucede.

Si comparamos la exportación de funciones desde DLLs en C# con la exportación desde DLLs normales - digamos, en C++ - entonces cada enfoque tiene sus propias ventajas y desventajas. Hice otra DLL en C++ y Qt. También funcionaba con una base de datos, pero SQLite, no SQL Server. También había errores de acceso a memoria, y mucho más a menudo que en la DLL .NET. Sin embargo, si se "limpia" el proyecto, si se comprueban los punteros a null en todas partes donde sea necesario, se libera memoria, etc., entonces puede que lo contrario sea más fiable. Pero en C# es de alguna manera más fácil, allí todo se comprueba y libera automáticamente. No he notado ninguna diferencia en el rendimiento. Pero, sin embargo, mi proyecto C++/Qt no fue explotado mucho.

 
Сергей Ткаченко:

Las desventajas aquí sólo se pueden comentar en comparación con cualquier otra cosa.

Si comparamos los EAs que utilizan la exportación de funciones desde DLL con aquellos EAs que no lo hacen y trabajan en MQL puro - entonces todo depende de la implementación de un EA en particular y qué tareas realiza. Si hay dos EAs que hacen exactamente lo mismo - entonces es difícil de decir. Supongo que el que utiliza DLL será más rápido debido a una mejor optimización del código por los compiladores al construir DLLs. Pero eso es sólo una suposición, porque no he comparado directamente. Normalmente he hecho en DLL sólo lo que es más difícil o imposible de hacer en MQL (por ejemplo, el trabajo con la base de datos descrita en el artículo). Por lo tanto, mis Asesores Expertos hechos con y sin acceso DLL realizaron tareas diferentes.

Los Asesores Expertos que utilizan DLL tienen una desventaja - menos fiabilidad. A veces, aunque raramente, obtienen el error "Access violation at 0x08364576" (los dígitos de la dirección de memoria son diferentes). Los robots basados en MQL puro no tienen tales errores. Por supuesto, todo depende de una DLL en particular - cómo se implementa, lo complejo que es, si todos los lugares potencialmente peligrosos en términos de errores de memoria se han comprobado. Pero mis Asesores Expertos tienen una situación en la que todo funciona bien durante dos o tres meses, y luego al reiniciar uno de los cinco Asesores Expertos que se ejecutan en una MT tiene este error en el registro. En el caso de MQL puro, esto no sucede.

Si comparamos la exportación de funciones desde DLLs en C# con la exportación desde DLLs normales - digamos, en C++ - entonces cada enfoque tiene sus propias ventajas y desventajas. Hice otra DLL en C++ y Qt. También funcionaba con una base de datos, pero SQLite, no SQL Server. También había errores de acceso a memoria, y mucho más a menudo que en la DLL .NET. Sin embargo, si se "limpia" el proyecto, si se comprueban los punteros a null en todas partes donde sea necesario, se libera memoria, etc., entonces puede que lo contrario sea más fiable. Pero en C# es de alguna manera más fácil, allí todo se comprueba y libera automáticamente. No he notado ninguna diferencia en el rendimiento. Pero, sin embargo, mi proyecto C + + / Qt no se explotó mucho.

Y otra pregunta, tal vez usted ha hecho tales cosas. ¿Es posible lanzar un panel de control interactivo desde una DLL en C# o hay que hacer el panel como un programa aparte y proporcionar comunicación con la DLL de alguna manera, por ejemplo, a través de Memory Mapping o WCF?

Ahora estoy hablando de un ordenador local.

 

No, por desgracia no he trabajado con paneles interactivos. Sólo puedo especular. Y no entiendo muy bien qué se entiende por "panel interactivo".

¿Es necesario abrir alguna ventana de MetaTrader? Aquí no sé cómo se podría hacer o si se puede hacer en absoluto.

¿Debería simplemente abrir alguna ventana y recibir entradas del usuario? No he hecho esto tampoco, pero creo que probablemente no es difícil. Haz una clase que defina una ventana normal de Windows Forms. En esa clase, haz una función estática exportable que cree la ventana, la muestre al usuario en modo diálogo, y luego la libere. Eso debería funcionar.

 
¡Increíble artículo! ¡Exactamente lo que estaba buscando! ¡Gracias Sergiey!
 
marca.
 
Sí, muy buen trabajo Sergy, muy apreciado.
 

Me encanta el artículo - muchas gracias por el debate en profundidad.


Esperando que alguien me puede ayudar con un inconveniente durante el tiempo de construcción.

C:\Users\user\source\repos\mql\MqlSqlDemo\packages\UnmanagedExports.1.2.7\tools\RGiesecke.DllExport.targets(58,3): error : Microsoft.Build.Utilities.ToolLocationHelper could not find ildasm.exe


Esencialmente, la utilidad UnmanagedExports es incapaz de encontrar el ejecutable desensamblador necesario para realizar su trabajo.


Sé a ciencia cierta que ildasm.exe existe, y sus diversas ubicaciones... pero no estoy seguro de cómo conseguir que DllExport reconozca la ruta correcta.