Discussion :

[billainfo]

je suis debutant en oracle et j'utilise oracle 9i
j'aimerai juste savoir s'il est possible de garder l'hitorique lors d'une mise a jour et si oui comment?
j'espere que j'ai poster dans le bon endroit
n'importe quel remarque me sera utile
merci

[Bruno2r]

Bonjour
Je suppose que tu veux parler d'in update sur une table ...
Mais combien de champs sont ils mis à jour et quelle profondeur d'historique veux tu conserver ? et dans quel but ? consultation ? annulation ? calcul ?
Ca me semble difficile de t'aider sans précisions

[mehdiing]

salut,
je ne connais pas bien orcale (peut être qu'il permet de produire des historique conçernant les actions...)mais une simple idée consiste à créer une ou plusieurs tables(selon la conception) où tu va sauvegarder tous les informations concernants les insertions et les updates (table modifiés, champs modifiés, anciennes valeurs, utilisateur réalisant l'action...).
pour remplir la table tu peut utiliser les trigger (déclencheurs) qui après insertion ou mise à jour vont collecter les informations nécessaires et les insérer dans la table.

[billainfo]

effectivement je veux parler d'un update sur une table
sachant que je donne pas la main a l'utilisateur de supprimer un champ
et je lui donnerai la main de modifier le champs qu'il le designe
sachant que j'ai plusieurs table de ce genre et j'ia pas ajouté une table hitorique
par contre j'ai mis date de modification mais je ne sais pas si ça marche de cette façon
merci

[Bruno2r]

De deux chose l'une :
Ou bien tu crées un trigger befor insert comme le propose très judicieusement mehdiing lequel trigger stocke dans une table les infos de type tablename, columname, oldvalue, sysdate
Ou bien tu veux garder la valeur précédente à chaque update et dans ce cas en plus de ton champs date de mise à jour tu ajoute un champ oldchamp dans lequel tu reportes la valeur avant modif

Code :

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

1
2
3
 
UPDATE MATABLE
SET OLDCHAMP = CHAMP, CHAMP = X

Dommage que tu ne sois pas en Oracle 10g où de nouvelles possibilités sont apparues pour ce faire.
Quelqu'un peut il confirmer que ce n'est pas le cas en Oracle 9 ?
Je n'en sais rien étant passé joyeusement de 8 à 10

[Yorglaa]

@BRUNO2R
juste pour ma culture, de quelle options parles-tu dans la 10G ?

[Bruno2r]

Bonjour Yorglaa
je faisais allusion aux techniques suivantes dont ma connaissance est purement culture générale suite à quelques incursion dans la doc mais aucune mise en oeuvre.
Référence :
Oracle® Database Application Developer's Guide - Fundamentals
10g Release 2 (10.2)
Part Number B14251-01
Using Flashback Query (SELECT ... AS OF)

You perform a Flashback Query by using a SELECT statement with an AS OF clause. You use a Flashback Query to retrieve data as it existed at some time in the past. The query explicitly references a past time by means of a timestamp or SCN. It returns committed data that was current at that point in time.

Using the DBMS_FLASHBACK Package

In general, the DBMS_FLASHBACK package provides the same functionality as Flashback Query, but Flashback Query is sometimes more convenient.
The DBMS_FLASHBACK package acts as a time machine: you can turn back the clock, carry out normal queries as if you were at that time in the past, and then return to the present. Because you can use the DBMS_FLASHBACK package to perform queries on past data without special clauses such as AS OF or VERSIONS BETWEEN, you can reuse existing PL/SQL code to query the database at times in the past.

Dans le sujet qui préoccupe notre ami ces techniques pourraient elles représenter une piste , A toi de nous le dire.

[Yorglaa]

@BRUNO2R

Le DBMS_Flashback existe aussi en 9i..
toutefois cette technique est un peu "approximative", du moins selon le rythme de modification de la table à surveiller...

pour utiliser cette technique il faut faire un "enable" du Flashback (je ne rentre pas dans les détails de syntaxe) selon soit une heure donnée ou selon un no de SCN (si on veut, un no de série du redo log) à consulter...

je vois principalement les problèmes suivants :

• le DBMS_FLASHBACK ne garde les données que le temps de la durée déterminée (en secondes) par le paramètre UNDO_RETENTION (pour autant qu'il y ait assez de place dans le tablespace UNDO)
• les données passées ne sont accessibles QUE si il n'y pas eu entretemps de modification structurelle de la table (ajout/suppression de colonne, truncate, etc...).
• dans le cas d'un "enable" par No de SCN, ça implique de le connaître... or il n'existe aucun moyen automatique de connaître les SCN passés. Il faut donc au préalable avoir mis point un processus qui va stocker les no de SCN avec leur dates et heures de validités à chaque log switch.
• dans le cas d'un "enable" par heure donnée, le processus n'est pas évident... de combien de temps "remonter le temps" pour prendre la données OLD ? selon le rythme de mise à jour de la table, la donnée OLD peut avoir changé x fois en n minutes...

Personnellement je n'ai toujours utilisé le DBMS_FLASHBACK que comme une voie de secours pour récupérer des données effacées/modifiées (et commitées) à tort...

ça peut également être utile dans le cadre d'une base de DEV/TEST pour revenir à un "état avant" lors de certaines phases de test...

mais pour tenir un journal des modifications d'une table, rien ne vaut un trigger en utilisant les arguments :OLD et :NEW. Comme ça on est toujours sûr de traiter avec :OLD la donnée JUSTE AVANT la modification et avec :NEW la donnée juste après...

enfin ce n'est que mon avis...

[Bruno2r]

Merci Yorglaa pour ces précisions
Effectivement ça limite l'intérêt de la tehnique
Notre ami devrait donc suivre la piste du trigger pourquoi pas avec insertion dans une table souvenir_souvenir générale

Code :

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

1
2
 
INSERT INTO MESUPDT(TABLENAME, CHAMPNAME, DTEDEB, DTEFIN, VAL, UTILNAME)

comme le proposait mehdiing