Récupérer le nom d'une table à la volée

**JuJuLaTordue** · 08/04/2008, 11h23

Bonjour à tous,

Je cherche à retourner (via un trigger) le nom de toutes tables altérée/modifiée/updatée/... dans une procédure afin de générer un document xml portant le nom de la table et mis à jour à chaque modif.

Existe-il une telle information dans le dictionnaire de données ? Ou tout autre possibilité ?

Ps : Je suis sous Oracle 8i

**mnitu** · 08/04/2008, 11h45

Regarde le chapitre 13 dans Oracle8i Application Developer's Guide - Fundamentals

**JuJuLaTordue** · 08/04/2008, 12h10

Oui merci bon lien, mais je n'ai pas vu de possibilité de retourner le nom de la table modifiée ?

**pifor** · 08/04/2008, 13h34

http://www.developpez.net/forums/sho...d.php?t=378704

**laurentschneider** · 08/04/2008, 13h46

Dans le cas d'un DDL, tu peux employer ora_dict_obj_name

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
create or replace trigger tr before ddl on schema begin
 insert into log values (ora_dict_obj_name); -- ou xml blabla
end;
/

**JuJuLaTordue** · 08/04/2008, 14h02

pifor > J'ai regardé avec attention le lien que tu m'as donné, et même avec des jointures je ne vois pas comment je pourrais obtenir le nom de la table modifiée à l'instant T. Le but étant justement de ne pas recréer l'ensemble des xml à chaque fois mais uniquement ceux dont la table est modifiée.

laurentschneider > Je n'ai pas encore testé ta solution, mais elle me parait judicieuse. Je vais essayé de suite

**pifor** · 08/04/2008, 14h37

Si vous voulez l'historique complet des instructions INSERT, UPDATE et DELETE sur une table particulière, vous pouvez utiliser utiliser l'audit:

Enabling Object Auditing
To audit all successful and unsuccessful DELETE statements on the SCOTT.EMP table, BY SESSION (the default value), enter the following statement:

AUDIT DELETE ON scott.emp;

To audit all successful SELECT, INSERT, and DELETE statements on the DEPT table owned by user JWARD, BY ACCESS, enter the following statement:

AUDIT SELECT, INSERT, DELETE
ON jward.dept
BY ACCESS
WHENEVER SUCCESSFUL;

Mais on ne peut pas demander directement à la commande AUDIT de travailler sur une procédure PL/SQL donnée à moins de modifier la procédure en question en ajoutant les commandes AUDIT en début de procédure et NOAUDIT en fin de procédure avec du SQL dynamique.

Un petit exemple complet serait le bienvenu pour définir le besoin exact.

**JuJuLaTordue** · 08/04/2008, 14h41

ARgh ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE OR REPLACE TRIGGER tr_xml before ddl ON SCHEMA

ERREUR à la ligne 1 :
ORA-00406: param. COMPATIBLE doit être 8.1.6.0.0 ou plus

Ya t'il une alternative ? :/

pifor > Pour être plus clair, j'ai un schema composé de x tables, je souhaite générer les fichiers xml spécifiques de ces tables. Ceci est fait.
Mais à chaque insertion (d'un patient par exemple), j'aimerai que le fichier XML attaché à la table soit mis à jour. Afin de m'éviter de re-générer l'ensemble des xml à chaque fois, ce qui serait fort préjudiciable pour le serveur.

Pour cela, je me suis dit qu'il me fallait récupérer le nom des tables au moment où elles sont modifiées et injecter ce nom dans une procédure qui me génére le xml voulu. (Peut-être existe-il une solution plus adéquate ? )

**laurentschneider** · 08/04/2008, 14h54

quelle est ta valeur de COMPATIBLE ???

8.1.6.0.0 ça a déjà 10 ans, non? tu as quoi? 8.1.5 ?

**pifor** · 08/04/2008, 14h55

Dans ce cas là, vous pouvez vous inspirer de l'exemple avec le trigger: c'est bien d'un trigger "simple" (pour INSERT/UPDATE/DELETE) que vous avez besoin dans votre exemple et non d'un trigger DDL (qui réagit à un ALTER TABLE).

On peut se poser la question s'il est plus simple et plus rapide d'utiliser un trigger et de générer un bout de XML ou d'utiliser l'audit et de générer le XML 1 fois par jour par exemple. A vous de voir.

**JuJuLaTordue** · 08/04/2008, 15h10

laurentschneider > 8.1.0

(on est limité en budget)

pifor > effectivement je me posais la question, un trigger serait trop gourmand en ressource, finalement ce n'est pas la bonne solution.
Je crois que je vais abandonner cette idée et passer par un autre langage(ASP), mais je vais étudier la question de l'audit.

En tous les cas, merci à vous deux pour votre aide.

**laurentschneider** · 08/04/2008, 15h25

8.1.0 ca n'existe pas.

que te donne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from v$version;

**JuJuLaTordue** · 08/04/2008, 15h31

erf c'est pourtant bien ce qui était indiqué dans init.ora >>

compatible = 8.1.0

sinon voici ce que me retourne SELECT * FROM v$version >>

Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
PL/SQL Release 8.1.7.0.0 - Production
CORE 8.1.7.0.0 Production
TNS for 32-bit Windows: Version 8.1.7.0.0 - Production
NLSRTL Version 3.4.1.0.0 - Production

Faudrait-il que je modifie simplement init.ora ?