Discussion :

[DEV-10]

Bonjour

à chaque soir j'aimerais lancer une job (procédure stockée) qui va aller regarder une table et detecter s'il y a eu des changements sur cette table durant la journée.

un changement peut être : 1 ou plusieurs champs de la table qui ont changés

Quelle serait la meilleure technique à utiliser à votre avis ?

Merci d'avance.

[agemis31]

Bonjour,

Je crois qu'il nous faudrait un peu plus d'informations:

• SGBDR et version, ou code le plus standard possible ?
• "changé": juste un update de colonne ou bien aussi les insertions et suppressions de lignes ?

@+

[csharpshooter]

normalement les Triggers ou les déclencheurs devraient faire l'affaire....

[DEV-10]

oui c'est le SQL server 2005.

les trois, update, insertions, et suppression.

Merci.

Bonjour,

Je crois qu'il nous faudrait un peu plus d'informations:

• SGBDR et version, ou code le plus standard possible ?
• "changé": juste un update de colonne ou bien aussi les insertions et suppressions de lignes ?

@+

[agemis31]

Bonjour,

Sous SQL Serveur 2005, il va falloir écrire une solution spécifique. Sous 2008 c'est déja fait
CDC = Change Data Capture. Il y a un virtual lab dessus.

Sous 2005, vous pouvez effectivement utiliser un mécanisme à base de trigger,
en utilisant les pseudos tables inserted et deleted.

Vous pouvez aussi utiliser un timestamp ou un rowversion, qui permet d'attribuer un n° de version à une ligne de table.

@+

[DEV-10]

Bonjour,

Sous SQL Serveur 2005, il va falloir écrire une solution spécifique. Sous 2008 c'est déja fait
CDC = Change Data Capture. Il y a un virtual lab dessus.

Sous 2005, vous pouvez effectivement utiliser un mécanisme à base de trigger,
en utilisant les pseudos tables inserted et deleted.

Vous pouvez aussi utiliser un timestamp ou un rowversion, qui permet d'attribuer un n° de version à une ligne de table.

@+

Bonjour

Voici un peu plus de précision :
Je vais utiliser une procédure stockée qui s'exécutera tous les soirs à 20:00. Dans ce cas je n'aurai pas besoin d'utiliser un trigger je pense. n'est-ce pas ?
je cherche plutôt un mécanisme qui detectera non seulement un changement dans la table, mais aussi le type de changement (suppression ou insertion, ou mise à jour) avec mémorisation de l'ancienne information.

il y aurai 4 procédures stockéesen tout.
la première qui detecte le chanement et s'exécute à tous les soirs.
1 procédure pour la mise à jour,
1 procédure pour la suppression,
et 1 procédure pour l'insertion.

ces 3 dernières procédures seront appelées par la première procédure seulement au besoin.

Merci.

[agemis31]

Bonjour,

A moins d'utiliser un snapshot, ce qui serait assez lourd pour ça et disponible seulement en version entreprise, il vous faut stocker les modifications au fur et à mesure, jusqu'à 20 heures si j'ai bien compris. Pour cela les triggers sont tout indiqués car il garantissent que d'ou vienne la modification (d'une procédure stockée ou d'un update, insert, delete direct), elle sera tracée.

@+

[DEV-10]

Bonjour,

A moins d'utiliser un snapshot, ce qui serait assez lourd pour ça et disponible seulement en version entreprise, il vous faut stocker les modifications au fur et à mesure, jusqu'à 20 heures si j'ai bien compris. Pour cela les triggers sont tout indiqués car il garantissent que d'ou vienne la modification (d'une procédure stockée ou d'un update, insert, delete direct), elle sera tracée.

@+

Bonjour

Est-ce que pour la version SQL Server 2000 c'est la même chose ?

[agemis31]

Bonsoir,

Oui. Voici deux liens qui peuvent vous servir. Le premier explique le principe. Le second est plus générique. Attention néanmois à l'aspect performance avec cette seconde méthode qui lit systématiquement le catalogue système.

@+