В наших компонентах этого делать необязательно, даже нежелательно, тк элементы запросов в них работают каждый в своей транзакции. Вот почему нельзя использовать, к примеру, VACUUM совместно с другими запросами в одном элементе, он просто не будет работать, тк должен выполнтся в своей, независимой транзакции

miver, взяли меня в просак Я все же буду делать запросы при просмотре логов и фильтрации оных - потому и база, а не файл.

Neo, есть еще один прикол у SQLite. Движок имеет тенденцию накапливать память, и если модуль записи не будет перезапускаться ежедневно, то память со временем вырастит очень сильно и может даже подвесить комп. Побороть это дело PRAGMA запросами не получилось, память росла в любом случае, в одном меньше, в другом больше, но росла

Если в БД 1-н столбик, то нет никакого резона
Надеюсь Вы знаете о существовании SearchInFile

Я написал как сделать. У меня с таким размером базы нет никаких тормозов главного потока

Вот как! Значит нужно бы вынести этот модуль записи в отдельную программу, и слать ей по UDP, перезапуская каждые сутки?
А если у меня в программе почти вся логика завязана на базах, но в памяти -как быть? Перезапускаться постоянно?
------------ Дoбавленo в 13.42:
miver, столбика 4, но раз уж все работает на базах, то думал и здесь использовать. Да и поиск по 20+Мб текста когда нужно сделать - база же быстрее?

Я у себя так и сделал -- накопительня база, в которую постоянно пишутся данные с определенным интервалом. Каждые сутки, в 0 часов, модуль записи в базу перезапускается и создает новую базу, в которую пишутся данные уже за следующее число. На момент перезапуска используется внутренний буфер в модуле обработки. Это дело работает без остановки месяцами, пока я сам не перезапущу по надобности. Извне я к базе обращаюсь из совершенно другого модуля, который напрямую не связан с модулем записи и обработки, только по UDP для синхронизации.

Не факт. Посмотри
Тут

каждый раз не идет. На диск сбрасывается при заполнении буфера блока управления БД, который создается при открытии БД.

И этот блок имеет тенденцию расти. Может движок и освобождает буфер, но не отдает освобожденное системе, даже принудительно дав ему сброс буфера в дефолтное состояние. Кстати, этим заразным явлением обладает и MSSQL, разрастается до неимоверных размеров, но на базе поболее

Это при PRAGMA synchronous=OFF, по умолчанию, если файл не занят, сброс идёт по возможности сразу, пачками по 1 Кб (по умолчанию).
------------ Дoбавленo в 14.53:

Если не ошибаюсь, с самого появления SQLite были жалобы на медленные и глючные функции работы с памятью по Windows (malloc, realloc и free). Зная это, разработчики предлагают множество способов компиляции с самыми разными методами работы с памятью, включая библиотеки сторонних разработчиков. Единственный способ быть уверенным в том, какой метод используется в Вашем экземпляре библиотеки - компилировать библиотеку самостоятельно

Ага, вот этого мне очень сильно не хватало. Для меня гораздо проще и быстрее было сделать перезапуск, к тому же, все равно надо было создавать новую базу в 0 часов.

nesco, разные способы работы с памятью имеют не только разную стабильность, но и разную производительность (так, стандартные медленнее, но стабильнее). Моё дело поделиться информацией, Ваше дело принять к сведению, к деятельности никого не агитирую

Да я никаких претензий не питаю. Просто констатировл факт.

Очень хорошо, мне стабильность более важна

nesco, очень интересно взглянуть на Вашу связку модулей с базой (если можно, выложите кусочек).
miver, все же база мне более родная. Поиск по ней проще и т.д..
Но я так и не понял конкретно по записи нескольких строк - нужно выполнять PRAGMA synchronous=OFF и писать все инсерты списком, или нет совсем никакого смысла? Ведь я четко вижу, что при каждой записи в базу создается файл журнала на диске. Даже если база 0 кб.