Discussion :

[MuadDib_CH]

Bonjour tout le monde!

Voilà ma situation: j'ai deux serveurs SQL hébergeant des bases de données différentes (A et B). Sur ma base de données B, j'ai un trigger insert sur une table qui va faire des insert dans une table de la base de données A.

En cas d'erreur dans l'insertion j'avais prévu de flagger l'enregistrement posant problème dans la base de données B. Seulement je n'arrive pas à le faire parce que s'il y a une erreur, le trigger fait un rollback général (ce qui est plutôt bien!).
Mais du coup, je ne sais pas comment flagger l'enregistrement de la base de données B pour ensuite le retrouver.

Qqn a-t-il une idée?

Merci d'avance

[SQLpro]

Il suffit de "flagger" à l'envers : considérer au départ que c'est pas OK et dans le trigger mettre à OK. Si rollback alors pas OK restera !

A +

[MuadDib_CH]

Il suffit de "flagger" à l'envers : considérer au départ que c'est pas OK et dans le trigger mettre à OK. Si rollback alors pas OK restera !

A +

Salut, effectivement c'est une excellente idée... Mais je ne peux pas flagger à l'envers parce que le seul endroit où je peux flagger à OK ou pas c'est dans mon trigger. Et s'il y a une erreur ça veut dire que mon flag n'est pas setté correctement :-)

Et à priori je ne peux pas utiliser une valeur par défaut directement dans la base parce que mon flag peut avoir 3 valeurs: ne pas traiter, traité, erreur.

Est-ce que qqn aurait une autre idée?

Merci pour l'aide

[mikedavem]

Bonjour,

Passer par autre chose qu'un trigger qui invalide une transaction si une erreur se produit.

Pourquoi ne pas faire cela avec une procédure stockée qui s'exécuterait de manière cyclique par le biais de l'agent SQL Server ?

++

[MuadDib_CH]

Pourquoi ne pas faire cela avec une procédure stockée qui s'exécuterait de manière cyclique par le biais de l'agent SQL Server ?

Malheureusement le trigger est une contrainte faisant partie du cahier des charges :-( pour cause de besoin d'immédiateté de la réplication des données entre les deux bases (même si ce besoin est plus que discutable).

[Bluedeep]

Malheureusement le trigger est une contrainte faisant partie du cahier des charges :-( pour cause de besoin d'immédiateté de la réplication des données entre les deux bases (même si ce besoin est plus que discutable).

Dans ce cas, pourquoi réinventer l'eau tiède et ne pas utiliser la réplication (ce qui est justement faite pour faire de la .... réplication).

[Ptit_Dje]

Malheureusement le trigger est une contrainte faisant partie du cahier des charges :-( pour cause de besoin d'immédiateté de la réplication des données entre les deux bases (même si ce besoin est plus que discutable).

Une stored procedure peut faire la meme chose.