Discussion :

[ghameau]

Bonjour

je dois créer un trigger qui va mettre à jour des données d'une bdd à une autre
pour cela je voudrais rendre paramétrable le nom de la bdd cible pour pouvoir changer bdd facilement.

apres des tests sur le trigger il s'avere que les execute n'acceptent pas d'utiliser les tables inserted et deleted alors que je suis obligé de faire des concaténations de chaine pour utiliser mon paramétrage.
Y a t' il une autre solution?

Merci

Gaétan

voir l'exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
la fonction dbo.base_prod('Ma_table') renvoie >> nomBDD.dbo.Ma_table
 
ALTER TRIGGER [dbo].[MAJ_TABLE]
   ON  [dbo].[Contact_Traitement]
   AFTER INSERT
AS 
BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;
 
    -- Insert statements for trigger here
declare @sq as nvarchar(500)
 
---- Ajouter les nouvelles données
set @sq = 'insert into '+ dbo.base_prod('Ma_table') + 
		' select contact.A_code,year(A_date_debut),year(a_date_fin),a_flag_traitement  from inserted T left join Contact on T.contact_id=Contact.contact_id '
 
exec (@sq)

[elsuket]

Bonjour,

Cela est normal puisque EXEC utilise un autre contexte d'exécution quel le contexte local au module SQL, ici votre trigger.

Il est bizarre que vous ayez besoin de copier vos données dans des tables différentes, et cela montre que votre modèle de données n'est pas correct à ce niveau là.

Néanmoins pour venir à bout de votre problème, il suffit de créer une vue dans dbo.base_prod qui spécifie la bonne table (vous pouvez créer cette vue pas SQL dynamique), et réaliser l'INSERT sur cette vue.
Cette vue se verrait attacher un trigger (dont vous pouvez aussi générer le code en SQL dynamique) qui réalisé l'insertion dans la table sous-jacente à la vue.

@++

[ghameau]

bonjour

>Il est bizarre que vous ayez besoin de copier vos données dans des tables >différentes, et cela montre que votre modèle de données n'est pas correct à >ce niveau là.
en effet mais c'est temporaire car il s'agit d'une migration de notre outil crm vers un autre, l'alimentation des données se fera pour une petite periode le temps de refaire toutes les interfaces manquantes...


>Néanmoins pour venir à bout de votre problème, il suffit de créer une vue >dans dbo.base_prod qui spécifie la bonne table (vous pouvez créer cette >vue pas SQL dynamique), et réaliser l'INSERT sur cette vue.
>Cette vue se verrait attacher un trigger (dont vous pouvez aussi générer le >code en SQL dynamique) qui réalisé l'insertion dans la table sous-jacente à >la vue.
J'avoue ne pas bien comprendre la manoeuvre!
le but est de mettre à jour les données dans l' "ancienne" table de l' "ancienne" BDD dès qu'il se passe une modification ou insertion dans le nouveau produit crm. le tout en pouvant choisir la base de destination via la fonction scalaire base_prod.


merci

[elsuket]

Veillez à utiliser les balises appropriées quand vous postez

- balises [code] : petit bouton # à droite de la barre d'outils
- balises [quote] : bouton à gauche du bouton #

en effet mais c'est temporaire car il s'agit d'une migration de notre outil crm vers un autre, l'alimentation des données se fera pour une petite periode le temps de refaire toutes les interfaces manquantes...

OK

J'avoue ne pas bien comprendre la manoeuvre!
le but est de mettre à jour les données dans l' "ancienne" table de l' "ancienne" BDD dès qu'il se passe une modification ou insertion dans le nouveau produit crm. le tout en pouvant choisir la base de destination via la fonction scalaire base_prod.

Excusez-moi, j'ai mal lu.
Je pense que vous n'avez pas d'autre choix que de copier les données issues de INSERTED dans une "vraie" table, pour ensuite pouvoir vous passer de celle-ci dans votre code SQL dynamique.

Si la table source est très souvent affectée par des insertions de données, je vous conseille d'utiliser la procédure stockée système sp_executeSQL qui permet de réutiliser les plans de requête.

@++

[SQLpro]

Ne serait-il pas plus judicieux de recourir à une réplication ? Parce que si l'on des serveur est arrêté ou le réseau occupé, votre système sera bloqué !

A +