Alex TorinПро какой именно код вы говорите - можете конкретизировать? Например определить на клиенте тип параметра и потом передать значение - этого достаточно?Для Where иногда - это когда?Как скомпилированная в исполняемый процессором машинный код клиентская библиотека fbclient.dll/fbclient.so должна определить тип параметра, который хотят передать в запрос? Процессоры, пока что, мысли горе-программистов читать не научились. Скажем, если в параметризованном запросе, в предложении WHERE, тип стоящего справа от оператора сравнения можно определить по типу поля, которое стоит слева от оператора сравнения, то в случае, когда исходя из подготовленного запроса тип параметра установить невозможно, разработчик БД должен задать тип параметра принудительно.
Что тут может быть непонятно?

Alex TorinНУ например непонятно то, что я его задаю принудительно в параметре на клиенте, а еще то, что этот параметр присутствует и в предложении where других select, объединенных в юнион!После чего ты задаешь его принудительно в параметре на клиенте? После того, как Prepare запроса уже вывалил ошибку? Да сколько угодно! Всё равно, что пытаться впрыгнуть с перрона в вагон поезда, который уже ушёл. Если твои UNION SELECT с, якобы, корректно заданным параметром идут после SELECT с некорректно заданным параметром, сервер не обязан "глухим дважды служить обедню" и выполнять второй проход в алгоритме подготовки запроса. Не можешь корректно задать параметры - используй EXECUTE BLOCK с типизированными входящими параметрами!

Alex TorinDimitry Sibiryakovпропущено...

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

Большинству серверов СУБД и клиентских библиотек (включая ODBC) фиолетово, как у тебя называется параметр и где еще он использован. Замени все свои параметры знаками "?" и ты, возможно, догадаешься почему. Именами параметров оперируют лишь высокоуровневые клиентские обёртки, типа FIBPlus, а всё, что ниже, использует очередность задания всех параметров независимо от имени. Иными словами, если у тебя на верхнем уровне используется лишь один именованный параметр, встречающийся в запросе трижды, то на нижнем уровне это будет три безымянных параметра.

Alex TorinНет - параметр нормально кушается, а ошибка происходит уже на стадии выполнения, отладка возвращает значения параметров, которые там присутствуют! Если вы мне объясните, как я на клиенте могу после вываливания ошибки задать параметр, то вы меня сильно удивите)))Facepalm!
Еще раз, для тех, кто в бронепоезде, объясняю, как это работает:

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

определит, что параметры с индексами 1, 4, 5 имеют имя "OWNERID", а параметры с индексами 2 и 3 имеют имя "PK_ISSUED_ID".

2. Далее, высокоуровневая обертка меняет имена параметров на символ, используемый конкретной СУБД для параметров параметризованного запроса (обычно, это символ "?") и передает модифицированный запрос на подготовку серверу. Серверу, как становится очевидно, совершенно пофиг на имена параметров, указанные в переданном высокоуровневой обёртке запросе и каждый "?" при подготовке запроса он воспринимает как отдельный параметр;

3. Если серверу удается определить все типы этих безымянных параметров и подготовить запрос, сервер возвращает нативной библиотеке количество и типы всех этих параметров, значения которых должна заполнить высокоуровневая обёртка в ранее определенной очередности, а именно - для параметров с индексами 1, 4 и 5 задать значение параметра "OWNERID", а для параметров с индексами 2 и 3 задать значение параметра "PK_ISSUED_ID";

Так работает подавляющее число СУБД, их нативных библиотек и даже ODBC с незапамятных времен, включая MS SQL, MySQL, Interbase, FirebirdSQL и прочих.
Это понятно?