Думаю полезно было бы опцию "Export values of BLOB fields as hex strings" инструмента "Экспортировать данные в скрипт", выделенную на приложенном скриншоте, перенести также в инструмент "Сравнение данных таблиц" (на страницу "Доп. настройки" наверное), а по возможности вообще унифицировать имеющиеся опции настройки результирующего SQL-скрипта обоих инструментов. Теперь для чего это понадобилось мне. Я написал приложение для подгрузки SQL-скрипта по списку однотипных баз. Скрипты для подгрузки получаю при помощи инструментов "Сравнение данных таблиц" и "Сравнение БД" путем сравнение девелоперской базы данных с какой-нибудь из остальных, но первый инструмент "Сравнение данных таблиц" для BLOB полей прописывает в скрипте ссылки на содержимое файла с расширением .lob, а хотелось бы иметь возможность получать самодостаточный SQL-скрипт, а для этого именно вышеуказанной опции в моем случае и не достает. P.S.Благодарю за такой чудесный инструмент как IBExpert.

Ограничение, я так понимаю, связано с тем, что: "Максимальная длина строки для типа VARCHAR составляет 32765
байт (32767 для типа CHAR). Если значение должно быть записано в столбец типа BLOB, то
максимальная длина строкового литерала составляет 65535 байт". Это верно в том числе и для Firebird 3. Также у Firebird 2.5 и ниже есть ограничение на размер самого тела запроса, в Firebird 3 для нового API это ограничение практически убрали - выдержка из Release Notes:
"If and only if the new API is being used.-

The size of the body of a stored procedure or a trigger can exceed the traditional limit of 32 KB. The theoretical limit provided by the new API is 4GB. At the moment, as a security measure, a hard-coded limit of 10MB is imposed. The same limit of 10MB also applies to any user-defined DSQL query.

The total size of all input or output parameters for a stored procedure or a user-defined DSQL query is no longer limited to the traditional size of (64KB minus overhead). The theoretical limit provided by the new API is 4GB".

В базах данных СУБД Firebird, с которыми мне приходилось работать, зачастую в BLOB-полях сохранялись всяческие настройки и в подавляющем количестве случаев размер хранимого значения не превышал вышеуказанного лимита в 65535 байт. Наверное, лучшим решением было бы при включенной опции "Export values of BLOB fields as hex strings" проверять размер получаемого литерала в запросе и при превышении лимита в 65535 байт, выдавать предупреждение, формировать lob-файл и вставлять в запись ссылки на него, то есть действовать по текущему алгоритму. В любом случае, несмотря на ограничения, данная опция в инструменте "Экспортировать данные в скрипт" присутствует и значит там она имеет смысл, поэтому не вижу почему она теряет смысл в аналогичном скрипте, только полученном другим способом. Решать конечно вам, стоит такое реализовывать или нет, потому что я не берусь оценивать трудоемкость реализации предложенного, хотя пользу в этой опции вижу.

Спасибо, что поддерживаете дискуссию. Ваши доводы я прекрасно понимаю и с ними согласен в том смысле, что опция получается неуниверсальной и не всегда может быть применена. Уже понял, что можно написать обработчики OnBeforeStatementExecute и OnAfterStatementExecute в TpFIBScripter (использую его для работы со скриптами в своем приложении), где отдельно передавать содержимое .lob-файла. Просто .lob-файл - это формат, завязанный на IBExpert, и поэтому у скрипта, который можно запросто выполнять в любом инструменте исполнения скриптов, есть свои неоспоримые плюсы. А с учетом вышеприведенных мной последних изменений, касающихся увеличения размера запроса до теоретически возможного размера в 4 ГБ, есть вероятность, что для литералов, присваиваемых блоб-полям, ограничение также в будущем могут соответственно увеличить (не вижу препятствий почему бы это не сделать, плюс тенденция уже есть - для тройки уже увеличили в 2 раза). Что касается IBExpertчтобы воспользоваться этой опцией, нужно быть уверенным, что все блобы во всех выборках не жирнее лимита. И если с одной выборкой в интерактивном режиме еще как-то можно быть уверенным в этом, то при сравнении кучки таблиц в БД можно только надеяться в абсолютном большинстве случаев.
, то IBExpert ведь гибкий инструмент и предоставляет возможность пометить галочками таблицы, участвующие в сравнении, и ничто не мешает такую опцию применять только к той выборке таблиц, на счет которых точно уверен, что значения в их блоб-полях точно попадают в лимит, а остальные таблицы сравнивать отдельно. Как уже писал выше зачастую в блоб-полях хранятся всяческие функциональные настройки, которые сродни метаданным базы (в том смысле, что они не являются данными предметной области, а влияют на функционирование системы) и которые надо разносить по всему списку однотипных баз, и в базах, с которыми я работаю, они нигде не дотягивают до лимита в 64 КБ (для наглядности - размер файла firebird.conf у Firebird 2.5, подавляющую часть места в котором занимают комментарии, составляет по умолчанию 28 КБ), и опять же повторюсь, что при превышении этого лимита целесообразно добавлять всё же в .lob-файл значение текущей проблемной записи, а в конце всего сравнения выдавать соответствующее предупреждение о том, что к части записей применить данную опцию невозможно, поэтому сформирован .lob-файл. Думаю такая реализация была бы и гибкой, и безопасной, потому что уверенность в отсутствии "жирных" блобов в выборке становится необязательным требованием для получения работоспособного скрипта, пусть и без выполнения опции, которую оказалось невозможно выполнить, но о чем выдается предупреждение.

Я знал об ограничении на размер самого запроса - 64 КБ, потому что было дело - славливал ошибки, связанные именно с этим ограничением при выполнении запросов, где есть большие строки. Про размер литерала как-то даже не задумывался, потому что не припомню, чтобы сталкивался с такой ошибкой на практике. А вообще интересно что сейчас делает инструмент "Экспортировать данные в скрипт" с включенной опцией "Export values of BLOB fields as hex strings", если строка всё таки превышает предел? Формирует скрипт, который при выполнении вызовет ошибку? Да в общем вы разработчик, у вас опыта больше насчет того, что стоит делать, а что нет. Так что если считаете, что не нужна эта опция, то не делайте, не тратьте время. Наверняка сейчас есть функционал поважнее, который нужно реализовывать прямо сейчас. Ваша работа слишком важна, чтобы тратить её на ненужные хотелки отдельных субъектов вроде меня. И я это говорю без тени иронии, потому что использую IbExpert уже лет 5 и считаю его настоящим эталоном подобных программ, при том что для WIN1251 он ещё и бесплатный. А эту опцию сделаете, если на неё будет реальный спрос в будущем. Лично я просто допишу приложение своё, чтобы работало с файлами .lob. Это несложно и недолго. Спасибо, что рассмотрели моё обращение. Думаю на этом можно остановиться.