SQL запрос в SQLite - страница 11
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Причем скорость работы все системы будет зависеть и от настроек выбора потоков и таблиц,
чем меньше потоков и таблиц, тем быстрее работа
Параметры, влияющие на скорость работы
На тестовом контуре, сейчас, доступно 105 фьючерсов
При полной загрузке (все 105 фьючерсов), все отлично работает
И в каждом дочернем окне есть информация об инструменте + обрабатывается Tick (таблица common), и если
есть поток стаканов, то окно получает свой стакан. Остальные данные берутся из базы по запросу
Спасибо!
Работает, но появилась другая проблема, ордера sell (dir = 2) и ордера buy (dir=1) расположены
в разнобой, тогда как в стакане сначала (сверху) должны располагаться ордера sell (dir = 2) от более
большой цены к маленькой
Такой запрос
Не помогает
Нет ли смысла ордера на покупку и на продажу получать двумя разными запросами?
2 запроса - двойное "отжирание" времени, но я решил проблему
переставив местами сортировку, теперь стакан правильный
Но нужно еще проверить, как будет с отрицательными ценами...А , вижу , все верно именно так.
Спасибо за помощь.
Привет!
В описании SQLite написано:
9. Иногда запросы возвращают SQLITE_BUSY в режиме WAL Второе преимущество WAL-режима заключается в том, что Писатели не блокируют читателей, а читатели не блокируют писателей. В основном это так. Но есть некоторые неясные случаи, когда запрос к WAL-режиму база данных может возвращать SQLITE_BUSY, поэтому приложения должны быть подготовлены за эту случайность. К случаям, когда запрос к базе данных в режиме WAL может возвращать SQLITE_BUSY, относятся следующие: Если для другого подключения к базе данных открыт режим базы данных в режиме монопольной блокировки, то все запросы к database вернет SQLITE_BUSY. И Chrome, и Firefox открывают свои файлы базы данных в режиме монопольной блокировки, поэтому попытки прочитать Chrome или Базы данных Firefox во время работы приложений столкнутся с этим проблема, например. Когда последнее соединение с определенной базой данных закрывается, это соединение приобретет эксклюзивную блокировку на короткое время, пока оно очищает файлы WAL и разделяемой памяти. Если вторая база данных пытается для открытия и запроса базы данных при первом подключении все еще находится посередине В процессе очистки второе соединение может получить ошибку SQLITE_BUSY. Если последнее подключение к базе данных завершилось сбоем, то первый новый Подключение для открытия базы данных запустит процесс восстановления. В Во время восстановления удерживается эксклюзивная блокировка. Таким образом, если третье соединение с базой данных пытается подключиться и выполнить запрос, пока второе соединение выполняет восстановление, Третье подключение получит ошибку SQLITE_BUSY.А есть ли такой режим работы SQLite, в котором никогда не конфликтуют множественные соединения с базой?
Возможно ли установить очередь запросов разных соединений?
К сожалению (у меня включен режим WAL), при работе с базой возникает ошибка "Database is locked".
Нормальная работа может продолжаться и час и два, а может и несколько секунд, а потом появляется эта ошибка.
Привет!
В описании SQLite написано:
А есть ли такой режим работы SQLite, в котором никогда не конфликтуют множественные соединения с базой?
Возможно ли установить очередь запросов разных соединений?
К сожалению (у меня включен режим WAL), при работе с базой возникает ошибка "Database is locked".
Нормальная работа может продолжаться и час и два, а может и несколько секунд, а потом появляется эта ошибка.
собственно "давно обещанное большевиками случилось" :-(
а именно файловые блокировки
Режима когда их нет - НЕТ.
Возможны некоторые обходные пути, которые могут временно помочь (именно временно, потом всё равно те-же грабли):
* перенесите базу в RAM-диск
* у вас множество хендлов к базе - разделите кому не надо писать пусть будет read-only
* отключите auto-commit, оберните все запросы в TRANSACTION, а COMMIT/ROLLBACK вызывайте самостоятельно и обрабатывайте ошибки (повторы, переподключения, etc)
* как самый крайний случай добавьте RW-Mutex ко всем запросам. Это убьёт скорость напрочь (всё равно что однопоточно), но зато блокировки будут на уровень выше и не вызовут краха.
а вообще надо смотреть на другие базы пока не поздно.
из встраиваемых в приложения (не требующих отдельного сервера) и более менее близких с SQLite есть:
* monetdb/e https://www.monetdb.org/ - сильно быстрее SQLite, но в многопотоке не пробовал.
* FireBird https://firebirdsql.org/ - традиционно любимая бухгалтерами :-)
или брать знакомое зло в виде Postgresql , MySQL
собственно "давно обещанное большевиками случилось" :-(
а именно файловые блокировки
Режима когда их нет - НЕТ.
Возможны некоторые обходные пути, которые могут временно помочь (именно временно, потом всё равно те-же грабли):
* перенесите базу в RAM-диск
* у вас множество хендлов к базе - разделите кому не надо писать пусть будет read-only
* отключите auto-commit, оберните все запросы в TRANSACTION, а COMMIT/ROLLBACK вызывайте самостоятельно и обрабатывайте ошибки (повторы, переподключения, etc)
* как самый крайний случай добавьте RW-Mutex ко всем запросам. Это убьёт скорость напрочь (всё равно что однопоточно), но зато блокировки будут на уровень выше и не вызовут краха.
а вообще надо смотреть на другие базы пока не поздно.
из встраиваемых в приложения (не требующих отдельного сервера) и более менее близких с SQLite есть:
* monetdb/e https://www.monetdb.org/ - сильно быстрее SQLite, но в многопотоке не пробовал.
* FireBird https://firebirdsql.org/ - традиционно любимая бухгалтерами :-)
или брать знакомое зло в виде Postgresql , MySQL
Я уже подумываю о смене Базы
Вот список Баз с которыми может работать FireDAC
База должна быть быстрой и бесплатной
Какую, по Вашему мнению, выбрать?
Я уже подумываю о смене Базы
Вот список Баз с которыми может работать FireDAC
База должна быть быстрой и бесплатной
Какую, по Вашему мнению, выбрать?
исключительно из требований "быстрый, бесплатный" и опций "легко найти помощь" и "может жить на Linux сервере" (вдруг захочется на хостинг и монстрячить веб-часть)
в списке, при всём богатстве выбора - Postgresql или MySQL , а кто из них - уже на вкус и цвет
MySQL попроще, Postgresql пофичастее