Van tijd tot tijd kan het om verschillende redenen nodig zijn om een databaseobject een andere naam te geven. Wanneer dat gebeurt, kunnen de ingebouwde functies voor het hernoemen van SQL Server-databaseobjecten zeer nuttig zijn. Maar er zijn grote verschillen tussen het hernoemen van SQL Server database objecten in SQL Server Management Studio en het veilig hernoemen met ApexSQL Refactor.
In dit artikel worden de verschillen uitgelegd tussen het hernoemen van database objecten met SSMS en de ApexSQL Refactor’s Veilige hernoem functie.
In het volgende voorbeeld, maken we een nieuwe database NewDB, en twee tabellen Gebruikers en Adres. De tabel Adres krijgt Foreign references naar de tabel Gebruikers:
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
Maak vervolgens twee opgeslagen procedures sp_GetUserAddress en 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
En maak aan het einde view v_Address01 en 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
Bankobjecten hernoemen met SSMS
Om de afhankelijkheden voor de tabel Gebruikers te bekijken, selecteert u deze in de Objectverkenner en kiest u in het contextmenu de opdracht Afhankelijkheden weergeven.
Met deze opdracht wordt het venster Object Dependencies geopend voor de geselecteerde tabel, in dit geval voor de tabel Gebruikers. In de lijst in het Object Dependencies venster staan alle objecten uit de database NewDB, die afhankelijk zijn van de tabel Gebruikers:
Sommige van de objecten waarnaar wordt verwezen, hebben schema-gebonden afhankelijkheden met de tabel Gebruikers (trigger trgAfterInsert en tabel Adres), en sommige hebben niet-schema-gebonden afhankelijkheden (stored procedures sp_GetUserCity en sp_GetUserAddress, en view v_Address01).
Databaseobjecten die schemagebonden afhankelijkheden hebben met de tabel Gebruikers zullen automatisch alle aangebrachte wijzigingen accepteren. Na het hernoemen van de tabel Gebruikers, zullen er geen afhankelijkheidsgerelateerde fouten optreden.
Maar, de naamswijziging van de tabel Gebruikers, zal de niet-schema gebonden afhankelijkheden objecten ongeldig maken. Om deze databaseobjecten te gebruiken nadat de tabel Gebruikers is hernoemd, moet hun code handmatig worden aangepast.
Om dat in een voorbeeld te zien, selecteert u de tabel Gebruikers in het venster Object Explorer en klikt u in het contextmenu op de opdracht Hernoemen:
Voer een nieuwe naam in voor de tabel Gebruikers, bijvoorbeeld NewUsers en ververs de database NewDB. In de lijst met tabellen wordt de naam gewijzigd in NewUsers:
Nadat de nieuwe naam voor de tabel is ingevoerd en de database is vernieuwd, wordt de lijst met objecten waarnaar wordt verwezen, gewijzigd. Controleer of de afhankelijkheden zijn gewijzigd voor de hernoemde tabel NewUsers. Selecteer nogmaals de tabel NewUsers en klik op het commando View Dependencies:
De lijst met objecten waarnaar wordt verwezen is nu gewijzigd.
De opgeslagen procedure sp_GetUserAddress staat niet meer op de lijst met objecten waarnaar wordt verwezen. Uitvoering van deze opgeslagen procedure zal eindigen met de volgende boodschap:
Msg 208, Level 16, State 1, Procedure sp_GetUserAddress, Line 4
Ongeldige objectnaam ‘Users’.
Aan de andere kant staan de opgeslagen procedure sp_GetUserCity en de view v_Address01 nog steeds op de lijst, maar wanneer deze worden gebruikt, zullen er fouten optreden:
Msg 208, Level 16, State 1, Procedure sp_GetUserCity, Line 8
Ongeldige objectnaam ‘dbo.Users’.
Msg 208, Level 16, State 1, Procedure v_Address01, Line 8
Objectnaam ‘dbo.Users’ ongeldig.
Msg 4413, Level 16, State 1, Line 1
Kan view of functie ‘v_Address01’ niet gebruiken vanwege bindingsfouten.
Dit bewijst dat het hernoemen van een tabel, met SSMS, niet automatisch alle database objecten zal updaten die er naar verwijzen. De code van de objecten die niet-schema gebonden afhankelijkheden hebben naar de tabel Gebruikers, moet handmatig worden bijgewerkt. Totdat elk objectscript is geopend en elke verwijzing naar de tabel Users is gewijzigd in NewUsers, kunt u deze objecten niet zonder fouten blijven gebruiken.
Hernoemen van database objecten met ApexSQL Refactor
ApexSQL Refactor, Visual Studio en SSMS add – in, biedt meer dan 200 opmaak opties en 15 code refactors voor het opmaken en refactoren van SQL code en database objecten.
Eén van de SQL code refactoring functies van ApexSQL Refactor is Safe rename. Deze functie biedt de mogelijkheid om SQL Server objecten te hernoemen zonder de database afhankelijkheden te verbreken. Database objecten die kunnen worden hernoemd met deze ApexSQL Refactor feature zijn: tabellen, views, procedures, functies, tabel/view kolommen en procedures/functie parameters.
Om te zien hoe de Safe rename feature werkt, selecteer de tabel Users in de Object Explorer en klik in het context menu op Safe rename command:
Of kies dezelfde optie uit het ApexSQL Refactor hoofdmenu:
Het venster Veilig hernoemen verschijnt:
In de velden Nieuw schema en Nieuwe naam staan het schema en de naam van de geselecteerde tabel.
Melding – geel knipperende driehoek – geeft aan dat de tabel met dit schema en deze naam al bestaat.
In dit venster kan het schema van de tabel worden gewijzigd door een van de bestaande databaseschema’s uit de vervolgkeuzelijst te kiezen. Bij het hernoemen van een tabel met SSMS behoort dit niet tot de mogelijkheden. Daarom zal in dit voorbeeld het tabel schema niet worden gewijzigd.
Voeg een nieuwe tabelnaam in in het veld Nieuwe naam. Het belangrijkste om te weten is dat er geen beperkingen zijn voor de gebruikte karakters. In dit voorbeeld wordt de nieuwe naam voor de tabel Gebruikers NewUsers.
Klik op de knop Voorbeeld, linksonder in het venster Veilige hernoeming.
Onder de tab Gegenereerd script staat het T-SQL refactoring script dat na uitvoering de tabel Gebruikers zal hernoemen. In dit venster kan het script niet worden gewijzigd, maar alleen worden bekeken:
Alle waarschuwingen met betrekking tot de tabel hernoemen, staan onder het tabblad Waarschuwingen. In dit voorbeeld zijn er geen waarschuwingen:
Om alle acties te controleren die zullen worden uitgevoerd voor het hernoemen van de tabel Gebruikers, klikt u op het tabblad Volgorde. Alle acties zijn op die manier gerangschikt, zodat hun uitvoering voorkomt dat afhankelijkheden tussen de objecten worden verbroken:
Onder het tabblad Afhankelijkheden bevindt zich een lijst met alle databaseobjecten waarnaar wordt verwezen voor de tabel Gebruikers. ApexSQL Refactor maakt geen onderscheid tussen schema-gebonden en niet-schema-gebonden afhankelijkheidsobjecten, omdat alle objecten waarnaar wordt verwezen worden bijgewerkt, ongeacht het type afhankelijkheden van de tabel Gebruikers:
Voor het hernoemen van de tabel Gebruikers klikt u eenvoudig op de knop Script maken. Het gegenereerde script wordt geopend in het venster SSMS Query-editor:
In de Query-editor kan het script worden gewijzigd of het kan worden uitgevoerd zoals het is. Na uitvoering verschijnt het volgende bericht:
Let op: Het wijzigen van een deel van een objectnaam kan scripts en stored procedures breken.
Na het verversen van database NewDB in de tabel lijst, zal in plaats van de tabel Users de tabel NewUsers zijn, hetzelfde als na het hernoemen van de tabel met SSMS, maar met één groot verschil – geen van de objecten waarnaar verwezen wordt zijn niet ongeldig.
Even ter controle, als de afhankelijkheden voor de hernoemde tabel NewUsers worden gecontroleerd met de SSMS View dependencies-functie, verschijnt deze lijst:
Deze lijst is precies hetzelfde als de eerste, voordat de naam van de tabel met ApexSQL Refactor werd gewijzigd.
Met ApexSQL Refactor’s Safe rename functie is het eenvoudiger om de tabel te hernoemen en wat meer is, zonder extra werk voor het veranderen van alle objecten waarnaar verwezen wordt. Ook kunnen in een venster alle zaken met betrekking tot het hernoemen worden gecontroleerd (waarschuwingen, volgordes, afhankelijkheden).
Dit voorbeeld laat zien hoe een tabel te hernoemen, maar dezelfde stappen zijn voor het hernoemen van elk van de SQL Server database objecten (tabel/view kolommen, functie/procedures parameters, views, functies, procedures).