Discussion :

[VITALTH]

Bonjour,
Lorsqu'on clique droit sur une vue et qu'on choisie "Générer un script de la vue en tant que ALTER to", on vois l'instruction correspondant à l'intruction SQL de la vue avec la requête qui a servi à sa définition.
Jusqu'ici je me disait c'était facile de générer ce script grâce au table sys.sql_modules et sys.objects qui conntiennent les définitions (requête de création de vue) et les nom de la vue.
Si maintenant je clique droit que tu je renomme. Admettons que ma vue s'appelait VIEW1 et je la renomme en VIEW2, Si je regarde la colonne définition dans sql_modules j'ai toujours "CREATE VIEWS AS VIEW1...." : il n'a pas remplacé VIEW1 par VIEW2.
Cependant si je choisis "Générer un script de la vue en tant que ALTER to" : il m'a remplacé VIEW1 par VIEW2 : je me demandais sur quel table il s'appuie pour générer ça ou est ce que c'est de l'analyse syntaxique.

Merci pour votre réponse.

[SQLpro]

les références sont mise à jour uniquement s'il y a recompilation. tant que tu lit l'IHM, il n'y a pas relance de la lecture, sauf si tu fait "reactualiser" !

A +

[Invité]

C'est vraisemblablement un bug de SSMS.
J'ai aussi remarqué que le cache de SSMS ne se rafraichit pas automatiquement et ressort parfois des informations qui ont été modifié.
Il est toujours prudent de lancer un refresh sur l'explorateur d'objet pour récupérer les informations.

[hmira]

C'est vraisemblablement un bug de SSMS.

Non ce n'est pas un bug ni de SSMS. Ce n'est pas non plus un bug de SQL Server.

Il s'agit selon Microsoft d'un fonctionnement normal, en tout cas, en qui concerne la vue sys.sql_modules et la colonne definition

Microsoft stipule les points suivants :

1 - sys.sql_modules stocke le script réel spécifié lors de la création d'un module (procédures stockées, fonctions, déclencheurs (trigger) et vues utilisateurs).

2 - Renommer une procédure stockée, une fonction, un déclencheur (trigger) ou une vue ne changera pas le nom de l'objet correspondant dans le contenu de la colonne definition de la vue système sys.sql_modules.

3 - Microsoft recommande de ne pas utiliser sp_rename pour renommer ces types d'objets (procedures stockées, fonctions, déclencheurs (trigger) et vues utilisateurs). Au lieu de cela, Microsoft recommande de supprimez, puis de recréez l'objet avec son nouveau nom.

Remarque :

1 - D'après les tests que j'ai effectués j'ai constaté qu'effectivement, ni sys.sp_refreshview, ni sys.sp_refreshsqlmodule ne permettent de rafraîchir la définition de la vue système sys.sql_modules (colonne definition) !

2 - Le seul moyen que j'ai trouvé pour rafraîchir la définition de la vue après un sp_rename, est d'enchainer le sp_rename par un alter view nouveau_nom_de_vue ..

Code SQL :

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

1
2
3
Alter View Nouveau_Nom_de_vue 
 AS 
 ... (définition identique de la vue !) ...

3 - Tout cela pose quand même un problème ; c.à.d. qu'on ne peut pas se fier à 100% sur la colonne definition de la vue système sys.sql_modules ! En effet compte-tenu des éléments cités ci-dessus, le contenu de la colonne definition de la vue système sys.sql_modules peut être complètement faux !

A+

[VITALTH]

Oui je suis d'accord avec himra.

Il n'en reste pas moins intéressant de constater que si on utilise la commande sp_rename en SQL (ou on clique droit et renommer dans SSMS), la vue est modifiée et pas la définition dans sql_modules.
MAIS
Lorsqu'on clique droit sur la vue et on demande de créer le script de CREATE TO ou ALTER TO : SSMS génère bien le script avec le nouveau nom de la vue. Du coup je me demande comment SSMS fait ça avec les informations erronnées qu'il a en stocke.

[hmira]

Oui je suis d'accord avec himra.

Il n'en reste pas moins intéressant de constater que si on utilise la commande sp_rename en SQL (ou on clique droit et renommer dans SSMS), la vue est modifiée et pas la définition dans sql_modules.
MAIS
Lorsqu'on clique droit sur la vue et on demande de créer le script de CREATE TO ou ALTER TO : SSMS génère bien le script avec le nouveau nom de la vue. Du coup je me demande comment SSMS fait ça avec les informations erronnées qu'il a en stocke.

Oui effectivement, votre remarque est très juste. Ci-dessous quelques éléments d'explication :

Si vous regarder de très près ce que fait SSMS lors de la génération du script de la vue, vous verrez, parmi d'autres commandes, la commande T-SQL ci-après.

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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
exec sp_executesql N'SELECT
CAST(
        serverproperty(N''Servername'')
       AS sysname) AS [Server_Name],
db_name() AS [Database_Name],
SCHEMA_NAME(v.schema_id) AS [Schema],
v.name AS [Name],
CAST(ISNULL(OBJECTPROPERTYEX(v.object_id,N''ExecIsQuotedIdentOn''),0) AS bit) AS [QuotedIdentifierStatus],
CAST(
 case 
    when v.is_ms_shipped = 1 then 1
    when (
        select 
            major_id 
        from 
            sys.extended_properties 
        where 
            major_id = v.object_id and 
            minor_id = 0 and 
            class = 1 and 
            name = N''microsoft_database_tools_support'') 
        is not null then 1
    else 0
end          
             AS bit) AS [IsSystemObject],
CAST(ISNULL(OBJECTPROPERTYEX(v.object_id,N''ExecIsAnsiNullsOn''),0) AS bit) AS [AnsiNullsStatus],
CAST(ISNULL(OBJECTPROPERTYEX(v.object_id, N''IsSchemaBound''),0) AS bit) AS [IsSchemaBound],
CAST(CASE WHEN ISNULL(smv.definition, ssmv.definition) IS NULL THEN 1 ELSE 0 END AS bit) AS [IsEncrypted],
CAST(0 AS bit) AS [HasColumnSpecification],
v.has_opaque_metadata AS [ReturnsViewMetadata],
v.object_id AS [ID],
ISNULL(sv.name, N'''') AS [Owner],
CAST(case when v.principal_id is null then 1 else 0 end AS bit) AS [IsSchemaOwned],
NULL AS [Text],
ISNULL(smv.definition, ssmv.definition) AS [Definition]
FROM
sys.all_views AS v
LEFT OUTER JOIN sys.sql_modules AS smv ON smv.object_id = v.object_id
LEFT OUTER JOIN sys.system_sql_modules AS ssmv ON ssmv.object_id = v.object_id
LEFT OUTER JOIN sys.database_principals AS sv ON sv.principal_id = ISNULL(v.principal_id, (OBJECTPROPERTY(v.object_id, ''OwnerId'')))
WHERE
(v.type = @_msparam_0)and(v.name=@_msparam_1 and SCHEMA_NAME(v.schema_id)=@_msparam_2)
ORDER BY
[Database_Name] ASC,[Schema] ASC,[Name] ASC',N'@_msparam_0 nvarchar(4000),@_msparam_1 nvarchar(4000),@_msparam_2 nvarchar(4000)',@_msparam_0=N'V',@_msparam_1=N'vw_MaVue_NouveauNom',@_msparam_2=N'dbo'

SSM récupère depuis la vue système sys.sql_modules as smv (smv.definition) la définition erronée (fausse) de la vue, dans mon exemple, la définition smv.definition est erronée, elle contient vw_MaVue (ancien nom) au lieu du nouveau nom vw_MaVue_NouveauNom !

Le nouveau nom (correct), vw_MaVue_NouveauNom, est obtenu depuis la vue système sys.all_views as v (colonne v.name)

SSMS, par un tour de passe, (par un traitement interne à SSMS de type "String Replace" !) modifie et transforme cette définition fausse pour produire en résultat une définition correcte.

Comme vous avez pu le constater, tout ceci manque de clarté et de rigueur.

C'est une des raisons pour la quelle, il est fortement déconseillé de renommer les vues, et plus généralement les procédures stockées, fonctions et triggers (déclencheurs).

A+

[VITALTH]

D'accord c'est ce que je pensais mais je n'en étais pas sur.
Merci