ORA-06512 « at line » : comprendre et corriger l’erreur PL/SQL

ORA-06512 « at line n » n’est pas une erreur en soi : c’est la ligne de la pile d’appels PL/SQL qui vous dit où une autre erreur s’est produite. Le vrai problème est l’erreur affichée juste au-dessus (ORA-01403, ORA-06502, ORA-00001…). Voici comment lire cette pile et corriger la cause réelle.

Lire correctement le message

ORA-01403: no data found
ORA-06512: at "MONSCHEMA.MAJ_SOLDE", line 12
ORA-06512: at line 1

Lecture : l’erreur réelle est ORA-01403 (aucune donnée trouvée). Elle s’est produite ligne 12 de la procédure MAJ_SOLDE, appelée depuis la ligne 1 de votre bloc anonyme. ORA-06512 = le « GPS » de l’erreur, rien de plus.

Méthode de résolution en 3 étapes

1. Identifier l’erreur d’origine (la ligne du dessus)

Les plus fréquentes en PL/SQL :

• ORA-01403: no data found — un SELECT INTO ne ramène aucune ligne.
• ORA-01422: exact fetch returns more than requested rows — le SELECT INTO ramène plusieurs lignes.
• ORA-06502 — valeur trop grande / conversion impossible.
• ORA-00001 — contrainte unique violée par un INSERT.

2. Retrouver la ligne exacte du code

SELECT line, text
FROM   user_source
WHERE  name = 'MAJ_SOLDE' AND type = 'PROCEDURE'
AND    line BETWEEN 8 AND 16
ORDER  BY line;

⚠️ La ligne compte à partir du CREATE de l’objet compilé — si vous lisez le fichier source avec des en-têtes/commentaires différents, le décalage vient de là.

3. Corriger la cause — exemple type

-- ❌ lève ORA-01403 + ORA-06512 si le client n'existe pas
CREATE OR REPLACE PROCEDURE maj_solde(p_id NUMBER) IS
  v_solde NUMBER;
BEGIN
  SELECT solde INTO v_solde FROM comptes WHERE client_id = p_id;  -- ligne 12
  UPDATE comptes SET solde = v_solde * 1.01 WHERE client_id = p_id;
END;

-- ✅ gérer l'exception explicitement
CREATE OR REPLACE PROCEDURE maj_solde(p_id NUMBER) IS
  v_solde NUMBER;
BEGIN
  SELECT solde INTO v_solde FROM comptes WHERE client_id = p_id;
  UPDATE comptes SET solde = v_solde * 1.01 WHERE client_id = p_id;
EXCEPTION
  WHEN NO_DATA_FOUND THEN
    RAISE_APPLICATION_ERROR(-20001, 'Client inconnu : ' || p_id);
END;

Obtenir une pile encore plus précise

Dans vos blocs de gestion d’erreur, loggez la pile complète :

EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.put_line(DBMS_UTILITY.format_error_stack);
    DBMS_OUTPUT.put_line(DBMS_UTILITY.format_error_backtrace);
    RAISE;  -- TOUJOURS re-lever : ne jamais avaler l'erreur
END;

format_error_backtrace donne la chaîne complète des appels jusqu’à la ligne fautive — précieux quand une procédure en appelle une autre. Pour les bases : notre guide des procédures PL/SQL et le guide des triggers.

Le piège du WHEN OTHERS silencieux

Si votre code contient WHEN OTHERS THEN NULL;, l’erreur d’origine est avalée et ORA-06512 vous montrera… le mauvais endroit (ou rien). Règle d’or : un WHEN OTHERS doit logger puis RAISE.

FAQ

ORA-06512 sans autre erreur au-dessus, c’est possible ?

L’erreur d’origine est toujours là, mais votre outil ne montre peut-être que la dernière ligne. Récupérez la pile complète (SQLERRM, format_error_stack) côté application.

Pourquoi la ligne indiquée ne correspond pas à mon fichier ?

La numérotation démarre au CREATE [OR REPLACE] compilé en base, pas à la première ligne de votre fichier. Comparez avec user_source.

Comment éviter ORA-06512 en production ?

On ne l’« évite » pas : on gère les exceptions prévisibles (NO_DATA_FOUND, DUP_VAL_ON_INDEX…) et on logge la backtrace pour diagnostiquer vite les autres.