Bonjour,
J'aimerais récupérer les lignes d'une table qui ont été insérées dans la journée, mais je ne peux pas ajouter de colonne date (contrainte) dans ma table. Peut-t-on récupérer la date de création de la ligne ?
Merci d'avance
Version imprimable
Bonjour,
J'aimerais récupérer les lignes d'une table qui ont été insérées dans la journée, mais je ne peux pas ajouter de colonne date (contrainte) dans ma table. Peut-t-on récupérer la date de création de la ligne ?
Merci d'avance
Si tu ne peux pas ajouter de colonne dans ta table, peux-tu ajouter une table (id_ligne_modifiée, date_modification) que tu alimenterais avec un trigger ON INSERT ?
Autre possibilité, si ta table à surveiller a une clé basée sur une séquence, récupérer en fin de journée l'ID de la dernière ligne modifiée.
Bonjour Alain,
A vrai dire je suis assez limité dans la modification de la base, moins j'en fait et mieux c'est :?, donc pour la table c'est une bonne solution j'y ai pensé mais ce n'est pas envisageable (à moins de ne pas avoir le choix :aie:), j'ai regardé mes tables n'ont pas d'"ID". N'y a t-il pas une "propriété date" pour chaque tuple ?
non ça n'existe pas.
tu ne peux pas mettre la colonne et la géré par trigger (comme cela pas de modif dans le code rattaché) ?
Si vous cherchez des données pas trop anciennes, vous pouvez vous appuyer sur le ora_rowscn comme indiqué ici par Pomalaix :
http://www.developpez.net/forums/d10...s/#post5615052
Et n'oublie pas de lire la doc :
http://download.oracle.com/docs/cd/E...columns007.htm
Citation:
This pseudocolumn is useful for determining APPROXIMATELY when a row was last updated
Je confirme l'utilisation de ora_rowscn
Code:
1
2
3
4
5
6 select scn_to_timestamp(max(ora_rowscn)) from XX where rowid = ( select rowid from XX where condition)
Et je confirme qu'il faut bien faire attention
Citation:
It is not absolutely precise, because Oracle tracks SCNs by transaction committed for the block in which the row resides. You can obtain a more fine-grained approximation of the SCN by creating your tables with row-level dependency tracking. Refer to CREATE TABLE ... NOROWDEPENDENCIES | ROWDEPENDENCIES for more information on row-level dependency tracking.
j'adore more fine-grained approximation...
Une meilleure approximation, mais une approximation quand même, qui ne marchera pas forcément avec tous les types de tables, pas au delà de l'UNDO, pas lors d'un déplacement de tablespace ou autre reorg, bref une "meilleure approximation" mais pas une "info fiable" 8-)
Je suis très perplexe, là !
Pour moi, ce qui rend le succès de ORA_ROWSCN fondamentalement aléatoire pour une table ordinaire (sans parler de modifications "parasites" dues à des réorgs), c'est la faible capacité de SMON_SCN_TIME, qui fait qu'au delà d'un "certain temps" (les fameux plus ou moins 5 jours), on est incapable de retrouver la correspondance entre le SCN de dernière modification du bloc, et l'horodate correspondante.
A ma connaissance, l'UNDO n'intervient pas là-dedans, l'ORA_ROWSCN, qu'il soit de niveau bloc ou de niveau ligne selon ROWDEPENDENCIES, est stocké dans le bloc de données lui-même, et c'est juste sa conversion en temps qui pose problème : SCN_TO_TIMESTAMP jette l'éponge.
Tanel Poder a d'ailleurs une astuce à ce propos (http://blog.tanelpoder.com/2009/02/0...e-last-changed) : si SMON_SCN_TIME ne peut fournir l'info, il essaye de calculer une approximation plus grossière de la date du changement à l'aide de V$LOG_HISTORY (FIRST_CHANGE# fournit le SCN, et FIRST_TIME l'horadate équivalente).
Mais s'il y a réellement une subtilité au niveau de l'UNDO, je suis friand de la découvrir !
ok, désolé, j'ai répondu trop vite... rien avoir l'UNDO, j'aurais du dire pas éternellement
merci pour la correction :ccool: