Есть один запрос, вроде бы примитивный, который отрабатывает успешно в IBExpert (FIB+) и падает c Invalid BLOB ID в аппликухе (Delphi XE2 / dbExpress).

Первая библиотека коммерческая, вторая и вовсе без исходников.
Попытался задействовать Trace - https://sourceforge.net/projects/fbprofiler
К сожалению, показывает только начало и окончание выполнения запроса.
README.tracе_services из FB 2.5.9 тоже вроде показывает только это.

Пока версия, что FIB+ вычитывает все блобы непосредственно после каждой строки, а dbExpress сначала вычитывает сколько-то строк (типа, на целый экран таблицы, хотя там никакой визуальщины в этом месте нет), а потом уже пытается вычитать все блобы за послние n строк - а они уже перестали существовать.

Получить извне программ и библиотек (у dbx нет исходников в принципе) последовательности вычитывания rows и blobs на FB25 возможно?

Нет вообще, или нет в FB2 ? Вроде ещё в 2012 собирались - 13036447

Нет, там не то что транзакция, там даже statement ещё не завершился!
В том и прикол, что в IBE все было оттестировано, а аппликуха посыпалась.

Прям хоть каким-нибудь WireShark'ом смотреть и учить wire protocol......

P.S. БД, если что, прошла B&R. Перезапуск FB service и т.д.

Проверялись варианты
FB 2.1.7 win32: backup & restore & application

FB 2.1.7 win32: backup & restore; FB 2.5.9 Win64 application

FB 2.1.7 win32: backup FB 2.5.9 Win64 restore & application

----

Любопытное в трейсе для DBX, окончания выполнения выглядит как exec-stmt-finish -> commit -> close cursor -> free-stmt
Я как-то думал, что курсоры живут внутри транзакций и закрываться должны перед закрытием транзакции, но DBX думает иначе... Надеюсь, серверу от этого не хуже.

Кстати, а такие функции, как COALESCE и NULLIF - это тоже просто другая форма CASE или как-то иначе?

hvladТ.е. оно легко воспроизводится ?

Как оказалось, да.

http://tracker.firebirdsql.org/browse/CORE-6119

hvladКто собирался ? Кто вообще об этом с тех пор вспоминал ?

мониторинг запросов извне программ? да регулярно вспоминался. В том числе обсуждались подменные fbclient.dll с логированием запросов - и жаль, что таких нет в составе FB, вам казалось бы проще всего такую сделать спец-сборку...

Ты ещё учти, что вам хоть напоминай - хоть нет.
Если вам это sexy, ну типа убить Оракл и завоевать мир Большого Железа - то вы будете это делать.
Нет - нет.
http://tracker.firebirdsql.org/secure/IssueNavigator.jspa?reset=true&reporterSelect=specificuser&reporter=arioch

Симонов Денисдля начала попробуй poFetchBlobOnDemand

Для этого нужно как минимум выкинуть dbExpress и пользоваться другой библиотекой - MIDAS/CDS.

Дружище ни о каком бодании с Оракулом речи не идёт. Вот есть MySql, есть PostgreSql вот с ними по разумным фичам тягаться можно и нужно

постгрессовцы вполне бодаются с MS-SQL и Oracle где могут, так что ты только подтвердил ориентиры.

а что при этом убивается когда-то присущая IB/FB предсказуемость и лёгкость в администрировании неподготовленными пользователями - так и постгресс с ней

Симонов ДенисВот и получается, что в процессе вызова commit закрываются все курсоры и освобождаются статменты. Их трейс показывает действия самого DBX, а не сервера.

понятно, что действия DBX, но на моё взгля дпорядок действий DBX тут вывернут наизнанку, а именно - что курсор надо закрывать до коммита, а не после. Я в этом прав или нет?

1) не прав, порядок действий DBX корректен
2) вообще прав, но на практике серверу на это наплевать потoму-то и потому-то, съест и не подавится
3) прав, и в каких-то случаях может привести к проблемам

hvladВ трекере ответил.

ты чем снимал трассу, fbtracemanager? с каким конфигом?

я на реальной аппликухе fbprofiler'ом никаких левых транзакций не видел.

сейчас затащу туда вчера на коленке сделанный проект-пример и попробую с транзакциями поиграть....

как и минимум нашёлся ещё один баг DBX....

Симонов ДенисПо идее у них записи пакетами в SimpleDataSet читаются

это другая библиотека, MIDAS/CDS/как-там-её-потом-обозвали

на упрощённом сэмпле явное управление транзакциями проблему снимает.

на реальной аппликухе надо разбираться, теоретически там управление транзакциями хотя и кривое, но есть.
если потерялось, надо будет правильно его найти....

кроме того, там есть явное закрытие query, и вот эта последовательность - сначала закрываем транзакцию, а потом курсор, она вполне может получиться оттуда...

но с другой стороны, fbprofiler через traceapi вообще не видел отдельных транзакций и ошибки с блобами...

прогнал через fbprofiler исходный вчерашний сэмпл (нет явного управления транзакциями и query не закрывается), забавно....

start transaction
prepare stmt
exec stmt start
exec stmt finish

start transaction - ага, вложенная!
compile BLR
execute BLR
compile BLR
execute BLR
commit

start transaction
compile BLR
....

Забавно, т.е. чтение BLOB выполняется как почему-то два BLR-запроса, каждый из которых надо ещё компилировать (т.е. не prepared? или зачем это?..)

Симонов ДенисТеперь внимание вопрос: как ты представляешь преобразование VARCHAR в BLOB "на лету"?

select cast('abcde' as blob sub_type text) from rdb$database

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

или можно для этого случая принудительно конвертировать данные, если исправить по-другом не получается

в конце концов ровно та же проблема раньше была с добавлением not null и прочих constraint на живых данных - справились же