Есть один запрос, вроде бы примитивный, который отрабатывает успешно в 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 на живых данных - справились же

A.S. в проблемное место аппликухи воткнул локальную транзакцию - и invalid BLOB id действительно ушёл.

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

Симонов ДенисТебе прям точно нужен этот глючный dbExpress? Заменить его никак?

во всей аппликухе, которой больше 10 лет? малореально.

не говоря про необходимость тогда покупать новую библиотеку доступа (или новую Dlephi со всеми новыми библиотеками) в количестве нескольких штук, и... тирьям-пам-пам - находить и изучать новые баги и новые пути их обхода.

Симонов Денисс какого перепуга она на закладке dbExpress?

а хрен его знает, но если наведёшь на него мышку, увидишь, что он в пакете dcl-dbx-cds
CDS - это ClientDataSet, MIDAS, тот ещё мега-комбайн
а в SDS поверх CDS навернули ещё каких-то рюшек...

Ну, собственно говоря, главное что навернули - это навигацию по записям вперёд-назад, потому что у Firebird большинство запросов - однонаправленные. Видимо, это была основная цель, не перетаскивать в SQLQuery буферизацию из например TBDEDataSet, а просто сделать поверх.

Симонов ДенисAriochЗабавно, т.е. чтение BLOB выполняется как почему-то два BLR-запроса

не обязательно 2 может и больше. Сначала открытие блоба, а потом посегментное чтение. сегментов может быть больше чем 1.

Ещё забавнее, что чтение блобов было хотя и из ДРУГОЙ транзакции, но из ВЛОЖЕННОЙ (или параллельной), т.е. вообще говоря сами-то блобы должны были существовать, потому что создавшая их транзакция не закрывалась!

Т.е. тут похоже дело не в том, что временные блобы уничтожались, а в том, что к ним доступа не было!
Но поскольку такой ошибки не было предусмотрено - выдавалась Invalid BLOB id....

Возможно, для таких случаев стоило бы завести отдельный текст ошибки, чтобы сразу различать случаи "блоба нет вообще", и "блоб есть, но не для тебя". Раз уж блобы - больная тема с пониженнйо предсказуемостью...

Тут ещё ньюанс, что в dbx3/delphi2006 были параллельные транзакции, а dbx4/xe2 только вложенные в виде стека.... Т.е. с точки зрение "верхнего уровня" dbx - вторичные транзакции возможно должны были наследовать права доступа от родительской? хотя х.з. что там авторы dbx4 думали в этот момент.


Dimitry SibiryakovАффтар, проверил бы ты это поведение на четвёрке. Туда, кажется, приняли мой патч по
предотвращению преждевременного удаления блобов.

интересно, а как ты формулируешь "преждевременное" ?

поскольку reference counting надёжно протащить из FB engine аж в недра аппликухи, хрен знает на чём написанной, в общем виде нельзя - то тут выбор между Сциллой и Харибдой, откуда чаще прилетает.

Ну и да, проверить поведение - открой ссылочку на трекер и возьми готовый EXE, запусти и нажми кнопку
Таки проще, чем мне искать FB4, ставить его, разбираться как там пользователей создают и т.д.

Basil A. SidorovAriochа что при этом убивается когда-то присущая IB/FB предсказуемость и лёгкость в администрировании неподготовленными пользователями - так и постгресс с нейFB версий от 1.5 до 3.0 администрируется совершенно одинаково.
Да, админ может быть не в курсе каких-то фичей FB, ну так админу это и не требуется.

Смешно. Просто почитай в интернете кучу проблем, когда пользователи не могли создать SYSDBA или создавали, но не так, или не там и т.д.

Или когда вместо отдельного сервера внезапно запускается embedded, потому что в FB3/win теперь совсем не так, как в IB/FB0-1-2/Win

Basil A. SidorovДа, админ может быть не в курсе каких-то фичей FB, ну так админу это и не требуется.

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

Симонов Денис,

для этого мне нужно сочинять бронебойный метод перехода с FB2.1 с литералами кирилицей в PSQL, который будет работать всегда, а когда не будет - "идиоты на телефоне" у них и у нас смогут без меня это быстро порешать.

и при этом ещё недопустить ни у кого глюков из-за внезапного embedded (CORE-5004/CORE-5185)
а на демо-версии - ровно наоборот, гарантировать работу с файлом БД исключительно через embedded без установки standalone сервера и без неожиданных попыток соединиться через отдельный fbserver.exe

и ещё объяснить всем остальным, зачем я вообще эти проблемы создаю клиентам и нам самим

ради CORE-4641/CORE-5186 я бы даже попробовал, при прошлом начальстве особенно.
но и нынешнему я бы сходу привёл несколько случаев проблем клиентов, которые бы сразу исчезли. В основном типа "перенос на новый сервер"

вот лично с моей колокольни, лишние 50% производительности на терабайтной БД совершенно не имеют значения с беспроблемностью у пользователей класса "бабушка божий одуванчик"

Ariochне имеют значения с беспроблемностью

....сравнительно с беспроблемностью....

Симонов Денис,

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

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

так что я не плачусь, я напоминаю и разъясняю

hvlad- временный блоб с blob_id 1 в тр-ции A это совершенно не то же самое, что временный блоб с blob_id 1 в тр-ции B
- доступ к блобам тут не при чём

может быть лучше это было бы изменить, чтобы id временных блобов не пересекались?

именно потому, что они уходят наружу и там с ними аппликухи делают что хотят

ну и кроме того

Симонов Денисотдельная ошибка по поводу прав на чтение временного (и не только) блоба из другой транзакции недавно добавлена в 3.0.4.

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

hvlad,

это не спасёт, но поможет их исправить

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

и да, особенно "с точки зрения пользователя" - потому что даже если пользователь сможет надёжно воспроизвести (не всегда), не факт что возможна поездка разработчкиа к нему или передача всех данных от него.

навскидку, сделать отдельный "в памяти" генератор для temporary blob id или просто в temporary blob id в старших разрядах хэшировтаь transaction id - не сильно нагрузит сервер, зато поможет распознавать разные ошибки

Dimitry SibiryakovНу ок, давай в isc_blob_open() добавим ещё один параметр - транзакцию и задокументируем, что это должна быть та самая транзакция в которой получен blob id. Кому от этого станет лучше?

не надо, надо просто сделать чтобы ID временных блобов не пересекались между транзакциями с вероятностью 99,999% и это не трудно

лучше будет разработчикам софта под FB и пользователям этого софта, у которых вместо ошибки "Firebird опять не находит BLOB, с ним такое бывает" будет четкая ошибка одного из трех выше описанных видов.

почитайте что ли какое-нибудь сравнение ошибок в GCC и CLang именно в разрезе понятности "а что случилось и теперь делать-то?". Разработчики CLang, в отличие от разработчиков GCC, посчитали, что понятные сообщения об ошибках - это хорошо. Возможно, они ошибаются.


Basil A. SidorovНет желания работать с FB4 - не работай

вообще-то это МНЕ предлагали "работать с FB4", а я - отказался. Так что эта твоя филиппика - к предыдущему оратору.

Basil A. SidorovБыл эпизод, когда лично я, собственными руками, создал проблему для, примерно, 80% пользователей этой системы. И ничего, не сломался за оставшийся рабочий день...

Т.е. ты предлагаешь мне намеренно создать проблему? Или к чему это было?
Причём проблему отложенную на случайный от нас не зависящий момент, не "мой рабочий день", а - и я про это писал - "решать в моё отсутствие"/
Т.е. твой "контр-пример" - он вообще не о том.

Basil A. Sidorovне вы один попадали в "сложные жизненные ситуации".

вы мне предлагаете не случайно попасть в неё, а созщдать совбственными руками, да ещё доказать начальств, что создавтаь её нужно. Зачем настолько топорно передёргивать?

Basil A. SidorovА вот лично у меня - совершенно противоположное мнение

Поэтому я и говорю, что у разработчиков FB цель - переораклить оракл, а "беспроблемное существование программ малого и среднего размера" когда-то бывшее нишей IB и причиной его распространения их перестало занимать. Ты это сейчас просто подтвердил. Это для меня не новость.

Симонов Денис,

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



Dimitry Sibiryakov,

Ну т.е. Firebird - это такая СУБД для 1% самых лучших разработчиков, и за эту привилегию надо держаться, и не упрощать жизнь 99% других разработчиков, чтобы они не полезли своими грязными лапами к элитной жар-птице

вполне чёткое позиционирование, респекут и уважуха

Dimitry Sibiryakov,

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

вообще говоря, тут надо или трусы или крестик

либо "никто не против" улучшать сообщения об ошибках FB, чтобы помогать разработчикам приложений, как ты пишешь сейчас.

либо разработчики приложений "рукожопы", а желание улучшать сообщения об ошибках FB - лицемерие", как ты писал на прошлой странице