Обсуждение статьи "Интеграция эксперта на MQL и базы данных (SQL Server, .NET и C#)"
Опубликована статья Интеграция эксперта на MQL и базы данных (SQL Server, .NET и C#):
Автор: Сергей Ткаченко
Спасибо за статью, как раз недавно обсуждали на форуме, как подключить C# DLL к MQL5 напрямую. Я до этого использовал прокладку в виде C++ DLL. Сергей, а Entity Framework с этой технологией можно будет использовать? Особенно CodeFirst интересует.
К сожалению, по поводу Entity Framework ничего не могу сказать - я с ним никогда не работал. Да и вообще по относительно новым технологиям C# и .NET у меня опыта мало.
Если бы мне нужно было это сделать - я бы попробовал. Предположительно, будет работать. Особенно если не использовать продвинутые возможности внутри экспортируемых статических функций, а завернуть их в приватные функции каких-нибудь вспомогательных классов и применять уже там. У меня так в одном из проектов использовались классы из System.Collections.Generic.
К сожалению, по поводу Entity Framework ничего не могу сказать - я с ним никогда не работал. Да и вообще по относительно новым технологиям C# и .NET у меня опыта мало.
Если бы мне нужно было это сделать - я бы попробовал. Предположительно, будет работать. Особенно если не использовать продвинутые возможности внутри экспортируемых статических функций, а завернуть их в приватные функции каких-нибудь вспомогательных классов и применять уже там. У меня так в одном из проектов использовались классы из System.Collections.Generic.
Ясно, опыт есть, при случае попробую. А вообще, вы замечали какие-либо минусы экспорта функций из DLL-файлов .NET в неуправляемый код? Я к тому, что Ренат Ф. сильно ругается на подобные вещи. Аргументы приводит самые общие, на уровне страшилок.
Вы замечали минусы? Например, снижение быстродействия, рост потребляемой памяти и т.д.
О минусах тут можно говорить только в сравнении с чем-либо.
Если сравнивать советников, которые используют экспорт функций из DLL с теми советниками, которые не используют и работают на чистом MQL - тогда тут всё зависит от реализации конкретного советника и от того, какие задачи он выполняет. Если будут два советника, которые делают в точности одно и то же - тогда сложно сказать. Предполагаю, что быстрее будет тот, который использует DLL - из-за лучшей оптимизации кода компиляторами при сборке DLL. Но это только предположение, потому как напрямую я не сравнивал. Я обычно делал в DLL только то, что в MQL сделать сложнее или вообще нельзя (например, описанную в статье работу с БД). Поэтому мои советники, сделанные с обращением к DLL и без него, выполняли разные задачи.
У советников, использующих DLL, есть один недостаток - меньшая надёжность. Временами, хотя и редко, у них возникает иногда ошибка "Access violation at 0x08364576" (цифры адреса памяти разные). У роботов на чистом MQL такого нет. Тут, конечно, всё зависит от конкретной DLL - как она реализована, насколько сложная, все ли потенциально опасные с точки зрения ошибок памяти места проверены. Но у моих советников бывает ситуация, когда два-три месяца всё работает хорошо, а потом при перезапуске у одного из пяти запущенных на одном МТ советников вылетает эта ошибка в логе. В случае чистого MQL такого не бывает.
Если сравнивать экспорт функций из DLL на C# с экспортом из обычных DLL - скажем, на C++ - то здесь у каждого подхода свои преимущества и недостатки. Я делал другую DLL на С++ и Qt. Там тоже была работа с БД, но SQLite, а не SQL Server. Ошибки доступа к памяти тоже были, причём куда чаще, чем в DLL на .NET. Впрочем, если проект "вылизан", если везде, где нужно, идёт проверка указателей на null, освобождение памяти и прочее в том же духе - тогда, может быть, наоборот будет более надёжно. Но в C# с этим как-то легче, там всё автоматически проверяется-освобождается. Отличий по производительности не замечал. Но, впрочем, мой проект на C++/Qt эксплуатировался мало.
О минусах тут можно говорить только в сравнении с чем-либо.
Если сравнивать советников, которые используют экспорт функций из DLL с теми советниками, которые не используют и работают на чистом MQL - тогда тут всё зависит от реализации конкретного советника и от того, какие задачи он выполняет. Если будут два советника, которые делают в точности одно и то же - тогда сложно сказать. Предполагаю, что быстрее будет тот, который использует DLL - из-за лучшей оптимизации кода компиляторами при сборке DLL. Но это только предположение, потому как напрямую я не сравнивал. Я обычно делал в DLL только то, что в MQL сделать сложнее или вообще нельзя (например, описанную в статье работу с БД). Поэтому мои советники, сделанные с обращением к DLL и без него, выполняли разные задачи.
У советников, использующих DLL, есть один недостаток - меньшая надёжность. Временами, хотя и редко, у них возникает иногда ошибка "Access violation at 0x08364576" (цифры адреса памяти разные). У роботов на чистом MQL такого нет. Тут, конечно, всё зависит от конкретной DLL - как она реализована, насколько сложная, все ли потенциально опасные с точки зрения ошибок памяти места проверены. Но у моих советников бывает ситуация, когда два-три месяца всё работает хорошо, а потом при перезапуске у одного из пяти запущенных на одном МТ советников вылетает эта ошибка в логе. В случае чистого MQL такого не бывает.
Если сравнивать экспорт функций из DLL на C# с экспортом из обычных DLL - скажем, на C++ - то здесь у каждого подхода свои преимущества и недостатки. Я делал другую DLL на С++ и Qt. Там тоже была работа с БД, но SQLite, а не SQL Server. Ошибки доступа к памяти тоже были, причём куда чаще, чем в DLL на .NET. Впрочем, если проект "вылизан", если везде, где нужно, идёт проверка указателей на null, освобождение памяти и прочее в том же духе - тогда, может быть, наоборот будет более надёжно. Но в C# с этим как-то легче, там всё автоматически проверяется-освобождается. Отличий по производительности не замечал. Но, впрочем, мой проект на C++/Qt эксплуатировался мало.
И еще вопрос, может быть занимались такими вещами. Можно ли из C# DLL запустить интерактивную панель управления или надо обязательно делать панель в виде отдельной программы и обеспечивать с DLL связь каким-либо из способов, например через Memory Mapping или WCF?
Я сейчас говорю про один локальный компьютер.
Нет, с интерактивными панелями я не работал, к сожалению. Могу только предполагать. И я не совсем понимаю, что тут имеется в виду под "интерактивной панелью".
Нужно открывать какое-то из окон MetaTrader? Здесь я вообще не знаю, как это можно было бы сделать и можно ли вообще.
Нужно просто открывать какое-то окно и получать ввод от пользователя? Этим тоже не занимался, но думаю, что скорее всего это несложно. Сделать класс, в котором определяется обычное окно Windows Forms. В этом классе сделать статическую экспортируемую функцию, которая создаёт окно, показывает пользователю в диалоговом режиме, а потом освобождает. Должно сработать.
вот такая ошибка:
2019.02.11 21:03:17.627 Cannot find 'CreateConnection' in 'MqlSqlDemo.dll'
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Интеграция эксперта на MQL и базы данных (SQL Server, .NET и C#):
Статья описывает, как добавить в экспертов на MQL5 возможность работы с сервером баз данных Microsoft SQL Server. Используется импорт функций из DLL. Для создания DLL применяется платформа Microsoft .NET и язык C#. Используемые в статье методы с незначительными изменениями подходят и для экспертов, написанных на MQL4.
На форумах периодически встречаются вопросы о том, как интегрировать в экспертов, написанных на MQL 5, работу с базами данных. Интерес к этой теме неудивителен. БД очень хороши как средства сохранения данных. В отличие от логов терминала, данные из баз никуда не исчезают. Их легко сортировать и фильтровать, выбирая только нужные. Через БД эксперту можно передавать нужную информацию — например, те или иные команды. И главное — полученные данные можно анализировать с разных сторон и статистически обрабатывать. Например, чтобы узнать среднюю и суммарную прибыль за указанное время по каждой валютной паре, достаточно написать запрос в одну строку, что займёт буквально минуту. А теперь представьте, сколько потребуется времени, чтобы подсчитать это вручную по истории счёта в торговом терминале.
К сожалению, штатных средств для взаимодействия с серверами БД в терминалах MetaTrader нет. Проблема решается только через импорт функций из DLL-файлов. Задача непростая, но выполнимая.
Запускаем эксперта, поменяв в параметрах данные строки подключения на параметры доступа к вашему серверу БД. Если всё сделано правильно, эксперт выведет в лог следующие записи:
2018.07.10 20:36:22.187 MqlSqlDemo (EURUSD,H1) Создана таблица в БД.
2018.07.10 20:36:22.427 MqlSqlDemo (EURUSD,H1) Данные записаны в таблицу.
2018.07.10 20:36:22.569 MqlSqlDemo (EURUSD,H1) Число прочитано из БД: 1
2018.07.10 20:36:22.586 MqlSqlDemo (EURUSD,H1) Строка прочитана из БД: Test
Подключение к БД, выполнение SQL-команд, запись и чтение данных — всё успешно выполняется.
Автор: Сергей Ткаченко