trigger, erreur et log

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

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 +

Citation:

---

Envoyé par 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 +

---

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

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 ?

++

Citation:

---

Envoyé par mikedavem

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).

Citation:

---

Envoyé par MuadDib_CH

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).

Citation:

---

Envoyé par MuadDib_CH

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.

Citation:

---

Envoyé par Ptit_Dje

Une stored procedure peut faire la meme chose.

---

Euh, tu la déclenche comment ? si il veut un déclenchement syncrhone, les deux sont inadaptés. Le try/catch dans le code ne permet pas de capturer une erreur majeur (base hors ligne par exemple) et ruine de toute manière l'ensemble.
C'est le choix de faire de la "réplication sans réplication" qui est fumeux ici à la base.

@MuadDib_Ch : je ne comprends pas, tu parles de cahier des charges; or, un cahier des charges, ça décrit un besoin à remplir, pas une solution technique à utiliser.

Citation:

---

Envoyé par Bluedeep

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).

---

Parce que, sauf erreur, la réplication va fonctionner sur deux bases identiques. Hors là il s'agit de deux bases totalement différentes!

Citation:

---

Envoyé par Bluedeep

@MuadDib_Ch : je ne comprends pas, tu parles de cahier des charges; or, un cahier des charges, ça décrit un besoin à remplir, pas une solution technique à utiliser.

---

Oui pardon je me suis mal exprimé :-)
Le trigger ne fait pas partie du cahier des charges. Ce qui fait partie du cahier des charges c'est que les données doivent être disponibles immédiatement dans les deux bases de données.
C'est ceci qui m'a amené à utiliser un trigger plutôt qu'une SP schedulée par SQL Agent. Parce que pour l'immédiateté via SQL Agent je ne vois pas bien (à part régler le lancement de la SP toutes les minutes).

Citation:

---

Envoyé par MuadDib_CH

Parce que, sauf erreur, la réplication va fonctionner sur deux bases identiques. Hors là il s'agit de deux bases totalement différentes!

---

Oui, il y a erreur.

La réplication d'uen base se passe au niveau table et colonnes, donc tu peux :

- sélectionner les tables à répliquer
- dans une/des tables, sélectionner les colonnes.

Au cas où ta structure destinatrice est très différente, c'est possible aussi moyennant un peu de redondance :

- répliquer les tables/colonnes contenant les données destinées à remplir tes tables de destination.

- utiliser le postsnapshot script et les proc stoc custom de réplication pour faire l'alimentation de tes tables "métiers" utiles sur la base destinatrice. Le post snapshot script fera le traitement initial, les proc stoc customs se chargeront de l'alimentation transactionelle.

(Suite)

Exemple concret :

j'ai une base Source qui a deux tables T1 et T2 et une base Target qui a une table T3, devant contenir des données venant à la fois de T1 et T2.

Je vais procéder de la manière suivante :

- répliquer T1 et T2 vers Target en ne sélectionnant que les colonne procédant de la constructiion des données de T3.

- faire un post snap shot script qui va alimenter T3 à partir de Target.T1 et Target.T2 (de la base Target, puisqu'elles sont répliquées).

- faire les 3 customs stoc proc de réplication de T1 et T2 de telle manière qu'elles alimentent transactionnellement T3. (ces 3 proc stoc custom sont sur la base Target, pas la base Source et seront exécutées sur T3 au moment de la réplication des transactions).


Est ce plus clair ?

Citation:

---

Envoyé par Bluedeep

Euh, tu la déclenche comment ? si il veut un déclenchement syncrhone, les deux sont inadaptés. Le try/catch dans le code ne permet pas de capturer une erreur majeur (base hors ligne par exemple) et ruine de toute manière l'ensemble.
C'est le choix de faire de la "réplication sans réplication" qui est fumeux ici à la base.

@MuadDib_Ch : je ne comprends pas, tu parles de cahier des charges; or, un cahier des charges, ça décrit un besoin à remplir, pas une solution technique à utiliser.

---

Pour le declenchement - Avec un:

Code:

---

1 2	exec <storedProcedure> [param1, param2, ...]

---

Je comprend pas l'idee de declenchement synchrone - Si la donnee doit etre inseree en 2 endroits en meme temps, ca se passe dans une transaction.

Maintenant, si on ne peut pas toucher au code de l'application et qu'il faut greffer une replication instantanee des donnees sur de l'existant juste a l'aide d'un artifice au niveau de la DB, effectivement l'idee du trigger...

Pour les exceptions du genre le serveur est mort ou autre, il faut plus d'info pour pouvoir repondre...

Citation:

---

Envoyé par Ptit_Dje

Pour le declenchement - Avec un:

Code:

---

1 2	exec <storedProcedure> [param1, param2, ...]

---

---

Merci, mais je ne te demandais pas comment appeler une proc stoc !!
Sur quel évenement tu comptes déclencher l'appel de la ps ?

Citation:

---

Pour les exceptions du genre le serveur est mort ou autre, il faut plus d'info pour pouvoir repondre...

---

Je ne mentionne même pas le cas "serveur mort" mais base hors ligne ou read only pour question de maintenance.
De ce fait, un trigger interbase manque tellement de robustesse que son utilisation n'est même pas réellement envisageable en environnement de production.

Citation:

---

Envoyé par Bluedeep

Merci, mais je ne te demandais pas comment appeler une proc stoc !!
Sur quel évenement tu comptes déclencher l'appel de la ps ?

---

C'est a MuadDib_CH de nous repondre sur ce point.
Comment est genere l'insert actuellement ? Est ce que cela peut etre effectuer par une stored procedure ou est ce que le code de l'application (ou autre) est fige ?

Citation:

---

Envoyé par Bluedeep

Je ne mentionne même pas le cas "serveur mort" mais base hors ligne ou read only pour question de maintenance.
De ce fait, un trigger interbase manque tellement de robustesse que son utilisation n'est même pas réellement envisageable en environnement de production.

---

Effectivement. Par contre on se retrouve dans une cas d'exception et je trouverai dommage de devoir couper l'acces a une base pour une maintenance, tout est fait pour que cela puisse se passer online...

Citation:

---

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.

---

Comment implementer cela avec une replication transactionnelle ?

Citation:

---

Envoyé par Ptit_Dje

Par contre on se retrouve dans une cas d'exception et je trouverai dommage de devoir couper l'acces a une base pour une maintenance, tout est fait pour que cela puisse se passer online...

---

La question n'est absolument pas là.
Le fait est qu'on ne peut pas désigner une archi où une appli qui alimente une base A se plante car pour d'autres raisons on doit alimenter une base B et que cette base B est hors ligne.
Se poser la question si il peut ou pas arriver que la base B soit hors ligne ne me semble pas une bonne approche.

Citation:

---

Comment implementer cela avec une replication transactionnelle ?

---

Avec les store proc custom.

T'as raison sur le premier point et tu m'apprends quelque chose sur le second :)

Merci à tous pour ces discussions fort intéressantes...
Alors voilà pour clarifier la situation:
1. Je n'ai pas la maîtrise du code des applications qui tournent sur les bases A et B (2 applis différentes)
2. Je ne peux pas modifier la structure de la base de données A
3. Mon but est de faire l'intégration de deux logiciels:
a. Le logiciel B est spécialisé dans un domaine que A ne fait que survoler
b. Le logiciel A a besoin d'une partie des données de B pour continuer $ fonctionner correctement malgré qu'il soit moins spécialisé.

Voilà...

Citation:

---

Envoyé par MuadDib_CH

Merci à tous pour ces discussions fort intéressantes...
Alors voilà pour clarifier la situation:
1. Je n'ai pas la maîtrise du code des applications qui tournent sur les bases A et B (2 applis différentes)
2. Je ne peux pas modifier la structure de la base de données A
3. Mon but est de faire l'intégration de deux logiciels:
a. Le logiciel B est spécialisé dans un domaine que A ne fait que survoler
b. Le logiciel A a besoin d'une partie des données de B pour continuer $ fonctionner correctement malgré qu'il soit moins spécialisé.

Voilà...

---

Réplication ou Queues SSB. (sauf si la phrase "Je ne peux pas modifier la structure de la base de données A" implique de ne pas pouvoir y créer de proc stoc ou de structure de réplication, et dans ce cas, il n'y a pas de problème car il n'y a pas de solution :D )

Une idée :

Code:

---

1 2 3 4 5 6

TRY ... CATCH 1) ROLLBACK 2) KO

---

J'ai des doutes quant à la possibilité de faire un rollback ds le trigger même.