Discussion :

[Pol63]

bonjout

(sql 2005)

j'ai fais un déclencheur Instead Of Update où je teste une condition qui me dit si la modification est autorisée ou non
dans le cas ou c'est non, je fais return

mais dans le cas ou c'est oui, j'aimerais pouvoir faire l'update voulu
et sans faire un set explicite de tous les champs, pour que si je rajoute un champs plus tard ca le prenne bien aussi sans venir modifier le trigger

donc il me faudrait une instruction magique pour acquitter l'update où un moyen de récupérer la requete pour la relancer via un sp_executesql je pense

merci

[SQLpro]

Un exemple : la colonne X des lignes à insérer ne doit pas contenir "toto"

Code :

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

1
2
3
4
5
IF NOT EXISTS(SELECT *
              FROM   inserted
              WHERE  X = 'toto')
   INSERT INTO MaTable
   SELECT * FROM inserted

A +

[Pol63]

sur un instead of insert, je sais faire

mais moi c'est un update pas un insert !
et là c'est moins drole, update * ca existe pas je crois

[SQLpro]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
IF NOT EXISTS(SELECT *
              FROM   inserted
              WHERE  X = 'toto')
   UPDATE MaTable
   SET Colonne1 = i.Colonne1,
       Colonne2 = i.Colonne2,
       Colonne3 = i.Colonne3,
       Colonne4 = i.Colonne4,
   ...
   FROM  MaTable T
         INNER JOIN inserted i
               ON T.clef = i.Clef

A +

[Pol63]

je vais finir par croire que tu ne lis pas ce que je dis ...

je cherche un moyen de le faire sans spécifier les colonnes pour avoir un trigger durable dans le temps

[SQLpro]

Cela n'est pas possible du fait de la structure du langage SQL.

Si SQL Server permettait l'emploi du Row Value Constructor, et si la norme SQL avait prévue qu'on puisse utiliser le * dans ce cas de figure, on aurait pu faire :

Code :

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

1
2
3
 
UPDATE ...
SET (*) = (SELECT * FROM INSERTED AS I WHERE I.clef = MaTable.clef)

Mais cela n'est possible sur aucune machine. Et pour ma prt je m'en réjouit car l'utilisation de * pose plus de problème qu'elle n'en résoust Voir la règle n° 8 de codd dans les explications que j'en donne dans cet article : <http://sqlpro.developpez.com/SGBDR/ReglesCodd/

A +

[Pol63]

ca n'empeche pas le fait que prévoir de pouvoir faire des triggers instead of sans la possibilité de dire "finalement faites comme si je n'étais pas là" est étrange ...

moi dans mes softs, je prévois la possibilité de modifier des comportements avant action, mais avec la possibilité de faire l'action quand meme ...


sinon pour le * , ca reste pratique quand meme pour éviter de rechercher toutes les modifs à faire quand on rajoute un champ quelque part

mais j'essairais de lire les 12 règles d'or quand j'aurais trouvé un pc avec un pdf reader
ca doit être utile bienque certaines doivent être évidentes

[SQLpro]

sinon pour le * , ca reste pratique quand meme pour éviter de rechercher toutes les modifs à faire quand on rajoute un champ quelque part

Justement c'est le contraire qui se passe. Avec le * si ta table est restructurée (ajout de colonne par exemple) alors il y a des chances que l'application cliente ne fonctionne plus. C'est pourquoi en principe on ne doit JAMAIS utiliser le *.

A +

[Pol63]

je dirais que ca dépend des applications et de l'utilisation de *

pour de l'affichage dans une grille, je ne vois pas de contre indication ...

[Jinroh77]

TU ne pourras pas connaitre l'ordre d'affichage des colonnes par exemple.
Si c'est simplement de l'affichage sans rien faire derrière ça ne gène pas, mais ça peut devenir plus problématique si cette restitution est réutilisée.

[Pol63]

le sqldatareader de .net permet de connaitre toutes les infos des champs remontés (table, colonne, alias, format etc...)

[SQLpro]

Mais là nous ne sommes plus dans la base de données ! de plus tu ne maîtrise toujours pas l'ordre des colonnes...

A +