SQL запрос в SQLite - страница 4

 
Dmitriy Skub #:

Так Вы его сделали первичным ключом?

REPLACE INTO FORTS_название_таблицы ( replID, replRev , replAct , server_time, num ) VALUES ( '8327... ' , '8327... ' , '0', '08.12...' ,1) как-то так

 string(GetFieldType(string(ptable_desc^.name), Fields)) + ',num integer primary key autoincrement)' else
 
prostotrader #:

А вот не работает


Вы туда значени РАЗНЫЕ пишете, а должны быть - ОДИНАКОВЫЕ.

Так понятнее?
 
prostotrader #:

Я так и подумал, что так сделаете. Не надо автоинкремент.

 
Sergey Gridnev #:
Вы туда значени РАЗНЫЕ пишете, а должны быть - ОДИНАКОВЫЕ.

Так понятнее?

Так понятно

 
prostotrader #:
Нахрена там автоинкремент?
 

Всем спасибо, все получилось


 
prostotrader #:

Всем спасибо, все получилось

Поздравляю! А вот интересно - какое время обновления записи?

 
Dmitriy Skub #:


Есть проблема.

таблица heartbeat находится в потоке FORTS_TRADE_REPL, лисенер открывается с параметрами snapsot+online,

иначе, мы не получим ордера и сделки, которые совершены раньше в эту сессию + предыдущую.

НО!

В эту таблицу в режиме snatshot "валится" все время, которое было в предыдущую и в текущую сессию.

Как будем решать эту проблему?

Там более 100 000 записей, что очень сильно тормозит начальную загрузку

в режиме snapshot

Все потоки уже перешли в режим он-лайн, а TRADE все грузит и грузит время сервера

Может быть сделать так.

Если поток не перешел в режим он-лайн, то просто игнорировать серверное время?

CG_MSG_STREAM_DATA: begin                               // Update storage
      if((sData.Tables[pcg_msg_streamdata_t(msg)^.msg_index].tName = 'heartbeat') and
         (FLsnrs[sData.Pos].LsnParams.cgMsgRplOnline = true)) then
        CGCntr.FStorage. UpdHeatBeart(pcg_msg_streamdata_t(msg), sData) else
          CGCntr.FStorage.UpdStrMsg(pcg_msg_streamdata_t(msg), sData);
    end;
Продолжим в нашей теме
 
prostotrader #:

Есть проблема.

таблица heartbeat находится в потоке FORTS_TRADE_REPL, лисенер открывается с параметрами snapsot+online,

иначе, мы не получим ордера и сделки, которые совершены раньше в эту сессию + предыдущую.

НО!

В эту таблицу в режиме snatshot "валится" все время, которое было в предыдущую и в текущую сессию.

Как будем решать эту проблему?

Там более 100 000 записей, что очень сильно тормозит начальную загрузку

в режиме snapshot

Все потоки уже перешли в режим он-лайн, а TRADE все грузит и грузит время сервера

Может быть сделать так.

Если поток не перешел в режим он-лайн, то просто игнорировать серверное время?

Продолжим в нашей теме

SQLite не самый лучший выбор для многопоточного приложения. Совсем-совсем не удачный :-(

Если много потоков захотят писать в базу, то писать будет один а остальные втормозят и будут ждать

 
Maxim Kuznetsov #:

SQLite не самый лучший выбор для многопоточного приложения. Совсем-совсем не удачный :-(

Если много потоков захотят писать в базу, то писать будет один а остальные втормозят и будут ждать

SQLite, как файловая серверная СУБД, блокирует таблицы базы данных при обновлениях. На одновременный доступ влияют следующие параметры:

  • если несколько потоков обновляют одну и ту же базу данных, задайте для параметра SharedCache connection значение False. Это помогает избежать некоторых возможных взаимоблокировок.
  • Если несколько процессов или потоков обновляют одни и те же таблицы базы данных, задайте для параметра LockingMode значение Normal, чтобы разрешить одновременный доступ к таблицам. Кроме того, задайте для параметра Синхронное соединение значение Полное или Нормальное. Таким образом, SQLite обновляет файл базы данных сразу после завершения транзакции, а другие соединения видят обновления на предсказуемой основе.
  • Чтобы избежать конфликтов блокировки между соединениями, задайте для параметра UpdateOptions.LockWait значение True, а для BusyTimeout — более высокое значение.
  • Чтобы избежать конфликтов блокировки между длительными транзакциями обновления, задайте для параметра TFDConnection.TxOptions.Isolation значение xiSnapshot или xiSerializible.
Причина обращения: