есть процедура

CREATE OR REPLACE PROCEDURE FE_SP_FM_CheckOperAcc
  (hdebet RAW, hcredit RAW, icurrency RAW, ctdate date)
is
      debet_iplan RAW(16);           credit_iplan RAW(16);
      debet_priority NUMBER;         credit_priority NUMBER;
      debet_ctdateb date;            credit_ctdateb date;
      debet_ctdatee date;            credit_ctdatee date;
      debet_chblocking number;       credit_chblocking number;
      debet_chend number;            credit_chend number;
      debet_chregister number;       credit_chregister number; -- Основная учетная валюта
      debet_chcurrency number;       credit_chcurrency number; -- другая валюта
      debet_icurrency RAW(16);       credit_icurrency RAW(16);
      user_priority NUMBER;
BEGIN

   SELECT FE_FLD_IPLAN, FE_FLD_CTPRIORITYUSE,FE_FLD_CTDATEB,FE_FLD_CTDATEE,FE_FLD_CHBLOCKING,
            FE_FLD_CHEND,FE_FLD_CHREGISTER,FE_FLD_ICURRENCY,FE_FLD_CHCURRENCY
   INTO  debet_iplan, debet_priority, debet_ctdateb,     debet_ctdatee,    debet_chblocking,
            debet_chend, debet_chregister, debet_icurrency,    debet_chcurrency
   FROM  FE_TBL_ACC c     where c.fe_fld_pkguid = hdebet;
--   Raise_application_error(-20000, hdebet);
END;

1) Если выполнить вручную селект с тем hdebet,
которое туда приходит (проверял), то возвращается 1 строка
(как и должно быть)
2) если выполнить процедуру на клиенте через ADo.ORaOleDB,
то летит ошибка



ORA-01403: no data found
ORA-01403: no data found
ORA-06512: at "FEB_WORK.FE_SP_FM_CHECKOPERACC", line 89
ORA-06512: at "FEB_WORK.FE_SP_FM_INSERTSALDO", line 11
ORA-06512: at "FEB_WORK.FE_T_OPER_IN_CUS", line 2
ORA-04088: error during execution of trigger 'FEB_WORK.FE_T_OPER_IN_CUS'
ORA-06512: at "FEB_WORK.FE_SP_INSERT", line 33
ORA-06512: at line 1


3) Если раскомментировать raise в конце процедуры,
то просто выводится значение hdebet в ошибке
(причем, чтобы оптимизатор не соптимизировал что-то,
я выводил таку переменную значениекоторой невозможно
определить без выполнения всей процедуры)


ГДЕ ГРАБЛИ ГОСПОДА ?!.. Где они родимые спрятались?


Еще есть такая лажа...


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

ORA-03113 end-of-file on communication channel

Здравствуйте, kto-to, Вы писали:

Если процедура так же глючит при выполнении с сервера — пройдите ее отладчиком. Если не глючит — смотрите на подключение из Вашей программы, текущего пользователя, настройки FGAC и так далее.

Этот селект — 89-я строка процедуры?

Протрассируйте сессию с вызовом этой процедуры. Вся ситуация, да и двойной no data found подталкивают к мысли, что втихаря выполняется еще какой-то код, в котором, собственно, и зашита проблема.

Попробуйте эквивалентные изменения, например, перепишите select into на for — увидите возвращаемую (пустую) выборку либо тот же no data found?

Здравствуйте, Softwarer, Вы писали:
S>Если процедура так же глючит при выполнении с сервера — пройдите ее отладчиком. Если не глючит — смотрите на подключение из Вашей программы, текущего пользователя, настройки FGAC и так далее.
Глючит именно из софтины. Я проверял, что, например, глюка с коммитом нет при выполнении в
PL\SQL Developer

S>Этот селект — 89-я строка процедуры?
Сообщения об ошибке отличаются только номером строки,
Который всегда указывает на этот селект.
Я взял одно из этих сообщений.
В тексте процедуры я выкинул лишние комментарии.
В моем варианте сейчас стразу за закомментированным raise идет return;

S>Протрассируйте сессию с вызовом этой процедуры. Вся ситуация, да и двойной no data found подталкивают к мысли, что втихаря выполняется еще какой-то код, в котором, собственно, и зашита проблема.
Я это вижу, но почему на простом SELECT INTO выполняется 2-ной селект?!!

S>Попробуйте эквивалентные изменения, например, перепишите select into на for — увидите возвращаемую (пустую) выборку либо тот же no data found?

Не понял? Это как?

Здравствуйте, kto-to, Вы писали:

KT>Глючит именно из софтины. Я проверял, что, например, глюка с коммитом нет при выполнении в
KT>PL\SQL Developer

Значит, прямо при коннекте Вашей софтины включайте максимально полную трассировку и смотрите, что она делает. Включать можно на системном триггере на событие after logon. Как включать трассировку — недавно была тема на sql.ru в форуме по ораклу; может, уже добавили в FAQ.

S>>Протрассируйте сессию с вызовом этой процедуры. Вся ситуация, да и двойной no data found подталкивают к мысли, что втихаря выполняется еще какой-то код, в котором, собственно, и зашита проблема.
KT>Я это вижу, но почему на простом SELECT INTO выполняется 2-ной селект?!!

Аудит? FGAC? Это и надо выяснить — кто его выполняет. Для этого в первую очередь и делается трассировка — она покажет куда более точную картину происходящего.

S>>Попробуйте эквивалентные изменения, например, перепишите select into на for — увидите возвращаемую (пустую) выборку либо тот же no data found?
KT>Не понял? Это как?

Напишите вместо select into цикл for по курсору, в котором присваивайте полям значения из курсора. Если все равно получите no data found — это железно докажет, что Ваш код тут самым немыслимым боком не при чем.

Здравствуйте, kto-to, Вы писали:

KT>1) Если выполнить вручную селект с тем hdebet,
KT>которое туда приходит (проверял), то возвращается 1 строка
KT>(как и должно быть)
KT>2) если выполнить процедуру на клиенте через ADo.ORaOleDB,
KT>то летит ошибка

А как байндится hdebet (RAW) на клиенте? Есть подозрение, что условие "where c.fe_fld_pkguid = hdebet" не выполняется из-за неверной передачи hdebet. Попробуй в том же клиентском коде на ADO, который вызывает процедуру, заменить вызов процедуры на простой

select * from fe_tbl_acc  where fe_fld_pkguid = :bound_hdebet;

и сделай bind переменной bound_hdebet на то же значение, что передается в процедуру.

Можно также попробовать объявить и передать параметр процедуры как VARCHAR2, а в условии поставить
where fe_fld_pkguid = utl_raw.cast_to_raw(hdebet).