И хочется, и колется, и мамка не велит А серьезно -- не до него пока, там я другие баги сейчас отлавливаю. Обязательно проверю, как только время появится. Я и предыдущий-то проверил, потому, что отловился глобальный глюк в аппаратной части у разработчиков, приведший к катастрофическим последствиям, под шумиху я и протестил его
------------ Дoбавленo в 17.49:
Alexbootch, ты мне лучше расскажи, как побороть нерациональное использование памяти движком -- оно гребет, гребет в буфер, наращивая его, а при создании новой текущей базы не очищает его, а добавляет новый. Есть ли каки-либо действенные запросы pragma, которые позволяют от этого избавиться, без перекомпиляции движка

nesco, а раньше такое было?

Я тебя об этом уже спрашивал, эта фича идет уже давно. Прошлый раз ты мне рекомендовал PRAGMA default_cache_size, млоэффективный способ, надо сказать

Ничего я такого не рекомендовал в отношении рациональное использование памяти движком. Это только на быстродействие зависит. А фича в версии 3.4.2 тоже есть?
------------ Дoбавленo в 19.54:
nesco, а при динамическом подключении библиотеки тоже самое?

Лень искать, но если очень хочется, то я поищу

Это ты сейчас говоришь, возможно, что раньше ты этого не знал

При любом подключении и в любой версии. В принципе, она уменьшается, со временем, но не сильно

перед созданием новой, закрываешь старую ?

Сами компоненты закрывают старую при создании или открытии новой.

и сбрасывают кэш на диск и уничтожают блок управления и освобождают память ?
Или только уничтожают id ?
Посмотреть надо. Пока ничего сказать не могу.

О! Серьезный подход. А ведь вопрос действительно интересный, и его неплохо бы решить

nesco, а схему либо схемы можешь выложить для моделирования подобной ситуации? И еще я думаю, что ключ SQLITE_TEMP_STORE=3 лучше заменить на на SQLITE_TEMP_STORE=0, т.к. предложенных тобою ключ использует для хранения временных файлов исключительно память и командой pragma указанный ключ не изменить

Мы не сможем ее смоделировать, нужны аппаратные блоки, круглосуточная запись и несколько дней непрерывной работы для определения действующего результата.
Я дома такой режим записи смоделировать не могу.
В принципе, можно разбить 40000 событий на сутки и с таким интервалом писать в базу 10 текстовых полей по 10 символов в каждом, но ждать пару дней в непрерывном режиме, это -- что-то... Но там есть еще одна особенность -- в одно время может прийти очень много событий, что движок загонит все это в буфер, в другое, они приходят медленно, и движок может успеть записать одно до прихода другого, а вот такой режим, смоделировать довольно сложно.

Хард больше подвержен старению и менее надежен, чем память, особенно, в интенсивном режиме записи

Да ладно -- PRAGMA temp_store

Редактировалось 7 раз(а), последний 2022-04-03 03:51:44

nesco, в Delphi я пользуюсь вот этим testsqlite.rar и с такими проблемами не сталкивался. Покопайся тоже (если хош)
Более подробно здесь: http://subscribe.ru/archive/comp.soft.prog.delphifaq/200801/31131653.html/

Согласен, недосмотрел
------------ Дoбавленo в 02.59:
Одно нашел и поправил, связанное с необходимостью обязательной очисткой самим буфера ошибок -- sqlite3_free(ErrorMsg)

В SqLite3Api.pas ?