Vue vide suite à la mise à jour du schéma

Bonsoir,

Sur une application que je gère depuis maintenant près de 4 ans, il m'arrive un petit bug de temps en temps, et je ne sais absolument pas d'où cela peut venir. Du coup, je demande l'avis d'experts :)

Voici le problème : parfois, après la mise à jour du schéma de ma base, certaines vues ne retourne plus aucune valeur. Un SELECT * sur la vue ne me retourne plus aucun enregistrement, sans message d'erreur. Cela se produit parfois si je modifie une table utilisée par ma vue (mais pas tout le temps).

Si je vais dans SQL Management Studio, que je fais un clic-droit sur ma vue et que je génère un script ALTER VIEW et que je l'exécute (sans modification donc), alors tout rentre dans l'ordre.

D'où peut venir le problème ? Serait-ce un problème lié au cache des plans d'exécution (et le ALTER VIEW viendrait nettoyer le cache) ? Mais si c'est le cas, SQL Server ne devrait-il pas vide le cache automatiquement si une des tables utilisées par la vue change ?

Merci d'avance pour vos éclairages :)

Bonjour,

Les changements de schéma doivent altérer les vues, ou alors la définition des vues est changée avant le schéma.
Il vous faut ajouter un EXEC sp_refreshview sur les vues impactées une fois toutes les instructions DDL exécutées.

@++;)

Merci pour les infos. Mais si le SGBD ne fait pas cela automatiquement, c'est qu'il doit y avoir une raison. Et Microsoft a bien dû réfléchir au problème, sinon, il n'y aurait pas cette procédure à exécuter afin de mettre à jour les vues. Mais j'avoue ne pas avoir d'idée concernant le pourquoi.

Serait-ce pour éviter de mettre à jour les vues à chaque instruction DDL, et de permettre ainsi de ne mettre à jour les vues qu'une seule fois une fois l'ensemble des instructions DDL ait été exécuté ?

Que se passe-t-il si tu les bind au schéma ?

Attention cependant : même si en soit c'est "mieux", ça implique quelques limitations, notamment quand on modifie les tables sur lesquelles se basent les vues :
http://stackoverflow.com/questions/1...-in-sql-server

J'avoue ne pas avoir testé dans cette configuration. Dans la mesure où l'application évolue sans cesse (c'est une application dans le domaine médical, et entre les nouveaux besoins utilisateurs, l'évolution du cadre légal, etc...) je suis obligé de mettre régulièrement à jour le schéma de ma base (au moins une fois par mois). En règle général, ce ne sont pas des grosses modifs (dans 90% des cas, se sont simplement des colonnes à rajouter ou de nouvelles tables), mais il arrive qu'il y ait des chamboulements plus ou moins important.

Je préfère faire un ALTER VIEW quand le soucis se pose (ou essayer un EXEC sp_refreshview) que de m'enquiquiner avec le schema binding qui serait plus lourd en terme de maintenance sans véritable gain pour l'application, dans la mesure où je n'utilise pas de vues indexées, que la base de données est propre à l'application et que je suis le seul développeur à modifier la base. (il faudrait que je supprime l'ensemble de mes vues avant de pouvoir intervenir sur mes tables pour ensuite recréer mes vues).

Ma question initiale c'était juste pour essayer de comprendre ce qui se passe exactement, car autant je peux comprendre qu'une vue soit "cassée" si par exemple, on supprime une colonne d'une table référencée par la vue, autant je suis surpris que l'ajout d'une colonne puisse "invalider" la vue sans erreur, si ce n'est qu'un SELECT * sur la vue ne revoit plus aucun enregistrement.

Citation:

---

Envoyé par dorinf

Ma question initiale c'était juste pour essayer de comprendre ce qui se passe exactement, car autant je peux comprendre qu'une vue soit "cassée" si par exemple, on supprime une colonne d'une table référencée par la vue, autant je suis surpris que l'ajout d'une colonne puisse "invalider" la vue sans erreur, si ce n'est qu'un SELECT * sur la vue ne revoit plus aucun enregistrement.

---

C'est parfaitement normal, justement parce que vous utilisez un SELECT * !
C'est d'ailleurs stupide d'utiliser le SELECT * en général et plus en particulier sur une vue...

En effet avec un SELECT * le moteur doit impérativement retrouver toutes les colonnes et donc va taper dans les tables de méta données pour construire le plan de requête qui est mis en cache. Si l'une quelconque des tables est modifiée et quelque soit cette modif, alors le plan est invalidé...
La solution consiste...
1) a éviter le SELECT *
2) a utiliser un sp_refreshview sur l'ensemble des vues après passage d'ordre DDL

Pour le point 2, vous pouvez utiliser le script suivant :

Code:

---

1 2 3 4

DECLARE @SQL NVARCHAR(max) = N''; SELECT @SQL = @SQL + N'EXEC sp_refreshview ''' + TABLE_SCHEMA + N'.' + TABLE_NAME + N''';' FROM INFORMATION_SCHEMA.VIEWS; EXEC (@SQL);

---

Et pour de plus amples informations :
Pièce jointe 216981

Citation:

---

Envoyé par SQLpro

C'est parfaitement normal, justement parce que vous utilisez un SELECT * !
C'est d'ailleurs stupide d'utiliser le SELECT * en général et plus en particulier sur une vue...

---

Alors pour que les choses soient claires (car il est vrai que je ne l'avais pas précisé) : quand je faisais le SELECT *, c'était avec Management Studio afin de faire des tests pour essayer de comprendre ce qui se passe. J'évite d'utiliser les SELECT * dans mes programmes. Je ne l'utilise que lorsque je fais des requêtes ponctuelles pour un traitement à la mano.

Citation:

---

Envoyé par SQLpro

En effet avec un SELECT * le moteur doit impérativement retrouver toutes les colonnes et donc va taper dans les tables de méta données pour construire le plan de requête qui est mis en cache. Si l'une quelconque des tables est modifiée et quelque soit cette modif, alors le plan est invalidé...
La solution consiste...
1) a éviter le SELECT *
2) a utiliser un sp_refreshview sur l'ensemble des vues après passage d'ordre DDL

---

Et c'est là où je viens de me faire avoir. Car même si j'évite le SELECT * dans mes programmes, les 2 vues qui me posent problèmes à chaque fois... l'utilise ! Alors qu'en plus cela n'est même pas nécessaire... (sachant que les deux vues sont proches et l'une est issu d'un copier/coller de l'autre). Bref, je devais être fatigué ce jour là, faire une requête à la va-vite pour tester un truc et ensuite faire un copier/coller pour la transformer en vue. Mais au moins, maintenant, je sais quoi faire pour éviter le soucis à l'avenir. Merci :)

Citation:

---

Envoyé par SQLpro

Et pour de plus amples informations :
Pièce jointe 216981

---

Il est déjà commandé. Depuis samedi ! Avec de la chance, il arrive demain !!!!