Обсуждение статьи "Работа с СУБД MySQL из MQL5 (MQL4)" - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
если не секрет, какой механизм использовался в ТС для вычитки данных с Aссess ?
ТС - стандартный C# ADO.NET. C буферами, их обновлениями и записью в базу. Терминал данные в базу пишет через (не помню) - либо ODBC, но скорее через Jet. Позже гляну, если интересно. В терминале встроенный экспорт в базу (любую, если драйвер на компе).
PS Похоже OLEDB
.
Приветствую Всех! Ребятки давно не заглядывал сюда. Тут прям жара по дискуссиям :) Разрешите объясниться :)
Пару лет назад занимался проектами в которых требования были достаточно разные (доп анализ рынка сторонним ПО, публикация на веб с сохранением истории, применение генетических алгоритмов, эмуляция торговли и т.п.), но данные целесообразно было иметь в БД. Поскольку требования были разными, то и выбор СУБД был соответственным. И в конце концов я решил под каждую СУБД написать врапперы к MT4 чтобы использовать "родные" драйверы, но не ODBC/OLEDB. Т.е. для mysql - libmysql, для oracle - OCI/Instant client, для SQLite - eго DLL с api, но вот для баз от Microsoft (Access/MS SQL) тут только вариант OLEDB остается. Все это было написано и существует до сих пор, здесь просто оформил статью для MySQL баз, поскольку для постсоветского пространства она все-таки ближе по моему субъективному мнению.
В общем, с базами данных я работал достаточно долго и плотно, и, появление,развитие и популярность SQLite меня не могла не затронуть :) Враппер я написал под v3 и в отдельном потоке все ок (т.е. когда на один чарт весить эксперт), однако при тестах на нескольких чартах я нежданчиком получал лок таблицы. Специально написал тестовые EA чтобы обновляли данные(строки) только по своему символу, т.е. таблица одна но строки разные чтобы не вызывать лока. результат - лок таблицы. И это не смотря на то, что сам враппер использует mutexы для выполнения операций, т.е. пока один update не завершится (+autocommit), то другой не начнется. проще говоря - локу возникнуть негде, кроме как внутри самой SQLite. Побегал по форумам и нашел что такая проблема действительно есть. Я переписал враппер под OLEDB (структура всех врапперов практически идентична, за исключением самих команд вызова API нужных СУБД) и проверил на MS Access... те же скрипты - никаких проблем. MS SQL - без проблем, PostgreSQL - без проблем, соединился с Oracle - тоже все ок.
И хотя было это достаточно давно, но ощущение от SQLite осталось... больше не экспериментировал. Единственная аналогичная база (файловая и компактная с SQL) мне помнится была MSSQL Compact Edition, но че-то руки не дошли до реализации в эту сторону.
В конце концов у меня два проекта осталось - один для MySQL (в т.ч. MariaDB) и один для OLEDB, который хоть и ограничивает возможности по сравнению с родными драйверами (например той же СУБД Oracle), но их вполне достаточно чтобы реализовывать production проекты. В этом плане я ценю стабильность + производительность решения, ну и плюс минимизация затрат на сопровождение. Ну а если нужен будет в дальнейшем переход к другой СУБД, то расходы тут будут минимальны - если упростить, то нужно всего лишь переписать запросы с учетом синтаксиса новой субд, а в целом логики проекта это не коснется.
Спасибо всем и Удачи!
не поленился "проверил из коробки" - не работает
Приветствую Павел,
Пожалуйста сообщите следующие сведения об окружении:
- Версия и битность операционной системы
- Версия, билд и битность терминала
- Версия MySQL
Достаточно странно что кернел не содержит функцию создания мьютекса, а libmysql функцию определения количество строк затронутых операцией...
Я постараюсь создать аналогичное окружение и проверить.
win 7 x64 - mt5 x64 последней версии (v5 b1455)
до MySQL не доходит, но не жалко
Сервер: Localhost via UNIX socket
Тип сервера: Percona Server
Версия сервера: 5.5.35-33.0-log - Percona Server (GPL), Release rel33.0, Revision 611
Версия протокола: 10
Пользователь: ***
Кодировка сервера: UTF-8 Unicode (utf8)
win 7 x64 - mt5 x64 последней версии (v5 b1455)
до MySQL не доходит, но не жалко
Сервер: Localhost via UNIX socket
Тип сервера: Percona Server
Версия сервера: 5.5.35-33.0-log - Percona Server (GPL), Release rel33.0, Revision 611
Версия протокола: 10
Пользователь: ***
Кодировка сервера: UTF-8 Unicode (utf8)
Вот для MQL5 перекомпилил x64
Павел попробуйте.
проблем с подключением dll'ок больше нет
всё работает, спасибо
проблем с подключением dll'ок больше нет
всё работает, спасибо
Всегда рад помочь.
Удачи Вам в проектах.
Спасибо, прочитал. Там оч дельное замечание автора текущей статьи, который пришел,... и все испортил.)
Сам сталкивался не раз с проблемой коллизий на ней. Скажем, если торговый робот прикреплен к различным чартам, а использует одну базу, причем обращение происходит к одной таблице общего назначения (скажем регистрация/изменение сессий, аккаунтов), то в любом случае вы получите ошибку типа "таблица заблокирована". И не важно что транзакции все завершены, курсоры все закрыты и БД открыта была в shared режиме.
Комментатор наверно не разбирался в настройках sqlite, которые все коллизии разрешают через компилирование для режим с локами или через pragma.
Со своей колокольни могу сказать что я несколько лет на тяжеловесных проектах с одновременным чтением/записью многопоточно - и нет никаких проблем, главное чтоб руки были прямые.
Комментатор наверно не разбирался в настройках sqlite, которые все коллизии разрешают через компилирование для режим с локами или через pragma.
Со своей колокольни могу сказать что я несколько лет на тяжеловесных проектах с одновременным чтением/записью многопоточно - и нет никаких проблем, главное чтоб руки были прямые.
o_O
Если что я могу поднять тот проект для SQLite, написать тестовые скрипты/EA и если будут снова локи, то можем вместе разобраться (если Вы не против) и предоставить программное решение сообществу.
Возможно стоит уделить этому внимание т.к. есть некоторые преимущества бд (автономность, SQL, мобильность, встраиваемость и т.п.).
По факту, я брал готовую DLL от SQLite (не исходники) и ее не перекомпиливал, а просто работал с С++ API.