Forcer une valeur NULL

**Jinroh77** · 04/03/2011, 17h24

* Bonjour, *

La demande est un peu bizarre mais imaginons une base alimentée par un CRM.
Pour des besoins particuliers, je souhaite que, même si le CRM souhaite remplir une colonne, je force la valeur à NULL et cela sans avoir un retour d'erreur du moteur.

A part utiliser un trigger after, il y a une autre solution ?
J'essaye avec les contraintes, mais lorsque j'essaye d'insérer, il refuse complètement la ligne et me retourne une erreur, ce qui est normal.

* Merci *

**aieeeuuuuu** · 04/03/2011, 17h39

Bonjour

A part utiliser un trigger after, il y a une autre solution ?

plutôt un trigger instead of :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
 
CREATE TRIGGER [dbo].[MonTrigger]
   ON  [dbo].[MaTable]
   INSTEAD OF INSERT
AS 
BEGIN
 
	INSERT INTO MaTable(A,B)
	SELECT NULL, B
	FROM INSERTED
END

**Jinroh77** · 04/03/2011, 17h42

C'est vrai, c'est peut-être mieux avec instead of.
Je n'ai pas précisé mais ça peut être en cas d'insert ou d'update.

mais l'idée est tout de même de ne pas utiliser de trigger du tout si possible ?

**Waldar** · 04/03/2011, 19h08

Quel serait le besoin "après" d'avoir cette colonne nulle ?

**Jinroh77** · 05/03/2011, 14h55

Le CRM met à jour cette colonne automatiquement, alors que dans le cas de ce paramétrage précis, pour ce client, je ne veut pas qu'il puisse modifier cette valeur.
Sans avoir la possibilité d'agir sur le CRM à ce niveau, je comptais le faire au niveau SQL, si possible sans trigger.

**fsmrel** · 07/03/2011, 20h20

Un moyen d'éviter les mises à jour d'une colonne est de leurrer le CRM en lui faisant prendre une vessie pour une lanterne, c'est-à-dire de lui faire mettre à jour une vue plutôt qu'une table de base, vue dans laquelle ne figurent pas les noms des colonnes justement interdites de mise à jour.

Le sage Waldar a-t-il une opinion à ce sujet ? Peut-être que le bouillant SQLpro a rédigé des billets en ce sens ?

**mikedavem** · 07/03/2011, 22h14

N'étant ni sage ni bouillant j'émetterais quand même mon humble avis

Un moyen d'éviter les mises à jour d'une colonne est de leurrer le CRM en lui faisant prendre une vessie pour une lanterne, c'est-à-dire de lui faire mettre à jour une vue plutôt qu'une table de base, vue dans laquelle ne figurent pas les noms des colonnes justement interdites de mise à jour.

Dans ce cas je pense qu'une erreur sera provoquée puisque dans la vue la colonne n'existera pas et c'est peut être ce que Jinroh77 ne veux pas.

++

**fsmrel** · 07/03/2011, 23h40

Envoyé par mikedavem

N'étant ni sage ni bouillant j'émetterais quand même mon humble avis

Dans ce cas je pense qu'une erreur sera provoquée puisque dans la vue la colonne n'existera pas et c'est peut être ce que Jinroh77 ne veux pas.

Je n'avais pas pensé à vous, et je bats ma coulpe, mais mon but est surtout de faire avancer le Schimilimili dans la détente et la bonne humeur (qualité dont vous n'êtes pas dépourvu)... Il est évident qu'au sens SQL, la mise à jour via une vue pose quelques problèmes. Reste à inviter dans la quête à la bonne solution quelques collègues — liste non limitative — comme elsuket et Luc Orient (M. DB2) dont le bon sens, le sérieux et la compétence ne sont plus à démontrer...

Quant à votre sagesse, votre modestie dût-elle en souffrir, j'oserai malgré tout la qualifier de proverbiale...

Vous connaissez ma position vis-à-vis de NULL, mais comme Jinroh77 n’a pas l’air contre son emploi, la séquence suivante devrait le satisfaire, dans le respect de la 6e des 12 règles de Codd :

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
CREATE TABLE T
(
        Tid        Int           NOT NULL
      , Nom        Varchar(32)   NOT NULL
      , Secret     Varchar(32)   NULL
    , CONSTRAINT T_PK PRIMARY KEY (Tid)
) ;
GO
CREATE VIEW V 
AS SELECT  Tid, Nom
   FROM    T
;
GO
INSERT INTO T VALUES (1, 'Albert', 'top secret') ;
SELECT '' AS 'T1', * FROM T ;
 
UPDATE V SET Nom = 'Bernard' WHERE Nom = 'Albert'
SELECT '' AS 'T2', * FROM T ;
 
INSERT INTO V VALUES (2, 'Charles') ;
SELECT '' AS 'T3', * FROM T ;

Quoi qu'il en soit, même si Jinroh77 n’est pas amateur de triggers, pourquoi ne pas quand même essayer de tricoter vue et trigger pour trouver une solution qui ne fasse pas intervenir NULL dans la déclaration de la table T ?

**fsmrel** · 08/03/2011, 00h08

Avec un trigger associé à la vue V, pourquoi pas quelque chose comme ça :

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
23
24
25
26
CREATE TABLE T
(
        Tid        Int           NOT NULL
      , Nom        Varchar(32)   NOT NULL
      , Secret     Varchar(32)   NOT NULL
    , CONSTRAINT T_PK PRIMARY KEY (Tid)
) ;
GO
CREATE VIEW V 
AS SELECT  Tid, Nom
   FROM    T
;
GO
CREATE TRIGGER TRG ON V INSTEAD OF INSERT AS
       INSERT INTO T
              SELECT Tid, Nom, 'Pas touche'
              FROM   INSERTED 
GO
INSERT INTO T VALUES (1, 'Albert', 'top secret') ;
SELECT '' AS 'T1', * FROM T ;
 
UPDATE V SET Nom = 'Bernard' WHERE Nom = 'Albert'
SELECT '' AS 'T2', * FROM T ;
 
INSERT INTO V VALUES (2, 'Charles') ;
SELECT '' AS 'T3', * FROM T ;

**aieeeuuuuu** · 08/03/2011, 10h07

Un question me taraude depuis le début de cette discussion...

par curiosité Jinroh77, pourquoi est-ce que :

Envoyé par Jinroh77

l'idée est tout de même de ne pas utiliser de trigger du tout si possible ?

?

**Jinroh77** · 08/03/2011, 10h15

Bonjour,
Merci à tous vos apports sur cette discussion.
Je vais voir du côté de la vue si au moins on peut jouer sur le CRM à ce niveau mais je ne suis pas sûr.

Pour répondre à cette dernière question, l'idée est d'un point de vue performance. J'avais peur qu'à partir d'un CRM générant beaucoup d'activité à ce niveau, le trigger pouvait plus consommer qu'une autre méthode.
D'où le fait de penser à quelque chose de simple et efficace, mais visiblement ce n'est pas possible.

**mikedavem** · 08/03/2011, 20h22

La solution de passer par une vue sans trigger est élégante je trouve (qui respecte bien la 6ème règle de Codd) mais pour cela il faudrait avoir comme hypothèse que Jinroh77 puisse avoir accès au code du CRM concerné.

++

**vmolines** · 09/03/2011, 09h58

Ne serait-il pas possible de nommer la vue comme la table normalement manipulée et de renommer cette dernière afin de leurrer complètement l'application cliente sans avoir à y toucher ?

**Jinroh77** · 09/03/2011, 10h06

Le problème est que si je fais cela, c'est tout le CRM qui risque de faire la tête.
La table est utilisée par d'autres traitements interne que je ne préfère pas déranger.

Pour résumer :
- soit un triger que l'on essaye de faire propre et rapide.
- soit d'une manière ou d'une autre, il faut aller modifier le code du CRM pour le faire pointer autre part.

Merci pour toutes vos idées

**fsmrel** · 09/03/2011, 12h47

Je ne suis pas du tout spécialiste de SQL Server, mais ne pourrait-on pas envisager la piste de l'instruction GRANT pour autoriser/interdire à tel ou tel process la mise à jour de telle et telle colonnes de la table en question ?

**iberserk** · 09/03/2011, 12h51

Si le CRM met à jour cette colonne, ne l'utilises pas également? le fait que sa valeur soit NULL (oups je veux dire son absence de valeur il y à tout le beau monde là il faut faire attention :-)) ne va t'il pas le perturber?

Les TRIGGER font partie intégrantes des SGBDR, s'il est vrai qu'il faut prêter une attention toute particulière à leur optimisation, leur utilisation est courante et pas forcement contre performante...

**iberserk** · 09/03/2011, 12h53

Je ne suis pas du tout spécialiste de SQL Server, mais ne pourrait-on pas envisager la piste de l'instruction GRANT pour autoriser/interdire à tel ou tel process la mise à jour de telle et telle colonnes de la table en question ?

Oui mais dans ce cas... SQL SERVER remonte une erreur... "ce qui est bien, mais pas TOP"