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

[Invit�]

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