Eksport skryptów

Eksport skryptów to proces zapisu poleceń Transact-SQL definiujących obiekty bazy danych do zewnętrznego pliku.

Na czym polega eksport skryptów w SQL Server

Eksport skryptów w środowisku Microsoft SQL Server polega na zapisaniu w postaci tekstu poleceń języka Transact-SQL definicji obiektów znajdujących się w bazie danych. Takie polecenia mogą opisywać między innymi tabele, kolumny, klucze podstawowe, klucze obce, indeksy, widoki, procedury składowane, funkcje, wyzwalacze oraz schematy. Wynikiem jest zwykle plik z rozszerzeniem .sql, który można otworzyć w edytorze tekstu albo wykonać w SQL Server Management Studio.

Skrypt opisuje strukturę obiektów, a nie jest tym samym co kopia zapasowa bazy danych. Wygenerowane polecenia mogą utworzyć pustą strukturę tabel i innych elementów, lecz nie muszą zawierać rekordów zapisanych w tabelach. Eksport definicji jest więc przydatny wtedy, gdy potrzebne jest odtworzenie schematu, przeniesienie wybranych obiektów albo przeanalizowanie zmian bez kopiowania całej bazy.

Generowanie pliku za pomocą SQL Server Management Studio

W SQL Server Management Studio eksport można wykonać za pomocą funkcji Script Database as albo kreatora Generate Scripts. Po wskazaniu bazy danych wybiera się wszystkie obiekty lub tylko określone elementy, na przykład pojedyncze tabele, widoki i procedury. Następnie ustala się miejsce docelowe: schowek, nowe okno zapytania albo plik zapisany na dysku. Kreator tworzy instrukcje Transact-SQL zgodne z wybranymi ustawieniami.

W opcjach generowania można określić między innymi, czy skrypt ma zawierać instrukcje tworzenia bazy, tabel, indeksów, kluczy obcych i innych zależności. Dostępne są także ustawienia dotyczące skryptowania danych, uprawnień, wyzwalaczy, indeksów oraz instrukcji IF NOT EXISTS w zakresie obsługiwanym przez daną funkcję i wersję narzędzia. Ważne jest wskazanie właściwej wersji docelowego SQL Server, ponieważ nowsze elementy składni lub właściwości obiektów mogą nie być dostępne w starszej wersji silnika.

Zależności między obiektami i kolejność poleceń

Obiekty bazy danych nie są niezależne. Widok może odwoływać się do tabeli, procedura składowana może korzystać z widoku, a klucz obcy wymaga istnienia tabeli nadrzędnej i podrzędnej. Z tego powodu eksport powinien uwzględniać zależności oraz właściwą kolejność wykonywania instrukcji. Najpierw zwykle tworzone są schematy i tabele, następnie kolumny oraz ograniczenia, a później indeksy, widoki, procedury, funkcje i wyzwalacze. Konkretna kolejność zależy od zestawu wybranych obiektów.

Sam fakt wygenerowania pliku nie gwarantuje, że zostanie on wykonany bez zmian w innym środowisku. Skrypt może odwoływać się do nazw bazy, schematów, użytkowników, obiektów zależnych albo ustawień, których nie ma w bazie docelowej. Problemy mogą wystąpić również wtedy, gdy obiekt o tej samej nazwie już istnieje, uprawnienia wykonującego są niewystarczające lub wybrano tylko fragment struktury. Dlatego plik warto przejrzeć, sprawdzić kolejność instrukcji i uruchomić najpierw na środowisku testowym.

Kontrola poprawności wyeksportowanego skryptu

Przed użyciem eksportu należy określić, czy celem jest sama definicja obiektów, czy także dane. W przypadku struktury sprawdza się obecność tabel, kolumn, typów danych, ograniczeń, indeksów i kodu modułów programowalnych. W przypadku danych trzeba dodatkowo zweryfikować sposób ich zapisania, kolejność wstawiania rekordów oraz wpływ kluczy obcych. Skrypt zawierający instrukcje INSERT może być znacznie większy od pliku zawierającego wyłącznie definicje.

Wygenerowany plik Transact-SQL powinien być traktowany jako materiał do kontroli i powtarzalnego odtworzenia określonej struktury, a nie jako automatyczny zamiennik kopii zapasowej. Po wykonaniu skryptu warto porównać obiekty w bazie docelowej z bazą źródłową oraz sprawdzić działanie procedur, widoków i ograniczeń. Przy problemach z eksportem diagnostyka obejmuje między innymi analizę komunikatu błędu, brakujących zależności, uprawnień oraz zgodności wersji SQL Server. Neutralna analiza pliku i środowiska wykonawczego pozwala ustalić, czy przyczyną jest niepełny wybór obiektów, błędna kolejność poleceń, czy różnica między konfiguracją źródłową a docelową.