🥇Az adatátvitel a biztonsági másolat új verziója az MS SQL Server korábbi verziójára

Háttér

Egyszer azzal a céllal, hogy reprodukáljam a hibát, szükségem volt egy production adatbázis mentésére.

Meglepetésemre a következő korlátozásokba ütköztem:

Az adatbázis mentése a következő verzión készült: SQL Server 2016 és nem volt kompatibilis a következő verzióval: SQL Server 2014.
A munkahelyi számítógépemen az operációs rendszer: Windows 7, ezért nem tudtam frissíteni SQL Server 2016-os verzióra
A támogatott termék egy nagyobb rendszer része volt, amely szorosan kapcsolódó legaci architektúrával rendelkezett, és más termékekhez és adatbázisokhoz is kapcsolódott, ezért a másik állomásra való telepítése sok időt vehetett igénybe.

Figyelembe véve a fenti tényezőket, arra a következtetésre jutottam, hogy itt az ideje a nem standard megoldásoknak.

Adatok helyreállítása a mentésből

Elhatároztam, hogy virtuális gépet használok Oracle VM VirtualBox Windows 10-tel (lehet tesztképet venni az Edge böngészőhöz innen). A virtuális gépre SQL Server 2016 került telepítésre, és a mentésből vissza lett állítva az alkalmazás adatbázisa (utasítás).

Hozzáférés beállítása az SQL Serverhez a virtuális gépen

Ezután néhány lépést kellett tenni a külső hozzáférés lehetővé tételéhez az SQL Serverhez:

A tűzfalhoz szabályt hozzáadni, hogy engedje át a lekérdezéseket a porton 1433.
Azt javaslom, hogy a hozzáférés az SQL belépéssel és jelszóval történjen, ne pedig Windows hitelesítéssel (egyszerűbb beállítani a hozzáférést). Azonban ebben az esetben ne felejtsük el engedélyezni az SQL hitelesítést az SQL Server tulajdonságai között.
Az SQL Server felhasználói beállításaiban, a User Mapping fülön meg kell adni a visszaállított adatbázishoz a felhasználói szerepkört: db_securityadmin.

Adatok átvitele

Az adatok átvitele valójában két lépésből áll:

Az adatarchitektúra átvitele (táblák, nézetek, tárolt eljárások stb.)
Az adatok tényleges átvitele

Az adatarchitektúra átvitele

A következő műveleteket hajtjuk végre:

Kiválasztás Tasks -> Generate Scripts a másolandó adatbázishoz.
Válassza ki a másolni kívánt objektumokat vagy hagyja az alapértelmezett értéket (ebben az esetben az összes adatbázis objektumra vonatkozó szkript készül).
Állítsa be a szkript mentésének beállításait. A legpraktikusabb, ha a szkript egyetlen fájlba van mentve Unicode kódolásban. Így hiba esetén nem kell újra végighaladni az összes lépésen.

A szkript mentése után azt végre lehet hajtani az eredeti SQL Serveren (régebbi verzió), hogy létrejöjjön a kívánt adatbázis.

Figyelem: A script must be executed to verify the alignment of the backup database settings with the database created by the script. In my case, the script lacked a setting for COLLATE, resulting in data transfer failures and complicated procedures to recreate the database using an enhanced script.

Adatok átvitele

Before transferring data, all constraints on the database must be disabled:

EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'

Data transfer is carried out using the data import wizard. Tasks -> Import Data on the SQL Server where the database created by the script is located:

Specify the connection settings to the source (SQL Server 2016 on a virtual machine). I used Data Source SQL Server Native Client and the aforementioned SQL authentication.
Specify the connection settings to the destination (SQL Server 2014 on the host machine).
Then we configure the mapping. All must be selected not read-only objects (e.g., views do not need to be selected). For additional options, select "Allow inserts into identity columns", if such are used.
Figyelem: if, when attempting to select multiple tables and set their property "Allow inserts into identity columns" the property was previously set for at least one of the selected tables, the dialog will indicate that the property is already set for all selected tables. This fact can be misleading and lead to transfer errors.
We start the transfer.

Restoring constraint checks:

EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'

If any errors occur, check the settings, delete the created database with errors, recreate it from the script, make corrections, and repeat the data transfer.

Zárás

This task is quite rare and arises only due to the aforementioned constraints. Most often, solutions involve upgrading SQL Server or connecting to a remote server, if the application's architecture allows it. However, no one is safe from legacy code and poorly done development. I hope you won't need this guide, but if you do, I hope it saves you a lot of time and nerves. Thank you for your attention!