Не все переменные привязаны к Oracle

Обновлено: 30.06.2024

Две тестовые среды, каждая из которых имеет идентичные sp-файлы (плюс-минус имена баз данных и т. п.).

Вот мой код в обоих случаях:

создать или заменить процедуру HJR_TEST

v_daykey_from номер(10): = 13164;

выберите cd.daykey||cd.calendardate в v_text

с компакт-диска cds.cdsday

где vsp.daykey = cd.daykey

и cd.daykey >= v_daykey_from

Запустите это в одной среде:

Процедура PL/SQL успешно завершена.

Запустите его в другой среде:

Ошибка, начиная со строки : 18 в команде -

ORA-01008: не все переменные привязаны

ORA-06512: в "HJR.HJR_TEST", строка 7

ORA-06512: строка 2

01008. 00000 - "не все переменные привязаны"

Тот же код; те же настройки init.ora; та же версия базы данных; тот же О/С; разные результаты.

Пожалуйста, есть какие-нибудь подсказки, где мне искать проблему?!

Лучший ответ

Думаю, мне лучше обновить форум по этому поводу.

Это подтвержденная ошибка, хотя отчет об ошибке не публикуется.

В некоторых случаях оптимизатор вызывает kkpap для создания раздела

сокращение во время компиляции. Иногда обрезка разделов выполняется

запуск подзапросов к таблице. Если значения переменных связывания

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

Исправление ошибки 14458214 устранило эту проблему в случае, когда

Подзапрос использовался для сокращения на уровне раздела. Однако это

возможно, мы используем какой-то другой метод на уровне раздела, а затем используем

сокращение подзапросов на уровне подразделов; этого случая не было

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

Упомянутая ошибка имеет исправление, доступное в 11.2.0.4, и не возникает в 12c. По какой-то причине мне также указали на ошибку 17258090, но я также не могу увидеть содержимое этого отчета об ошибке. :-(

Возможный обходной путь в версии 11.2.0.3 – изменить набор сеансов "_subquery_pruning_enabled"=false; . хотя, поскольку X$KSPPI перечисляет _subquery_pruning_enabled как скрытый параметр, я предполагаю, что вы также можете установить его для всего экземпляра, хотя очевидно, что последствия для других запросов в этот момент должны быть оценены очень тщательно.

Ответы

непонятно. Убедитесь, что вы запускаете эту процедуру, а не что-то другое (разрешение имени) (пример: пересоздайте ее с другим именем: создайте или замените процедуру test_hjr_for_bruno как . тогда я уверен, что на самом деле выполняется).

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

Что произойдет, если вы запустите SELECT:

с компакт-диска cds.cdsday

где vsp.daykey = cd.daykey

и cd.daykey >= v_daykey_from

Еще кое-что: код выглядит немного странно, так как вам не нужен "vsd" ни для чего, кроме проверки существования. Поэтому я бы предпочел написать что-то вроде

ВЫБЕРИТЕ TO_CHAR(cd.daykey) || cd.calendardate

ИЗ cds.cdsday cd

ГДЕ cd.daykey >= v_daykey_from

И СУЩЕСТВУЕТ( ВЫБРАТЬ NULL

ИЗ cds.snapshot vsp

ГДЕ vsp.daykey = cd.daykey

(и замечание: вам подходит любой ряд? Разве вам не нужен "минимальный ключ дня", если их больше одного?)

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

Все, что я могу предложить, — это подход «грубой силы»: изменение одной вещи за раз, чтобы полностью изолировать вещь, вызывающую проблему.

Цель состоит в том, чтобы создать САМЫЙ ПРОСТОЙ пример (наименьшее количество таблиц, предикатов столбцов и т. д.), вызывающий проблему.

Вот краткое изложение того, что я бы проверил в первую очередь (в произвольном порядке)

<р>1. возникает ли проблема, если используется только одна таблица?

<р>2. Вы можете воспроизвести проблему, используя «двойную» или две другие новые таблицы? Если да, опубликуйте этот DDL и код.

<р>3. имеет ли значение строка, к которой осуществляется доступ? Возникает ли у вас проблема независимо от того, к какой ОДНОЙ строке осуществляется доступ?

<р>4. если вы удалите все строки, кроме одной, останется ли проблема?

<р>5. если вы удалите ВСЕ предикаты и используете только одну строку, вы можете воспроизвести проблему? Это просто выберите этот concat из таблицы cdsday.

<р>6. проверить выбор только одного из этих двух столбцов - та же проблема?

<р>7. проверить выбор только другого из двух - та же проблема?

<р>8. тестовая вставка в коллекцию (удалить проверку rownum и массовый сбор)

<р>1. это семантика BYTE или CHAR?

<р>2. одинакова ли семантика в обеих системах?

<р>3. спецификации более 2000 выделяются во время выполнения — попробуйте значение < 2000, чтобы выделить место во время компиляции. Теперь есть разница?

<р>4.на самом деле укажите 'varchar2 (100 BYTE)' - есть ли разница?

<р>1. какая разница, если вы жестко задаете значение в запросе, а не используете переменную?

Спасибо за ответ.

<р>1. Обычный выбор прекрасно работает в любой среде:

из cds.cdsday cd

где vsp.daykey = cd.daykey

и cd.daykey >= 13164

Другая информация, которую я, возможно, должен был упомянуть в первую очередь: если я перепишу процедуру ТОЛЬКО для выбора из cds.cdsday и запроса cd.daykey >= v_daykey_from, код будет работать нормально в обеих средах. Если я перепишу, чтобы выбрать только из cds.snapshot, где daykey >= v_daykey_from, он также будет работать нормально в обеих средах. Только если я выполняю соединение, как показано изначально, и запрашиваю cd.daykey>=v_daykey, происходит сбой в одной среде (в которой намного больше данных) и в другой (в которой есть некоторые данные, но не так много и не идентично ).

Хорошо, но этот "простой выбор" НЕ совпадает с опубликованным вами выбором. Когда вы не знаете, что вызывает проблему, ОБЯЗАТЕЛЬНО сохраняйте одно и то же от теста к тесту, за исключением тех вещей (обычно только одного), которые вы меняете намеренно и по определенной причине.

Хорошо и хорошо с точки зрения публикации для нас. Но ПЕРВЫЙ ШАГ в устранении неполадок запроса состоит в том, чтобы знать ПОДРОБНО, что этот запрос должен делать. Это означает, что вам (не обязательно нам) нужно знать, что это за «логическая цель». В противном случае вы не можете сказать, какие другие альтернативные «перезаписи» могут быть применимы, чтобы попытаться достичь тех же результатов другим способом.

Хммм, вы сказали "провал" в ОБОИХ случаях. Вы имели в виду успех для одного из них? Может быть тот, у которого меньше данных?

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

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

И, как было сказано в моем первом ответе, можете ли вы создать две СОВЕРШЕННО НОВЫЕ таблицы, в каждой из которых будет только строка "что-то", и воспроизвести проблему? Цель состоит в том, чтобы определить, являются ли эти две КОНКРЕТНЫЕ таблицы, которые вносят свой вклад, или это ТОЛЬКО процесс, используемый независимо от таблиц.

<р>1. Процесс (присоединение, выбор и т. д.)

<р>2. Задействованные объекты - что-то об одной из таблиц (ограничения и т.д.)

<р>3. Используемые данные.

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

Да, конечно, у вас нет этих таблиц. Вы должны поверить мне на слово, что я проверил почти все очевидное, что мог придумать. Включая проверку того, что столбцы DAYKEY действительно объявлены как тип NUMBER(10) в обеих таблицах. Преобразования типов данных не выполняются.

<р>1. возникает ли проблема, если используется только одна таблица?

Нет. Если к любой таблице запрашивается отдельно, код отлично работает в обеих средах. Только когда две таблицы соединены, как показано, в одной среде происходит сбой, а в другой нет.

Нет, я этого не пробовал и не могу придумать код, который бы подходил для этого.

Ну, если я перепишу запрос так, чтобы он стал и "rownum=9" или "rownum=1306", возникает та же ошибка. Повторите для любого значения rownum, о котором вы можете подумать, возникает та же самая ошибка «не все переменные связаны».

<р>4. если вы удалите все строки, кроме одной, останется ли проблема?

<р>6. проверить выбор только одного из этих двух столбцов - та же проблема?

<р>7. проверить выбор только другого из двух - та же проблема?

Не знаю, что это значит, но см. (1): если запрашивается только одна таблица со всеми строками, тогда это работает.

<р>8. тестовая вставка в коллекцию (удалить проверку rownum и массовый сбор)

Еще не обращался туда, потому что ваш (4), похоже, указывает на проблему с данными в таблицах, а не с кодом.

Что касается других ваших вопросов:

<р>1. Если я жестко запрограммирую 13164 в запросе, код будет работать нормально.

<р>2. varchar2 (3000) может быть varchar2 (почти все, что вам нравится). это терпит неудачу. В частности, VARCHAR2(30) был протестирован перед публикацией.

<р>3. Семантика byte и char не имеет значения. Мы используем MSWIN1252, в котором 1 символ равен 1 байту.

IE: это сработает, если я это сделаю:

создайте таблицу hjr.cdsday, выбрав * из cds.cdsday, где daykey=13164;

создайте таблицу hjr.snapshot как select * from cds.snapshot, где daykey=13164;

<р>. а затем замените в этих таблицах hjr исходные cds в моем коде.

Это также сработает, если я это сделаю

создайте таблицу hjr.cdsday как select * из cds.cdsday, где daykey=13164 и rownum

создайте таблицу hjr.snapshot как select * from cds.snapshot, где daykey=13164 и rownum < 2

Это также работает, когда я создал копии, где ключ дня > 13163, в результате чего каждая таблица имеет около 400 строк.

Я мог бы повторить эту копию таблицы, пока не найду дневной ключ, который вызывает ошибку, как я полагаю. надеялся, что не придется этого делать!

Обучение Oracle
Советы Oracle
Форум Oracle
Каталог классов

Удаленный администратор баз данных
Настройка Oracle
Экстренный вызов 911
Поддержка RAC
Поддержка приложений
Анализ
Дизайн
Внедрение
Поддержка Oracle

Настройка SQL
Безопасность
Oracle UNIX
Oracle Linux
Мониторинг
Удаленная поддержка
Удаленные планы
Удаленные услуги
Сервер приложений
Приложения
Формы Oracle
Портал Oracle
Обновления приложений
SQL Server
Концепции Oracle
Поддержка программного обеспечения
Удаленная поддержка
Разработка
Внедрение

Сотрудники консультантов
Цены на консалтинг
Требуется помощь!

Постеры Oracle
Книги Oracle
Скрипты Oracle
Ion
Excel-DB

PL/SQL ORA-01008: Не все переменные привязаны

ORA-01008: Не все переменные привязаны

myoper varchar(12);
оператор varchar(12);
лоти varchar(12);
продукт varchar(25);
квант varchar(12);

ВЫБРАТЬ nOperno ИЗ d2f_prod_0_report.factoryloops
ГДЕ wtflag = 'Y' ЗАКАЗАТЬ ПО ecdorder;

FETCH C1 INTO myoper;
ВЫБЕРИТЕ операцию, партию, продукт, количество1
FROM d2f_prod_0_report.f_lot
ГДЕ операция = :myoper
И маршрут = 'SL00.2RZS'
И продукт LIKE '% IX190%';

ORA-01008: Не все переменные привязаны

Ответ Эдварда Стовера:

Утилита err показывает это для ошибки ORA-01008:

ORA-01008 не все переменные привязаны

Причина: Оператор SQL, содержащий подстановочные переменные, был выполнен без привязки всех переменных. Все переменные подстановки должны иметь подставляемое значение перед выполнением оператора SQL.

Действие: в OCI используйте вызов OBIND или OBINDN для замены требуемых значений

Здесь многое не так. вы пытаетесь использовать переменную связывания (:myoper), которая не привязана к значению.

Кроме того, оператор select

ВЫБЕРИТЕ
операцию,
партию,
продукт,
Кол-во1
ОТ
d2f_prod_0_report.f_lot
ГДЕ
/>operation = :myoper
И
Route = 'SL00.2RZS'
И
Product LIKE '%IX190%';

нужно "выбрать в", потому что вы не можете просто так выбрать в PL/SQL. Если подумать, в этом есть смысл; если вы не выбираете или не открываете курсор, чтобы значения могли быть использованы, то вы просто выбираете, чтобы тратить время, и это не будет компилироваться.

Обучение Oracle от Дона Берлесона

Лучшие на сайте «Учебные курсы Oracle» находятся на расстоянии одного телефонного звонка! Вы можете пройти индивидуальное обучение Oracle от Дональда Берлесона прямо в своем магазине!

Бурлесон — американская команда

Примечание. Эта документация по Oracle была создана в качестве справочника по поддержке и обучению Oracle для использования нашими специалистами-консультантами по настройке производительности администраторов баз данных. Не стесняйтесь задавать вопросы на нашем форуме Oracle.

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

Ошибки? Технология Oracle меняется, и мы стараемся обновлять нашу информацию о поддержке BC Oracle. Если вы обнаружите ошибку или у вас есть предложение по улучшению нашего контента, мы будем признательны за ваш отзыв. Просто электронная почта:

и укажите URL-адрес страницы.

Burleson Consulting

Оракул поддержки баз данных

ORA-01008: не все переменные привязаны

Запрос и код следуют. Имена переменных были изменены, чтобы защитить невиновных:

Почему Oracle утверждает, что не все переменные связаны?

NullUserException: Спасибо за ссылку. Я наткнулся на это в моем Google, но никто не применил. tsells: проверю версию. Спасибо за предложение.

В некоторых документах Oracle функция Prepare() описывается как неоперативная. Однако, если это не так, это не в том месте. Подготовка инструкции имеет смысл только после того, как известны имена и типы всех параметров. Значения могут быть предоставлены позже.

8 ответов 8

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

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

Правильный способ — установить для свойства BindByName OracleCommand значение true, как показано ниже:

Вы также можете создать новый класс для инкапсуляции OracleCommand, установив для BindByName значение true при создании экземпляра, чтобы вам не приходилось устанавливать значение каждый раз. Это обсуждается в этом посте

BindByName уже имел значение true во всех случаях, когда я сталкивался с этой уязвимостью Oracle. За исключением самых тривиальных запросов, значения Oracle по умолчанию делают его почти непригодным для использования, требуя, чтобы код обновлялся каждый раз при изменении запроса.

Вау, это странно, у меня это работает нормально. У вас установлены последние драйверы клиента ODP? Если это так, вы можете открыть тикет с Oracle и сообщить об ошибке на основе вашего конкретного сценария и вашей настройки.

У нас эта проблема тоже возникает не каждый раз. В одном случае у нас был запрос, который работал нормально в течение многих лет, а затем внезапно возникла эта проблема, без внесения изменений в программное обеспечение или базу данных. Должен быть достигнут какой-то порог, установленный в оптимизаторе. Что касается поддержки Oracle, то было бы проще исправить ошибку в памяти, используя язык ассемблера Itanium, чем бороться с ними. :)

+1 к вашему решению @VijayJagdale -- я не сталкивался с этой информацией где-либо еще, и она решила серьезные, запутанные проблемы, которые у меня были, даже если они не были такими же, как у OP. ^_^

Спасибо, Скряга. И вы правы, это очень запутанно и серьезно. Когда Oracle пытается связать переменные в другом порядке, он выдает странные ошибки (например, ORA1722-invalid number) или, что еще хуже, возвращает неверные результаты выбора или вставляет/обновляет/удаляет с неправильными значениями, и это может быть очень сложно понять. , если вы не знали, что связанные переменные не синхронизированы.

Я нашел, как выполнить запрос без ошибок, но не решаюсь назвать это "решением", не понимая истинной причины.

Это больше похоже на начало моего фактического запроса:

Второй набор комментариев выше, в начале подзапроса, был проблемой. При удалении запрос выполняется. Другие комментарии в порядке. Это не вопрос какой-то мошеннической или отсутствующей новой строки, вызывающей закомментирование следующей строки, потому что следующая строка является SELECT. Отсутствующий выбор приведет к ошибке, отличной от ошибки "не все переменные привязаны".

Я поспрашивал и нашел одного сотрудника, который несколько раз сталкивался с этой проблемой — комментариями, вызывающими сбои запросов. Кто-нибудь знает, как это может быть причиной? Насколько я понимаю, самое первое, что СУБД будет делать с комментариями, — это смотреть, содержат ли они подсказки, и если нет, удалять их во время синтаксического анализа. Как обычный комментарий, не содержащий необычных символов (только буквы и точка), может вызвать ошибку? Странно.

Вы искали это на сайте поддержки Oracle? У меня есть ощущение, что это связано с ошибкой привязки. Какую версию 11 вы используете (включая версию исправления)?

Это ошибка версии R9. У нас была такая же проблема с нашими приложениями, когда вышли более новые версии оракула (odp), и нам пришлось отказаться от их поддержки. Oracle не признает это официальной ошибкой. Нам сказали, что мы должны «изменить» запросы.

У меня была такая же проблема, и это сработало для меня. Мой комментарий был в предложении select самого внешнего запроса. Большое спасибо за публикацию.

В Oracle.ManagedDataAccess 12.1.2400 в NuGet (версия файлового продукта 4.121.2.20150926) этой ошибки не было, но в более новых версиях до текущей версии 12.2.1100 она появилась. Как глупо.

У вас есть две ссылки на переменную привязки :lot_priprc -- хотя она должна требовать, чтобы вы установили значение переменной только один раз и привязали ее в обоих местах, у меня были проблемы, когда это не не работал, и приходилось рассматривать каждую копию как отдельную переменную. Больно, но это сработало.

Очень наблюдателен, и это часто проблема с Oracle, когда они используют их безумную привязку по умолчанию по положению в тексте запроса. К сожалению, я уже пытался использовать две переменные: :lot_priprc и :lot_priprc2 и связывать их по отдельности.

Жаль, что это было не так просто, мне будет интересно узнать, каково решение, и я буду продолжать думать об этом. Похоже, вы перепробовали почти все на данный момент. Я не уверен, что вы упомянули это в своем исходном сообщении — я не всегда читаю все :)

О проблеме с комментариями Чарльза: чтобы усугубить ситуацию, пусть

через параметр команды, а затем выполнить

и при изменении буквальной строки с === на ---

Оба оператора прекрасно выполняются в SQL Developer. Сокращенный код:

Итак, где-то в цепочке вызовов может быть синтаксический анализатор, который слишком агрессивно ищет однострочные комментарии, начинающиеся -- в commandText. Но даже если бы это было правдой, сообщение об ошибке «не все переменные привязаны» как минимум вводит в заблуждение.

Решение в моей ситуации было похоже на ответ Чарльза Бернса; и проблема была связана с комментариями кода SQL.

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

"ORA-01008: не все переменные связаны"

Я пробовал несколько разных вещей (файл TNSNames.ora, установленный на сервере, удаленные однострочные комментарии, проверка сопоставления запросов набора данных). В итоге мне пришлось удалить блок комментариев сразу после ключевого слова WHERE . Сообщение об ошибке было устранено после перемещения блока комментариев после условия WHERE CLAUSE . У меня есть и другие комментарии в коде. Это был только тот, что был после ключевого слова WHERE, вызвавшего ошибку.

Уважаемые друзья!
Не могли бы вы просмотреть следующий пример 1. Не знаю, в чем проблема. Не поддерживается оракулом! Заранее спасибо за помощь!

Версия БД: 10g rel2

Пример 1. Не работает – использование строки. Выдает ошибку "ORA-01008: не все переменные привязаны"
DECLARE
v_opr_sql varchar2(4000);
v_table_opr varchar2(60) := 'CM_DEPT';
v_col_string varchar2(60) := 'НОМЕР ОТДЕЛА,DNAME';
v_values_string varchar2(60) := ':1,:2';
v_using_string varchar2(256):= '10,'||'''УЧЕТ'''';
НАЧАЛО
v_opr_sql := 'ВСТАВИТЬ В '||v_table_opr||' '||
'('||v_col_string||')'||' '||
'ЗНАЧЕНИЯ'||' '||'('||v_values_string||')';
НЕМЕДЛЕННО ВЫПОЛНИТЬ v_opr_sql, используя v_using_string;
ИСКЛЮЧЕНИЕ
КОГДА ДРУГИЕ ТОГДА
ПОВЫШАЮТ;
КОНЕЦ;

Пример 2: Работает с литералами
DECLARE
v_opr_sql varchar2(4000);
v_table_opr varchar2(60) := 'CM_DEPT';
v_col_string varchar2(60) := 'НОМЕР ОТДЕЛА,DNAME';
v_values_string varchar2(60) := ':1,:2';
НАЧАЛО
v_opr_sql := 'ВСТАВИТЬ В '||v_table_opr||' '||
'('||v_col_string||')'||' '||
'ЗНАЧЕНИЯ'||' '||'('||v_values_string||')';
НЕМЕДЛЕННО ВЫПОЛНИТЬ v_opr_sql, используя 10, 'УЧЕТ';
ИСКЛЮЧЕНИЕ
КОГДА ДРУГИЕ ТОГДА
ПОВЫШАЮТ;
КОНЕЦ;

Пример 3: Работа с переменными
DECLARE
v_opr_sql varchar2(4000);
v_table_opr varchar2(60) := 'CM_DEPT';
v_col_string varchar2(60) := 'НОМЕР ОТДЕЛА,DNAME';
v_values_string varchar2(60) := ':1,:2';
номер v_deptno := 10;
v_dname varchar2(60) := 'УЧЕТ';
НАЧАЛО
v_opr_sql := 'ВСТАВИТЬ В '||v_table_opr||' '||
'('||v_col_string||')'||' '||
'ЗНАЧЕНИЯ'||' '||'('||v_values_string||')';
НЕМЕДЛЕННО ВЫПОЛНИТЬ v_opr_sql, используя v_deptno, v_dname;
ИСКЛЮЧЕНИЕ
КОГДА ДРУГИЕ ТОГДА
ПОВЫШАЮТ;
КОНЕЦ;

Ответы

Ваш код создает заполнители для двух переменных связывания. Однако ваше предложение USING в EXECUTE немедленно передает только один

P17-EMAIL — элемент текущей страницы. структура таблицы следующая:

Я не знаю, как отладить эту функцию в SQL Developer.

Лучший ответ

заявить
число;
xvarchar2(512);
начать
x:='selectcount(*)fromacl_employeeswhereUPPER(userid)=upper(:P17_MAIL)
andAPPLICATION_ID=:APP_ID';
выполнитьнемедленныйXintoY;
возвратY>0;
конец;

В коде отсутствует предложение USING, которое требуется, когда динамическая инструкция включает заполнители переменных связывания.

Вопрос в том, почему вообще используется динамический SQL? Здесь это не требуется. Используйте статический SQL, встроенный в блок PL/SQL.

Кроме того, не используйте " select count(*) from table where . " для проверки существования строки. Используйте следующий шаблон, который всегда будет возвращать либо 0, либо 1:

Это проблема с конструкциями APEX PL/SQL Function Body. За пределами APEX они не являются допустимым синтаксисом PL/SQL. Лучшей практикой является реализация необходимых функций в пакетах.Затем их можно независимо тестировать и отлаживать в SQL Developer и (повторно) использовать в других контекстах, а также вызывать из APEX.

Где и как используется этот код? Если он находится в состоянии или проверке, вместо этого используйте декларативную конструкцию SQL Exists.

Ответы

заявить
число;
xvarchar2(512);
начать
x:='selectcount(*)fromacl_employeeswhereUPPER(userid)=upper(:P17_MAIL)
andAPPLICATION_ID=:APP_ID';
выполнитьнемедленныйXintoY;
возвратY>0;
конец;

Это проблема с конструкциями APEX PL/SQL Function Body. За пределами APEX они не являются допустимым синтаксисом PL/SQL. Лучшей практикой является реализация необходимых функций в пакетах. Затем их можно независимо тестировать и отлаживать в SQL Developer и (повторно) использовать в других контекстах, а также вызывать из APEX.

Читайте также: