Доброго всем времени суток, уважаемые.

Столкнулся со следующей проблемой при переходе с Firebird 2.5 на Firebird 3.0
В частности, в 3.0 стало нельзя указывать алиасы к полям русскими буквами более чем из 16 символов, тогда как в 2.5 это было возможно (32 русских ANSI-символа на ура работали).

Вот такой запрос выполняю под FB2.5, все работает прекрасно:



беру этот же запрос выполняю под 3.0 и получаю:


Если в алиасе изменить раскладку, то запрос выполняется:


Заметил такую особенность в 3.0:
Всего под алиас выделяется 32 байта (максимальное количество символов при этом латинских 31, кириллица - 15), латинские символы в алиасе занимают по одному байту, а кириллица по два, тоесть можно написать, например, так:


Этот запрос не выполняется, хотя общая длина символов 29, если принять ту арифметику что я писал чуть выше, то получается 26 + 2*3 = 32.
Если же мы уберем любую одну латинскую букву, то запрос выполняется.

Кто что думает по этому поводу?

Выходит это тупиковый фактор, при переходе на 3.0
У меня большое приложение где алиасы к полям используются во всю. Переделать это если невозможно, то почти не реально.

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

Ну а что тут странного? Имеется некоторый движок по генерации отчетов, у которого на входе SQL, где все колонки названы так, чтобы пользователю было понятно их содержание, движок просто берет файл с текстом запроса, подгружает его к себе, выполняет и выводит содержимое в удобочитаемом для пользователя виде.

Я же в предыдущем письме объяснил зачем это надо.
Денис, с какой целью ты мне говоришь, что "обычно запросы используются для извлечения и модификации данных"? (вопрос риторический)

Еще раз о вышесказанном, движок отображения отчетов один, файлов sql сотни, движку пофиг какие там поля он знать об них ничего не знает, его задача подгрузить файл с запросом, выполнить его и нарисовать таблицу, поэтому в каждом файле запроса, колонки названы так чтобы пользователям нашей программы было понятно название колонок вместо всяких "PERCENT_EXEC_WORK" и т.п.
Это ведь совершенно понятно должно быть?!

Всем большое спасибо, за ответы, посоветовались с коллегами и прислушавшись к вашим мнениям, решили таки парсить SQL перед его выполнением и изменять его так чтобы в нем осталось только оригинальное имя поля, а название на русском собирать в нейкий лист-словарь(field_name=alias_name) для каждого файла, а затем, после того как SQL выполнится в датасете пробежаться по его FieldList-у (программируем в Delphi) и проставить каждому полю DisplayLabel взяв значение из "словарика".

Вкратце отвечая на вопросы выше: "Почему нельзя так, а почему эдак..."
Есть некие ограничения по работе с этим "движком", это FastCube 2.0, исходников, к сожалению, нет, поэтому все делается методом "научного тыка" этак "лишь бы заработало".

авторФИБовские датасеты, кстати, умеют такое из коробки.
Немного не по теме, у датасетов фибовских на трешке сейчас надо выставлять опцию psUseLargeIntField в PrepareOptions.
Так, например,

теперь возвращает BIGINT вместо INTEGER.
Если этого не сделать, то можно получить ошибку о не соответствии ожидаемого типа поля и актуального.