SQL Source Control sluit aan op SSMS en verbindt uw databases met uw versiebeheersysteem, zodat u uw databaseschema’s kunt versiebeheer, en ze vervolgens kunt implementeren met behulp van Redgate’s vertrouwde vergelijkingsengine SQL Compare.
De nieuwste release (deze week verzonden!) bevat een verbeterde versie van migratiescripts, waarmee u uw eigen SQL kunt schrijven om het door SQL Compare gegenereerde implementatiescript te overschrijven, zodat uw teamgenoten de laatste wijzigingen uit de broncontrole kunnen halen zonder het risico te lopen gegevens te verliezen. U kunt meer te weten komen over wat we hebben gedaan, en waarom, in een andere recente blogpost van mij.
Maar hier, wilde ik u vertellen hoe het werkt met behulp van een veelvoorkomend scenario.
Hoe gegevensverlies te voorkomen bij het hernoemen van een tabel
Voorkomende taken die hierdoor beïnvloed kunnen worden zijn het splitsen of samenvoegen van kolommen en tabellen, het toevoegen van een NOT NULL constraint aan een kolom, het wijzigen van het datatype of de grootte van een kolom, en het hernoemen van een tabel.
In het geval van het hernoemen van een tabel in uw ontwikkel database, zou SQL Source Control deze wijziging interpreteren als een DROP en een CREATE. Als een ander lid van uw team de Get latest tab gebruikt om deze wijzigingen op te halen, gaan gegevens in de doeltabel verloren.
Om dit gegevensverlies te voorkomen, kunt u een migratiescript schrijven om de tabel te hernoemen met behulp van de sp_rename stored procedure. Dit script vervangt de DROP en CREATE statements die de SQL Compare engine anders voor deze wijziging zou genereren.
Als u de tabel eenmaal hebt hernoemd (in dit geval van users naar customers), is de volgende stap het vastleggen van de wijzigingen in uw bronbeheersysteem met behulp van het tabblad Commit changes in SQL Source Control. SQL Source Control waarschuwt u dat er gegevensverlies kan optreden als u de wijziging vastlegt en stelt voor dat u een migratiescript schrijft.
Op het tabblad Migraties en onder Vervang niet-vastgelegde schemawijzigingen gebruikt u vervolgens de selectievakjes om de relevante schemawijzigingen te selecteren.
In dit voorbeeld vervangt u niet-vastgelegde schemawijzigingen omdat u de naam van de tabel al hebt gewijzigd, maar deze nog niet hebt vastgelegd. De hernoeming wordt door SQL Compare geïnterpreteerd als een DROP en CREATE en het migratiescript vervangt deze wijzigingen in het implementatiescript (de andere optie zou zijn om met een leeg script te beginnen, wat u zou doen als u uw schema al had voorbereid voor de migratie en deze wijzigingen al had vastgelegd).
Door op Script genereren te klikken genereert SQL Source Control een migratiescript op basis van de niet vastgelegde wijzigingen en kunt u vervolgens de automatisch gegenereerde DROP en CREATE statements vervangen.
In dit geval zouden we de volgende SQL gebruiken:
EXEC sp_rename 'dbo.users', 'customers'GO CREATE SYNONYM dbo.users FOR customersGO
Het synoniem voor de klantentabel voorkomt problemen als de tabel met de oude naam wordt aangeduid.
Dan kunt u opslaan en sluiten en dit migratie script vervangt nu de gemaakte wijzigingen.
Terug in het Commit tabblad ziet u het migratie script met de bijbehorende schema wijzigingen eronder genesteld. U hoeft nu alleen nog maar het nieuwe migratiescript te selecteren, een commentaar in te voeren en de wijzigingen vast te leggen.
U bent nu klaar om de wijzigingen te implementeren. Als u SQL Compare gebruikt, wordt het migratiescript automatisch uitgevoerd tijdens de implementatie, waarbij de sp_rename opgeslagen procedure wordt gebruikt in plaats van de DROP en CREATE statements die oorspronkelijk door de SQL Compare engine zijn gegenereerd.