Discussion :

[oadin]

Bonjour,

Je me retrouve face a un problème un peu insoluble.

Je crée des trigger sur une table, nous allons prendre pour l'exemple une clé commande.

Les clés primaire de ma table commande sont l'année de commande et le numéro de commande.

je décide de faire un update sur un groupe pour changer tout les numéro de commande d'une année.

Ce qui m'embette la est que j'ai changé une composante de ma clé primaire, comment puis je relier les données insérée dans ma table inserted et dans la table deleted pour savoir quel enregistrements correspondes?

ps : bien sur dans mon exemple j'ai simplifié, je n'ai aucune logique sur laquelle me basé pour me dire que je vais modifier une partie de ma clé mais que je peux utiliser ça ou ça ou ça.
Car en fait je retrouve se problème dans un utilitaire qui me génère dynamiquement des triggers pour l'ensemble de ma base de donnée.

Il me faudrait par exemple un n° d'insertion dans deleted et inserted, mais je ne trouve la description de la table nulle part sur le net, si j'ai bien compris elle contient uniquement les lignes affectée par mon opération et aucune information système supplémentaire.

Ou alors un moyen (autre que un curseur) de parcourir mes donnée dans l'ordre de leur insertion car et cela reste une supposition elles sont j'espère ajoutée dans le même ordre dans les 2 tables.

[SQLpro]

Ce qui m'embette la est que j'ai changé une composante de ma clé primaire, comment puis je relier les données insérée dans ma table inserted et dans la table deleted pour savoir quel enregistrements correspondes?

Vous ne pouvez pas, sauf si vous disposez d'une contrainte d'unicité not null.

La technique consiste à rajouter une colonne temporaire dans laquelle on va stocker la valeur actuelle de la clef pour servir de colonne de recollement.

Enfin il faut penser à débrancher les contraintes d'intégrité référentielles puis les rebrancher.

Evidemment le plus simple aurait été de passer par une vue ce qui permet de ne pas modifier les données de la table... Mais il est vrai que les recommandations du dr. Codd créateur des SGBD relationnels sont très rarement appliquées... Dommage !

A +