БД FireBird.
Имеется запрос примерно ~12000 символов (прошу длину запроса на обсуждение не выносить, он такой есть, сильно ужаться не может).
Из IBExpert выполняется без проблем.
При выполнении из Delphi компонент TpFIBDataSet, вылазит следующая ошибка "Unexpected end of command - line 1, column 10814".
Насколько я понял компоненты Delphi при отправке запроса в Firebird нарезает его на пакеты, соответственно часть идет в одном пакете, часть в другом. Но видимо Firebird начинает его парсить и выполнять не дождавшись оставшихся пакета(ов).

Не значительно укоротив данный запрос, выполняется без проблем.
В поле TpFIBDataSet.SelectSQL - хранится весь запрос (проверял).
Обсуждений данной темы на форуме не нашел, параметры у DataSet, транзакции и БД покурил, ничего похожего что может быть связанно с моей проблемой не нашел.

Может кто то сталкивался с данной проблемой?

Мимопроходящий,

Строка подключения стандартная, несколько параметров изменено.

Версия сервера 3. (у клиента я так понимаю тоже самое).

Dimitry Sibiryakov,
Использую параметры.
Сначала все было хорошо, а у одного клиента вылезла ошибка.
Один параметр используется в 10 местах, и вместо него подставляется строка (ну вот у одного она оказалась длиннее чем у остальных, соответственно и вылезла за предел).

А что это 75000?
Когда я про символы писал, имелось ввиду, что вылезаю за пределы размера пакетов в байтах.

Мимопроходящий,
единственный закрытый параметр оказался CHARSET = WIN1251

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

Скорее всего в данном случае ФИБ+ Хрень. Пишу @PARAM.
Могу попробовать переписать на :PARAM - если это будут именно параметры.

Но есть еще один более длинный запрос, который без параметров, с ним тогда как быть?

Верно.

Спасибо за наведения на мысли.

1. GTT - это генератор? Не понял как в мое случае использовать.
2. Пока проверил в IBexpert, работает только для для in < 4, далее ничего не выводит(позже попробую в Delphi).

1. Как вариант можно рассмотреть, но не очень бы хотелось, тк сам запрос достаточно быстро выполняется;
2. Сделал тестовый запрос к одной таблице, ID - int. Может это IBexpert, что то не так делает.
(~1~2~3~) - так работает.
(~1~2~3~4~) - так уже не работает. (все значения есть, хотя и без них должно работать)

Подстановочная строка формируется правильно, взял уже значение из самого параметра.
Натолкнули меня на мысль.
Проверил, вставил "In" в данный запрос руками и скормил DataSet (без использования параметров), запрос отработал.

Предполагаю, может сам параметр обрезается при подстановке в запрос. Как проверить сформированный запрос который улетает, я не знаю как.

длина строки в параметре получается 155 символов.

сохранял в файл. Но запрос остается в чистом виде, как он и указан.
Я его сохраняю из TpFIBDataSet.SelectSQL

Вроде он все параметры подставляет непосредственно перед отправкой.

Хотя забыл, все же тут видно все взаимосвязано.
ТК уменьшив длину самого запроса, запрос выполняется и с подстановкой параметров.

Я не знаю что и думать, может как то все же нарезает, и вставляет какой то символ.

Тогда такой вопрос, как посмотреть этот ошибочный запрос.
Если нельзя из Delphi в FairBirde может есть возможность увидеть?

Спасибо за помощь, буду дальше эксперементировать.

Не особо секретный, но думаю без схемы бд особо смысла не имеет.

На текущий момент.
Исходный запрос с длинным параметром - не работает.
Исходный запрос с коротким параметром - работает.
Исходный запрос без параметра с подставленным in в тексте - работает.(длинным)

Но в файл ты сохранял, конечно же, только тот запрос, что работает.


Сохранял наоборот который не работает. Но это исходный запрос. Он между первым и вторым случаем не меняется.
Если кто знает как сохранить запрос с представленными параметрами буду признателен .

К сожаления старая версия FIB.

ReadySelectText - данной функции нет, в используемой версии FIB

Вот только по этому поводу пинать не надо, 4.77 ))

\

FB 3.0.

Трассировка ? Этот в Statement глянуть.
Пытался там отловить запрос, но как оказалось, он до туда не доходит, видимо библиотека рубит его еще до отправки.

Еще раз повторяюсь, во всех доступных полях хранятся исходные запросы, преобразование производится перед непосредственной отправкой на сервер.