De temps en temps, un objet de base de données peut avoir besoin d’être renommé pour diverses raisons. Lorsque cela se produit, les fonctionnalités natives de renommage des objets de base de données SQL Server peuvent être très utiles. Mais, il y a de grandes différences entre le simple fait de renommer des objets de base de données SQL Server dans le SQL Server Management Studio et le fait de les renommer en toute sécurité avec ApexSQL Refactor.
Cet article expliquera les différences entre le renommage des objets de base de données avec SSMS et la fonctionnalité de renommage en toute sécurité d’ApexSQL Refactor.
Dans l’exemple suivant, créons la nouvelle base de données NewDB, et deux tables Users et Address. La table Adresse aura des références étrangères à la table Utilisateurs:
CREATE DATABASE NewDB;CREATE TABLE Users (UserID INT PRIMARY KEY IDENTITY(1, 1),FirstName VARCHAR(20),Lastname VARCHAR(50),Address VARCHAR(250))GOCREATE TABLE Address (ID INT NOT NULL IDENTITY(1, 1),City VARCHAR(120),PostalCode INT,UserAddressID INT FOREIGN KEY REFERENCES Users(UserID))GO
Créons ensuite deux procédures stockées sp_GetUserAddress et sp_GetUserCity :
CREATE PROCEDURE sp_GetUserAddressASBEGINSELECT FirstName,Lastname,AddressFROM UsersENDGOCREATE PROCEDURE sp_GetUserCityASBEGINSELECT Users.FirstName,Users.Lastname,Address.CityFROM UsersINNER JOIN Address ON Users.UserID = Address.UserAddressIDENDGO
Et, à la fin, créez la vue v_Address01 et le déclencheur trgAfterInsert :
CREATE VIEW .ASSELECT ID,City,PostalCode,UserAddressIDFROM dbo.AddressINNER JOIN Users ON Users.UserID = Address.UserAddressIDGOCREATE TRIGGER trgAfterInsert ON .FOR INSERTASPRINT 'Data entered successfully'GO
Renommer les objets de la base de données avec SSMS
Pour voir les dépendances de la table Users, sélectionnez-la dans l’explorateur d’objets et choisissez dans le menu contextuel la commande View Dependencies.
Cette commande ouvre la fenêtre Dépendances d’objets pour la table sélectionnée, dans ce cas pour la table Users. Dans la liste de la fenêtre Dépendances d’objets se trouvent tous les objets de la base de données NewDB, qui dépendent de la table Utilisateurs :
Certains des objets référencés ont des dépendances liées au schéma à la table Users (déclencheur trgAfterInsert et table Address), et certains d’entre eux ont des dépendances non liées au schéma (procédures stockées sp_GetUserCity et sp_GetUserAddress, et vue v_Address01).
Les objets de base de données qui ont des dépendances liées au schéma à la table Users accepteront automatiquement toutes les modifications apportées. Après avoir renommé la table Users, il n’y aura pas d’erreurs liées aux dépendances.
Mais, la modification du nom de la table Users, rendra invalides les objets de dépendances non liés au schéma. Pour utiliser ces objets de base de données après le renommage de la table Users, leur code doit être modifié manuellement.
Pour voir cela en exemple, sélectionnez la table Users dans la fenêtre de l’explorateur d’objets et dans le menu contextuel, cliquez sur la commande Renommer :
Saisissez le nouveau nom de la table Users, par exemple NewUsers et rafraîchissez la base de données NewDB. Dans la liste des tables, elle sera renommée en NewUsers:
Après la saisie du nouveau nom de la table et le rafraîchissement de la base de données, la liste des objets référencés changera. Vérifiez si les dépendances sont modifiées pour la table NewUsers renommée. Une fois de plus, sélectionnez la table NewUsers et cliquez sur la commande View Dependencies :
La liste des objets référencés est maintenant modifiée.
La procédure stockée sp_GetUserAddress ne figure plus dans la liste des objets référencés. L’exécution de cette procédure stockée se terminera par le message suivant :
Msg 208, Level 16, State 1, Procedure sp_GetUserAddress, Line 4
Invalid object name ‘Users’.
En revanche, la procédure stockée sp_GetUserCity et la vue v_Address01 sont toujours dans la liste, mais lorsqu’elles sont utilisées, des erreurs sont générées :
Msg 208, Niveau 16, État 1, Procédure sp_GetUserCity, Ligne 8
Invalid object name ‘dbo.Users’.
Msg 208, Niveau 16, Etat 1, Procédure v_Address01, Ligne 8
Invalide object name ‘dbo.Users’.
Msg 4413, Niveau 16, État 1, Ligne 1
Peut pas utiliser la vue ou la fonction ‘v_Address01’ à cause d’erreurs de liaison.
Ce qui prouve que renommer une table, avec SSMS, ne va pas automatiquement mettre à jour tous les objets de la base de données qui y font référence. Le code des objets qui ont des dépendances non liées au schéma à la table Users, doit être mis à jour manuellement. Tant que le script de chaque objet n’est pas ouvert et que chaque référence à la table Users n’est pas changée en NewUsers, vous ne pouvez pas continuer à utiliser ces objets sans erreur.
Renommer les objets de base de données avec ApexSQL Refactor
ApexSQL Refactor, ajout – in de Visual Studio et SSMS, fournit plus de 200 options de formatage et 15 refactors de code pour formater et refactorer le code SQL et les objets de base de données.
L’une des fonctionnalités de refactoring du code SQL d’ApexSQL Refactor est Safe rename. Cette fonctionnalité permet de renommer les objets de SQL Server sans rompre les dépendances de la base de données. Les objets de la base de données qui peuvent être renommés avec cette fonctionnalité d’ApexSQL Refactor sont : les tables, les vues, les procédures, les fonctions, les colonnes des tables/vues et les paramètres des procédures/fonctions.
Pour voir comment la fonctionnalité Safe rename fonctionne, sélectionnez la table Users dans l’explorateur d’objets et dans le menu contextuel, cliquez sur la commande Safe rename :
Ou choisissez la même option dans le menu principal d’ApexSQL Refactor :
La fenêtre Safe rename apparaîtra :
Dans les champs, New schema et New name sont le schéma et le nom de la table sélectionnée.
La notification – triangle jaune clignotant – indique que la table avec ce schéma et ce nom existe déjà.
Dans cette fenêtre, le schéma de la table peut être modifié en choisissant l’un des schémas de base de données existants dans la liste déroulante. Lors du renommage d’une table avec SSMS, cela ne fait pas partie des options. Pour cette raison, pour cet exemple, le schéma de la table ne sera pas modifié.
Insérer le nouveau nom de la table dans le champ Nouveau nom. La chose importante à savoir est qu’il n’y a pas de restrictions pour les caractères utilisés. Pour cet exemple, le nouveau nom de la table Users sera NewUsers.
Cliquez sur le bouton Aperçu, situé dans le coin inférieur gauche de la fenêtre Safe rename.
Sous l’onglet Generated script se trouve le script de refactoring T-SQL qui, après exécution, renommera la table Users. Dans cette fenêtre, le script ne peut pas être modifié, il peut seulement être examiné :
Tous les avertissements liés à la table de renommage, seront sous l’onglet Avertissements. Pour cet exemple, il n’y a pas d’avertissements:
Pour vérifier toutes les actions qui seront exécutées pour renommer la table Utilisateurs, cliquez sur l’onglet Séquence. Toutes les actions sont ordonnées de cette manière, de sorte que leurs exécutions empêcheront de rompre les dépendances entre les objets :
Sous l’onglet Dépendances, il y a une liste de tous les objets de base de données référencés à la table Users. ApexSQL Refactor ne fait pas de différence entre les objets de dépendances liés au schéma et ceux qui ne le sont pas, car tous les objets référencés seront mis à jour quel que soit le type de dépendances à la table Users:
Pour renommer la table Users, il suffit de cliquer sur le bouton Créer un script. Le script généré sera ouvert dans la fenêtre de l’éditeur de requêtes SSMS :
Dans l’éditeur de requêtes, le script peut être modifié ou il peut être exécuté tel quel. Après exécution, le message suivant apparaîtra :
Attention : La modification d’une partie du nom d’un objet pourrait casser les scripts et les procédures stockées.
Après avoir rafraîchi la base de données NewDB dans la liste des tables, au lieu de la table Users sera la table NewUsers, comme après avoir renommé la table avec SSMS, mais avec une grande différence – aucun des objets référencés n’est non valide.
Pour vérifier, si les dépendances de la table renommée NewUsers sont vérifiées avec la fonctionnalité SSMS View dependencies, cette liste apparaîtra :
Cette liste est exactement la même que la première, avant de changer le nom de la table avec ApexSQL Refactor.
Avec la fonctionnalité Safe rename d’ApexSQL Refactor, il est plus facile de renommer la table et qui plus est, sans travail supplémentaire pour changer tous les objets référencés. De plus, dans une seule fenêtre, tout ce qui concerne le renommage peut être vérifié (avertissements, séquences, dépendances).
Cet exemple a montré comment renommer une table, mais les mêmes étapes sont pour renommer n’importe quel objet de la base de données SQL Server (colonnes de table/vue, paramètres de fonction/procédure, vues, fonctions, procédures).