обновление BLOB-объектов базы данных при сбоях OTL

Я пишу простое приложение для исправления определенного байта в двоичном двоичном объекте, который хранится в базе данных. Я использую OTL для подключения моей программы C ++ к базе данных.
Чтение данных и манипуляция работают нормально, но когда я хочу записать их обратно в базу данных, программа умирает.

Код:

try
{
std::string updateQuery = "UPDATE tbtptemplates ""  SET tptemplate=:tp<BLOB> ""WHERE afisid=:aid<INT>";

otl_long_string blob(&stp(), theSizeOfBlob);
blob.set_len(theSizeOfBlob);

otl_stream str(1, updateQuery.c_str(), theDbConnection);
str.set_lob_stream_mode(true);
str.set_commit(0);

otl_lob_stream lob;
lob.set_len(theSizeOfBlob);

str << lob;
str << theCurrentAfisId;
lob << blob;
lob.close();
}
catch (const otl_exception &oe)
{
std::cerr << oe.msg;
throw std::runtime_error("could not write to database");
}

Я подсматривал в Sourceforge для примера.

Я создаю строку otl_long_string, которая принимает данные.
Затем я создаю otl_stream и объединяю оператор SQL и соединение с базой данных.
Я использую otl_lob_stream для предоставления двоичных данных в otl_stream.
Потоковая передача BLOB-данных в otl_stream работает нормально. Но когда я передаю идентификатор потоку, процесс умирает.

Это инструкция убийцы:

str << theCurrentAfisId;

это простая переменная типа int, которую я передаю.
Эффект очень забавный: процесс не полностью умирает, исчезает только стек вызовов ниже текущего метода.
Это стек вызовов до заявление:

Thread #1 [fix_stp] 10307 [core: 7] (Suspended : Breakpoint)
Drm::TPFixer::DatabaseConnector::writeDB() at DatabaseConnector.cpp:224 0x40b565
Drm::TPFixer::DatabaseConnector::fixImpressiontype() at DatabaseConnector.cpp:139 0x40b516
Drm::TPFixer::SuperTemplateManager::fixImpressiontype() at SuperTemplateManager.cpp:67 0x4074e3
main() at main.cpp:51 0x40477b

и это полный стек в тот момент, после Инструкция:

Thread #1 [fix_stp] 10307 [core: 7] (Running : Step)
Drm::TPFixer::DatabaseConnector::writeDB() at DatabaseConnector.cpp:240 0x40b6b2

Я пытался отладить OTL. Кажется, что OTL обнаружил, что у него есть все необходимые параметры и начинает работать. В этот момент он падает.

Среда, которую я использую:
— OTL 4.0
— CentOS Linux, ядро ​​3.10.0-327.22.2.el7.x86_64
— gcc-версия 4.8.5
— Oracle 11g

У кого-нибудь есть идея?