Pourquoi Oracle ne vous dit pas QUELLE table ou vue n'existe pas ?

Question

Si vous avez utilisé Oracle, vous avez probablement reçu le message utile "ORA-00942 : Table or view does not exist". Y a-t-il une raison technique légitime pour laquelle le message n'inclut pas le nom de l'objet manquant ?

Les arguments selon lesquels cela est dû à la sécurité semblent avoir été élaborés par la TSA. Si je suis un attaquant, je saurais quelle table je viens de tenter d'exploiter et je pourrais facilement interpréter ce message inutile. Si je suis un développeur travaillant avec une jointure complexe à travers plusieurs couches de code d'application, il est souvent très difficile de le savoir.

Je pense que lorsque cette erreur a été implémentée à l'origine, quelqu'un a négligé d'ajouter le nom de l'objet, et maintenant, les gens ont peur de briser la compatibilité pour le corriger. (Le code faisant des choses idiotes comme analyser le message d'erreur sera confus si cela change).

Existe-t-il un moyen convivial pour le développeur (par opposition au recrutement de votre DBA) de déterminer le nom de la table manquante ?

---

Bien que j'aie accepté une réponse pertinente pour le sujet, elle ne répond pas vraiment à ma question : Pourquoi le nom ne fait-il pas partie du message d'erreur ? Si quelqu'un peut trouver la vraie réponse, je serai heureux de changer mon vote.

Answer 1

Vous pouvez définir un EVENT dans votre fichier de paramètres (texte brut ou spfile) pour forcer Oracle à transférer un fichier de trace détaillé dans le répertoire user_dump_dest, le nom de l'objet peut y être, sinon le SQL devrait y être.

EVENT="942 trace name errorstack level 12"

Si vous utilisez un fichier texte brut, vous devez conserver tous vos paramètres EVENT sur des lignes consécutives. Je ne sais pas comment cela s'applique à spfile.

Answer 2

SQL*Plus vous indique la table qui n'existe pas. Par exemple :

SQL> select
  2     *
  3  from
  4     user_tables a,
  5     non_existent_table b
  6  where
  7     a.table_name = b.table_name;
   non_existent_table b
   *
ERROR at line 5:
ORA-00942: table or view does not exist

Ici, il montre le nom de la table manquante et le numéro de ligne dans l'instruction SQL où l'erreur se produit.

De même, dans une instruction SQL d'une ligne, vous pouvez voir l'astérisque qui met en évidence le nom de la table inconnue :

SQL> select * from user_tables a, non_existent_table b where a.table_name = b.table_name;
select * from user_tables a, non_existent_table b where a.table_name = b.table_name
                             *
ERROR at line 1:
ORA-00942: table or view does not exist

En ce qui concerne votre question, je suppose que la raison pour laquelle le message d'erreur n'inclut pas le nom de la table est que le message d'erreur lui-même doit être un texte statique. Le numéro de ligne et l'emplacement dans la ligne de l'erreur sont clairement transmis à SQL*Plus (d'une manière ou d'une autre).

Answer 3

Je ne suis pas d'accord avec l'opinion selon laquelle SQL+ vous permet de comprendre quel nom de table est inacceptable. Il est vrai que cela aide dans les DML directs, bien que leur analyse soit très difficile. Mais quand il s'agit de dynamique, nous n'avons aucune aide :

SQL> begin
  2  execute immediate 'insert into blabla values(1)';
  3  end;
  4  /
begin
*
ERROR at line 1:
ORA-00942: table or view does not exist
ORA-06512: at line 2

Answer 4

Si vous utilisez un outil d'exploration SQL comme TOAD ou TORA, il vous aidera à détecter les erreurs ORA en mettant en évidence ou en déplaçant le curseur à l'endroit où vous avez commis votre erreur.

Copiez et collez votre SQL dans l'un de ces outils pour vous aider. Les informations d'analyse disponibles peuvent également vous être utiles.

Answer 5

Je n'ai jamais eu de problème d'interprétation des messages d'erreur d'Oracle. Cela s'explique en partie par le fait que tous les outils interactifs que j'ai vus pour développer le langage SQL pour Oracle indiquent de manière utile l'endroit où la requête s'est trompée. Cela inclut SQL*Plus, comme d'autres l'ont noté, et le module Perl DBI :

$ exec_sql.pl 'select * from daul'
DBD::Oracle::db prepare failed: ORA-00942: table or view does not exist (DBD ERROR: error possibly near <*> indicator at char 14 in 'select * from <*>daul') [for Statement "select * from daul"] at exec_sql.pl line 68.

Eh bien, cela est un peu difficile à lire car tout est regroupé sur une seule ligne. Mais un outil GUI serait capable de pointer le token où Oracle a commencé à avoir des problèmes avec la requête. Et avec un peu de travail sur un analyseur syntaxique, vous pourriez écrire un outil pour identifier la table en question.

Pour répondre à la question sous-jacente, les erreurs Oracle ne semblent pas être conçues pour fonctionner comme vous l'attendez. Pour autant que je sache, aucun des messages d'erreur d'Oracle ne prend en charge le texte variable. Au lieu de cela, Oracle renvoie deux éléments d'information : un numéro d'erreur et un emplacement où l'erreur se produit. Si vous disposez des outils appropriés, il est assez facile de diagnostiquer une erreur à l'aide de ces éléments d'information. On peut dire que le système d'Oracle est plus agréable pour les créateurs d'outils que celui qui fournit des quantités variables de données de diagnostic en fonction de l'erreur. Imaginez devoir écrire un analyseur syntaxique personnalisé pour tous les messages d'erreur d'Oracle (y compris les erreurs futures) afin de mettre en évidence l'emplacement incriminé.

Parfois, il serait trompeur d'inclure le nom de la table. Le fait de savoir où les choses se sont mal passées peut être d'une grande aide :

SQL> select * from where dummy = 'X';
select * from where dummy = 'X'
              *
ERROR at line 1:
ORA-00903: invalid table name

Quant à savoir pourquoi Oracle a choisi de procéder de cette manière, j'ai quelques spéculations :

1. IBM a utilisé ce style de message d'erreur pour System R, que Larry Ellison, Bob Miner et Ed Oates ont copié pour construire Oracle V2. (Rétrocompatibilité.)

2. Le numéro et l'emplacement de l'erreur sont la plus petite représentation possible des informations de diagnostic. (Parsimonie.)

3. Comme je l'ai indiqué ci-dessus, pour simplifier la création d'outils qui se connectent à Oracle. (Interopérabilité.)

Dans tous les cas, je ne pense pas qu'il faille être un DBA pour savoir quelle table n'existe pas. Il suffit d'utiliser les outils appropriés. (Et ajuster vos attentes, je suppose).