Discussion :

[StringBuilder]

Bonjour,

Je tente d'écrire un trigger sur SQL Server 2008 R2.

J'ai deux tables :

CRM_AR : Contient les colonnes (ID, ID_04, F7042)
Contient des produits

CRM_04 : Contient les colonnes (ID, ID_04, Text)
Contient les traductions des libellés des produits

La colonne ID_04 est une sorte de clé étrangère à l'envers : si CRM_04.ID_04 = CRM_AR.ID_04 alors les colonnes sont liées.

Le logiciel qui utilise la base de donnée est très mal foutu (autant que le modèle des données, c'est pour dire) et ne sait pas utiliser la table CRM_04 pour effectuer des recherche sur les articles (donc pas de recherche pas nom dans la langue de l'utilisateur).

J'ai donc truandé en créant une colonne dans CRM_AR qui contient la concaténation de tous les libellés traduits de l'article. Et lors d'une recherche, je fais une recherche dessus.
Je sais, c'est crade, et discutable d'un point de vue résultat, mais c'est tout ce que j'ai sous la main.

Seulement voilà... Les produits ne sont pas seulement intégrés par moulinette (sur laquelle nous avons la main) mais aussi créés en interactif.
Et évidement, dans le logiciel, aucun mécanisme pour mettre à jour le libellé concaténé.

Voici donc le trigger que je tente d'écrire :

Code sql :

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
 
create trigger trg_crm_04_a_iud
on crm_04
after insert, update, delete
begin
	update CRM_AR
	set F7042 = dbo.group_concat(crm_04.Text)
	from CRM_04
	where ID_04 in (
		select id_04
		from inserted
		union
		select id_04
		from deleted
	)
	group by crm_ar.id_04;
end;

Et ça compile pas.

Ca non plus d'ailleurs :

Code sql :

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

1
2
3
4
5
6
7
8
9
 
update CRM_AR
set F7042 = dbo.group_concat(crm_04.Text)
from CRM_04
where ID_04 in (
	select id_04
	from crm_04
)
group by crm_ar.id_04;

Ca semble venir du group by...

Une idée pour rectifier le truc ?

Faites pas attention à group_concat, c'est une fonction de mon cru, qui fonctionne très bien (cf. la section contribution).

Imaginez que je cherche à mettre à jour l'entête du'ne commande avec le SUM() du prix des lignes dont elle est constituée à chaque fois que je fais une modification sur les postes.

[StringBuilder]

Ah ben en fait c'est bon, suffisait de faire une sous-requête

Code sql :

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
20
21
22
 
create trigger trg_crm_04_a_iud
on crm_04
after insert, update, delete
as
begin
	update CRM_AR
	set F7042 = tmp.zzz
	from (
		select id_04, dbo.group_concat(text) zzz
		from CRM_04
		where ID_04 in (
			select id_04
			from inserted
			union
			select id_04
			from deleted
		)
		group by crm_04.id_04
	) tmp
	where crm_ar.ID_04 = tmp.id_04;
end;

[SQLpro]

Pourquoi ne pas faire une vue indexée et faire les recherches dessus plutôt que d'alourdir la table ?

A +

[StringBuilder]

Parce que je ne maîtrise pas le code client, et que le programme ne sais pas utiliser autre-chose que des tables qu'ils gère lui-même.

Déjà faire un trigger en SQL, ça relève du miracle que ça foute pas tout en l'air.

... enfin... miracle pas si miraculeux, puisque j'ai pour le moment été obligé de désactiver mon trigger, car ça fait planter le programme, de façon aléatoire ! :/

[iberserk]

attention je ne vois pas de SET NOCOUNT ON au début du TRIGGER, c'est peut-être la source de vos ennuis...

En effet ajouter un trigger sans le NOCOUNT activé peut perturber certains programmes (notamment ceux utilisant des ORM) qui exploitent le nombre ligne affecté...

[iberserk]

Parce que je ne maîtrise pas le code client, et que le programme ne sais pas utiliser autre-chose que des tables qu'ils gère lui-même.

Sauf erreur de ma part, sur les éditions ENTERPRISE de SQL SERVER le moteur peut utiliser une vue indéxée sans qu'elle soit appelée explicitement... Fred tu confirmes?

[StringBuilder]

Oui, sauf que c'est le programme qui crée les tables/colonnes.
Donc déjà, le trigger, je vais devoir vérifier qu'il a pas sauté à chaque modification.

Si je fais ce que vous proposez, il faut que je crée la table avec le programme, puis que le la remplace par une vue indexée.

Sauf que si on fait ensuite une modification, un ordre ALTER est lancé sur la table : si c'est une vue, je vais planter l'outil de design, ce qui est tout sauf une bonne idée : je vais corrompre la base.

[iberserk]

Je connais très bien le problème des ERP, travaillant avec:

• SAGE L100
• SAGE X3
• DYNAMICS NAVISION
• DYNAMICS AX
• DYNAMICS CRM

En effet il faut toujours scripter les modifications "externes" : index, triggers etc...

Ce que je voulais dire c'est: si la vue indexée est la solution créez la à coté, si informix fait des requêtes sur les tables cibles, SQL SERVER tirera avantage de la présence de la vue indexée de manière transparente.