ОРАКУЛ: НЕТ ДАННЫХ НАЙДЕНО - но данные существуют - PullRequest
6 голосов
/ 06 декабря 2011

Отладка процедуры пакета и я не получаю данных, когда есть фактические данные.

Тестирование только SELECT

SELECT trim(trailing '/' from GL_SECURITY) as DUMMY 
FROM b2k_user@b2k
WHERE sms_username = 'FUCHSB';

Это с радостью возвращает мое значение: '23706 * 706'

Как только я пытаюсь выбрать это INTO, я получаю ошибку NO_DATA _FOUND (закомментировал обработку ошибок, которую я вставил)

set serveroutput on

DECLARE  
    p_BAS_user_name varchar2(20);  
    v_gl_inclusion varchar2(1000);
    v_gl_exclusions varchar2(1000);
BEGIN  
    --inputs
    p_BAS_user_name := 'FUCHSB';
    dbms_output.put_line(p_BAS_user_name);    
----- GOOD ----- 

    --BEGIN
      SELECT trim(trailing '/' from GL_SECURITY) as DUMMY 
      INTO v_gl_inclusion 
      FROM b2k_user@b2k
      WHERE sms_username = p_BAS_user_name;   
    --EXCEPTION
    --  WHEN NO_DATA_FOUND THEN
    --    v_gl_inclusion := 'SUPER EFFING STUPID';
    --END;    
    dbms_output.put_line(v_gl_inclusion);

END;


Error report:
ORA-01403: no data found
ORA-06512: at line 12
01403. 00000 -  "no data found"
*Cause:    
*Action:
FUCHSB

Я могу поймать ошибку просто отлично, за исключением того факта, что на основании 1-го запроса я знаю, что на 100% есть значение для FUCHSB в базе данных.

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

Спасибо


УСТРАНЕНО странное поведение разработчика SQL заставило меня пропустить потенциальные пробелы:

Похоже, что SQL Developer при запуске автономного выбора применяет свой собственный компаратор обрезки при выполнении 'WHERE sms_username = p_BAS_user_name;' часть .. оказывается, когда сидит в пакете это не .. куча пробелов была причиной проблемы .. все еще странно, что он возвращается при нормальном выборе. Спасибо, хотя!

Ответы [ 2 ]

12 голосов
/ 06 декабря 2011

Я почти уверен, что нашел причину этого поведения: я предполагаю, что столбец на самом деле имеет тип CHAR, а не VARCHAR2.

Рассмотрим следующее:

SQL> CREATE TABLE t (a CHAR(10));

Table created.

SQL> INSERT INTO t VALUES ('FUCHSB');

1 row created.

SQL> SELECT * FROM t WHERE a = 'FUCHSB';

A
----------
FUCHSB

SQL> DECLARE
  2    l VARCHAR2(20) := 'FUCHSB';
  3  BEGIN
  4    SELECT a INTO l FROM t WHERE a = l;
  5  END;
  6  /
DECLARE
*
ERROR at line 1:
ORA-01403: no data found
ORA-06512: at line 4

Заключение:

  • При работе с типом данных CHAR объявите переменные PL / SQL как CHAR.
  • Когда это возможно, предпочтите тип данных VARCHAR2 для определения столбца таблицы.Тип данных CHAR является просто раздутым типом данных VARCHAR2 и не добавляет никакой функции к типу данных VARCHAR2 (использование большего пространства / памяти не является функцией).
0 голосов
/ 27 октября 2016

Я заметил еще одну проблему для той же ошибки. ОШИБКА в строке хх: ORA-01403: данные не найдены ORA-06512: в строке хх

select abc into var from table

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...