2011-12-06 13 views
5

Il debug di una procedura di pacchetto e sto ottenendo un dato non trovato quando ci sono in effetti dati.ORACLE: NESSUN DATO TROVATO - ma i dati esistono

test appena SELECT

SELECT trim(trailing '/' from GL_SECURITY) as DUMMY 
FROM [email protected] 
WHERE sms_username = 'FUCHSB'; 

Questo restituisce felicemente il mio valore: '23706 * 706'

Non appena cerco di avere questo selezionato in ottengo un errore di NO_DATA _FOUND (commentata la gestione degli errori ho messo in)

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 [email protected] 
     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 

riesco ad afferrare l'errore bene tranne per il fatto che, sulla base della prima interrogazione so che il 100% v'è un val ue per FUCHSB nel database.

Tutte le idee .. Sto davvero iniziando a disprezzare Oracle. Sì, questa query viene eseguita su un collegamento dati come nella prima query in cui si trovano i dati.

Grazie


Risolto un comportamento strano in Developer SQL mi ha fatto trascurare il potenziale spazio bianco:

Sembra come se SQL Developer quando si esegue la versione autonoma di selezione applica un proprio comparatore rifilatura quando si fa il 'DOVE sms_username = p_BAS_user_name; ' porzione .. si scopre quando si siede nel pacchetto che non .. un mucchio di spazio bianco stava causando il problema .. ancora strano che ritorni sulla selezione normale. Grazie comunque!

+0

Il "gruppo di spazi bianchi" è il comportamento normale del tipo di dati CHAR =) –

risposta

10

Sono abbastanza sicuro di aver trovato la causa di questo comportamento: suppongo che la colonna sia effettivamente di tipo CHAR e non VARCHAR2.

Si consideri il seguente:

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 

Conclusione:

  • Quando si lavora con il tipo di dati CHAR, dichiarare le variabili PL/SQL come CHAR.
  • Se possibile, preferire il tipo di dati VARCHAR2 per la definizione della colonna di tabella. Il tipo di dati CHAR è solo un datatype VARCHAR2 gonfiato e non aggiunge alcuna funzione sul tipo di dati VARCHAR2 (consumando più spazio/la memoria non è una funzionalità).
+0

wow, buon punto! +1 –

+0

Buon posto (e bel esempio). L'unica cosa che aggiungerei alla tua conclusione sarebbe evitare di dichiarare esplicitamente i tipi di dati in PL/SQL dove possibile, dichiararlo come: l t.a% TYPE –

0

Ho notato un altro problema per lo stesso errore. ERRORE alla linea xx: ORA-01403: Nessun dato trovato ORA-06512: alla linea xx

select abc into var from table 

Se la query non restituiscono dati, al di sopra di errore buttare.

Problemi correlati