Проблема: нашими тестировщиками замечено, что если сразу после сохранения BLOBa (AppendChunk() + Update()) приложение слетает по какой-то внутренней ошибке, то BLOB не сохраняется. Причем, такое случается не всегда, а только при полной загрузке процессора. Похоже, что не сбрасываются какие-то кэши на внутренних потоках ADO, хотя соединение открывается не в асинхронном режиме. Пробовал проверять состояние рекордсета через ADODB::_IRecordset::GetState() — после Update() флаг adStateExecuting не установлен. Короче, проблема . Может, кто что посоветует?

Здравствуйте, Аноним, Вы писали:

А>Проблема: нашими тестировщиками замечено, что если сразу после сохранения BLOBa (AppendChunk() + Update()) приложение слетает по какой-то внутренней ошибке, то BLOB не сохраняется. Причем, такое случается не всегда, а только при полной загрузке процессора. Похоже, что не сбрасываются какие-то кэши на внутренних потоках ADO, хотя соединение открывается не в асинхронном режиме. Пробовал проверять состояние рекордсета через ADODB::_IRecordset::GetState() — после Update() флаг adStateExecuting не установлен. Короче, проблема . Может, кто что посоветует?

М.б. приложене слетает, не закрыв транзакцию?! Проверьте профайлером, что ухоит на сервер.

Здравствуйте, pkarklin, Вы писали:

P>М.б. приложене слетает, не закрыв транзакцию?! Проверьте профайлером, что ухоит на сервер.

Забыл сообщить одну деталь: сохраняю в базу MS Jet (Access), профайлером не посмотришь. Сохранение выполняется без использования транзакций. И еще: вылет приложения, о котором идет речь, не связан с обращением к ADO. Можно, например, просто бросить и не поймать ислючение сразу после Update(). После чего обнаруживаем, что BLOB до базы не дошел.

Здравствуйте, Аноним, Вы писали:

P>>М.б. приложене слетает, не закрыв транзакцию?! Проверьте профайлером, что ухоит на сервер.

А>Забыл сообщить одну деталь: сохраняю в базу MS Jet (Access), профайлером не посмотришь.
Важная деталь!

А>Сохранение выполняется без использования транзакций.

В этом случае по умолчанию работает автокоммит, то есть каждый запрос в своей транзакции. Если я правильно помню, в последних версиях Jet коммит по умолчанию асинхронный, то есть внутрение буфера страниц не сразу сбрасываются в файл БД. В в этом случае падение приложения до момента полной записи изменений приведет к потере данных. Связь с высокой загрузкой процессора можно предположительно объяснить тем, что сброс буферов происходит в отдельном потоке с низким приоритетом (возможно это касается только BLOB-ов).

W>В этом случае по умолчанию работает автокоммит, то есть каждый запрос в своей транзакции. Если я правильно помню, в последних версиях Jet коммит по умолчанию асинхронный, то есть внутрение буфера страниц не сразу сбрасываются в файл БД. В в этом случае падение приложения до момента полной записи изменений приведет к потере данных. Связь с высокой загрузкой процессора можно предположительно объяснить тем, что сброс буферов происходит в отдельном потоке с низким приоритетом (возможно это касается только BLOB-ов).

Спасибо за информацию, теперь многое проясняется. Рецептов лечения, как я понимаю, нет? Можно хотя бы установить момент, когда сброс завершен?

W>Если я правильно помню, в последних версиях Jet коммит по умолчанию асинхронный.

Можно ли изменить режим коммита на синхронный?

Здравствуйте, vasdm, Вы писали:

V>Можно ли изменить режим коммита на синхронный?

Можно, и режим, и задержку, и много других параметров, которые описаны в документации.

W>Можно, и режим, и задержку, и много других параметров, которые описаны в документации.

Спасибо, нашел.