Discussion :

[billybob2]

Bonjour à tous,

J'ai besoin d'une clarification sur la mise à jour des vues(j'utilise SQL Server 2000).

Créons une table et sa vue associée :

Code :

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

1
2
3
4
5
6
7
8
CREATE TABLE T_INT (I INT)
GO
CREATE VIEW V_INT
AS
SELECT 	I,
	I+1 AS J 
FROM T_INT
GO

Essayons maintenant d'inserer une ligne :

Code :

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

1
2
INSERT INTO V_INT(I)
VALUES(1)

Ceci provoque l'erreur :
Serveur*: Msg 4406, Niveau 16, État 1, Ligne 1
Impossible de mettre à jour ou d'insérer une vue ou une fonction 'V_INT' car elles contiennent un champ d'une dérivée ou d'une constante.

Par contre la mise à jour fonctionne ?? :

Code :

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

1
2
3
4
5
insert into T_INT(I) values(1)
GO
update V_INT
SET I=2
WHERE I=1

Si quelqu'un peut m'expliquer ce mystère .

Merci d'avance

[Joel Pinto Ribeiro]

C'est normal...

les vue comme son nom l'indique sert de "vue" donc c'est seulement une table de visualisations et tu peux pas faire de traitement dessus.

Donc quand t'essaye de la modifier c'est normal que sql server te gronde dessus.

Si tu dois faire des modif c'est sur la table principale (T_INT dans ton cas)

[aieeeuuuuu]

Non,

il est possible d’insérer, et mettre à jour une vue, lorsque celle-ci est triviale. Il faut simplement que le moteur soit en mesure de "retrouver ses petits".
Lorsque la vue est plus complexe, il faut alors créer des triggers instead of insert/update...

D'ailleurs ici, à mon sens, l'insertion, comme la mise à jour devraient passer !

[Joel Pinto Ribeiro]

Autant pour moi .
Oui effectivement on peut faire des traitement sur des vues, sauf que la vue ne connais pas forcement toutes les colonnes, et n'as pas forcement toute les contraintes d'integrites de la table "mére".

Sur des vue basique ça peut marcher, par contre je n'en vois pas l'interet? (autant faire les modifs sur la table "mere" )


Cordialement,

[aieeeuuuuu]

L’intérêt peut être de "masquer" un modèle logique complexe pour les applications clientes, qui, avec une simple requête, peuvent alors effectuer des opération plus compliquées...

Cela peut aussi permettre d'autoriser certains utilisateurs à insérer/mettre à jour certaines colonnes d'une table, mais pas toutes !

Enfin (et peut être surtout), cela permet de pouvoir effectuer des modifications sur le modèle de la base sans affecter les applications, qui continueront d'inserer/mettre à jour la vue, sans être perturbée par le changement de structure de la table sous-sous-jacente...

Cela dit, après test sur un SQL Server 2008 avec les scripts de billybob2, l'insertion fonctionne, tout comme la mise à jour...

Je n'ai pas de SQL 2000 sous la main pour tester...

[elsuket]

Bonjour,

Par contre la mise à jour fonctionne ?? :

Il me semble que le message d'erreur est clair.
Faites donc un trigger INSTEAD OF sur cette vue.

Comme l'a dit aieeeuuuuu, tout l'intérêt des vues est là : le modèle externe de données, qui est très rarement utilisé.
Les triggers INSTEAD OF sur les vues sont là pour faire les manipulations de données à la place de l'utilisateur.

On prend pour habitude de manipuler directement les tables, et pourtant cette démarche est fausse.
SQLPro vous en dirait bien plus que moi là-dessus

@++

[SQLpro]

La raison pour laquelle votre vue n'est pas "misajourable" est simple : la fonction inverse (I-1) n'est pas bijective....
Étonnant non ?
Et pourtant vrai ! Devinez pourquoi ????

A +

[billybob2]

Si elle n'est pas "miseajourable" pourquoi l'update fonctionne ?

De plus , l'insertion concerne la colonne I qui n'est pas une fonction mais un champs de type integer ...

[aieeeuuuuu]

Et pourtant vrai ! Devinez pourquoi ????

hmmm,

Peut être car -2 147 483 648 n'a pas d'image par la fonction (I-1), et que 2 147 483 647 n'est l'image d'aucune valeur possible de I ???

[SQLpro]

Exact !!!! bravo !!!! Et du fait de la clause WHERE qui restreint les valeurs dans le cas évoqué d'UPDATE, cette non bijection devient fausse !

Cela dit 2005/2008 est plus fin sur le sujet en acceptant l'insert de I !

A +