Di tanto in tanto, un oggetto del database potrebbe aver bisogno di essere rinominato per vari motivi. Quando ciò accade, le funzioni native per rinominare gli oggetti del database di SQL Server possono essere molto utili. Ma ci sono grandi differenze tra rinominare semplicemente gli oggetti del database di SQL Server in SQL Server Management Studio e rinominarli in modo sicuro con ApexSQL Refactor.
Questo articolo spiegherà le differenze tra rinominare gli oggetti del database con SSMS e la funzione Safe rename di ApexSQL Refactor.
Nel seguente esempio, creiamo il nuovo database NewDB, e due tabelle Users e Address. La tabella Address avrà dei riferimenti esterni alla tabella Users:
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
Poi creiamo due stored procedure sp_GetUserAddress e 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
E, alla fine, create la vista v_Address01 e il trigger 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
Rinomina gli oggetti del database con SSMS
Per vedere le dipendenze per la tabella Utenti, selezionala nell’Esplora oggetti e scegli dal menu di contesto il comando Visualizza dipendenze.
Questo comando aprirà la finestra Object Dependencies per la tabella selezionata, in questo caso per la tabella Users. Nell’elenco della finestra Object Dependencies ci sono tutti gli oggetti del database NewDB, che dipendono dalla tabella Users:
Alcuni degli oggetti referenziati hanno dipendenze schema-bound dalla tabella Utenti (trigger trgAfterInsert e tabella Indirizzo), e alcuni di essi hanno dipendenze non schema-bound (stored procedure sp_GetUserCity e sp_GetUserAddress, e vista v_Address01).
Gli oggetti del database che hanno dipendenze legate allo schema della tabella Users accetteranno automaticamente tutti i cambiamenti fatti. Dopo aver rinominato la tabella Utenti, non ci saranno errori relativi alle dipendenze.
Ma, la modifica del nome della tabella Utenti, renderà non validi gli oggetti con dipendenze non legate allo schema. Per usare questi oggetti del database dopo che la tabella Utenti è stata rinominata, il loro codice deve essere modificato manualmente.
Per vederlo nell’esempio, seleziona la tabella Utenti nella finestra Esplora oggetti e dal menu contestuale clicca sul comando Rinomina:
Inserisci il nuovo nome della tabella Utenti, per esempio NewUsers e aggiorna il database NewDB. Nell’elenco delle tabelle sarà rinominata come NewUsers:
Dopo aver inserito il nuovo nome per la tabella e aver aggiornato il database, l’elenco degli oggetti referenziati cambierà. Controlla se le dipendenze sono cambiate per la tabella NewUsers rinominata. Ancora una volta, seleziona la tabella NewUsers e clicca sul comando View Dependencies:
L’elenco degli oggetti referenziati è ora cambiato.
La stored procedure sp_GetUserAddress non è più nella lista degli oggetti referenziati. L’esecuzione di questa stored procedure terminerà con il seguente messaggio:
Msg 208, Level 16, State 1, Procedure sp_GetUserAddress, Line 4
Nome oggetto non valido ‘Utenti’.
D’altra parte, la stored procedure sp_GetUserCity e la vista v_Address01 sono ancora nella lista, ma quando queste sono usate, vengono sollevati degli errori:
Msg 208, Level 16, State 1, Procedure sp_GetUserCity, Line 8
Nome oggetto non valido ‘dbo.Users’.
Msg 208, Level 16, State 1, Procedure v_Address01, Line 8
Nome oggetto non valido ‘dbo.
Msg 4413, Level 16, State 1, Line 1
Non è stato possibile utilizzare la vista o la funzione ‘v_Address01’ a causa di errori di binding.
Questo dimostra che rinominare una tabella, con SSMS, non aggiorna automaticamente tutti gli oggetti del database che fanno riferimento ad essa. Il codice degli oggetti che hanno dipendenze non legate allo schema della tabella Utenti, deve essere aggiornato manualmente. Finché ogni script degli oggetti non viene aperto e ogni riferimento alla tabella Utenti cambiato in NewUsers, non è possibile continuare a usare questi oggetti senza errori.
Rinominare gli oggetti del database con ApexSQL Refactor
ApexSQL Refactor, add – in di Visual Studio e SSMS, fornisce oltre 200 opzioni di formattazione e 15 refactor di codice per la formattazione e il refactoring del codice SQL e degli oggetti del database.
Una delle caratteristiche di refactoring del codice SQL di ApexSQL Refactor è Safe rename. Questa caratteristica permette di rinominare gli oggetti di SQL Server senza rompere le dipendenze del database. Gli oggetti del database che possono essere rinominati con questa caratteristica di ApexSQL Refactor sono: tabelle, viste, procedure, funzioni, colonne di tabelle/viste e parametri di procedure/funzioni.
Per vedere come funziona la funzione Safe rename, selezionare la tabella Users in Object Explorer e dal menu contestuale fare clic sul comando Safe rename:
Oppure scegliere la stessa opzione dal menu principale di ApexSQL Refactor:
La finestra Safe rename apparirà:
Nei campi, New schema e New name sono lo schema e il nome della tabella selezionata.
Notifica – triangolo giallo lampeggiante – mostra che la tabella con questo schema e nome esiste già.
In questa finestra, lo schema della tabella può essere cambiato scegliendo uno degli schemi di database esistenti dall’elenco a discesa. Quando si rinomina una tabella con SSMS questa non è una delle opzioni. Per questo motivo, per questo esempio lo schema della tabella non verrà cambiato.
Inserisci il nuovo nome della tabella nel campo Nuovo nome. La cosa importante da sapere è che non ci sono restrizioni per i caratteri in uso. Per questo esempio, il nuovo nome per la tabella Users sarà NewUsers.
Clicca sul pulsante Preview, situato nell’angolo in basso a sinistra della finestra Safe rename.
Sotto la scheda Generated script è presente lo script T-SQL refactoring che dopo l’esecuzione rinominerà la tabella Users. In questa finestra, lo script non può essere modificato, può solo essere rivisto:
Tutti gli avvertimenti relativi alla tabella rinominata, saranno sotto la scheda Avvertimenti. Per questo esempio, non ci sono avvertimenti:
Per controllare tutte le azioni che saranno eseguite per rinominare la tabella Utenti, clicca sulla scheda Sequenza. Tutte le azioni sono ordinate in questo modo, quindi la loro esecuzione eviterà di rompere le dipendenze tra gli oggetti:
Sotto la scheda Dependencies, c’è un elenco di tutti gli oggetti del database referenziati alla tabella Users. ApexSQL Refactor non fa differenza tra gli oggetti di dipendenza legati allo schema e quelli non legati allo schema, perché tutti gli oggetti referenziati saranno aggiornati indipendentemente dal tipo di dipendenza dalla tabella Utenti:
Per rinominare la tabella Utenti basta cliccare sul pulsante Crea script. Lo script generato verrà aperto nella finestra dell’editor di query di SSMS:
Nell’editor di query, lo script può essere modificato o può essere eseguito così com’è. Dopo l’esecuzione, apparirà il seguente messaggio:
Attenzione: Cambiare qualsiasi parte del nome di un oggetto potrebbe interrompere gli script e le stored procedure.
Dopo aver aggiornato il database NewDB nell’elenco delle tabelle, invece della tabella Users ci sarà la tabella NewUsers, come dopo aver rinominato la tabella con SSMS, ma con una grande differenza – nessuno degli oggetti referenziati non è valido.
Solo per controllare, se le dipendenze per la tabella NewUsers rinominata sono controllate con la funzione SSMS View dependencies, apparirà questa lista:
Questa lista è esattamente la stessa della prima, prima di cambiare il nome della tabella con ApexSQL Refactor.
Con la funzione Safe rename di ApexSQL Refactor è più facile rinominare la tabella e per di più senza alcun lavoro aggiuntivo per cambiare tutti gli oggetti referenziati. Inoltre, in una finestra si possono controllare tutte le cose riguardanti la rinomina (avvertimenti, sequenze, dipendenze).
Questo esempio ha mostrato come rinominare una tabella, ma gli stessi passi sono per rinominare qualsiasi oggetto del database SQL Server (colonne di tabelle/viste, parametri di funzioni/procedure, viste, funzioni, procedure).