Nesen nācās vienā mazā projektiņā nodrošināt conditional SQL deployment procesu atkarībā no kaut kādiem projekta uzstādījumiem.
Protams, ka sākot ar 2008 studijas versiju, izmantojam VS for DB Professionals jeb DB Dude jeb vienkārši SQL 200X projektus, kas ir pieejami vizuālajā studijā, lai izstrādātājiem un DBA atvieglotu darbu ar datu bāzēm.
Pieredze rāda, ka agrāk vai vēlāk ir nepieciešams kaut kādā veidā parametrizēt visu datubāzes uzstādīšanas procesu atkarībā no kaut kādiem ārējiem faktoriem. Viens no klasiskākajiem ārējiem faktoriem ir: “izstrādātājiem šī atslēga satur vērtību X, bet ražošanas vai testēšanas vidē šai atslēgai jābūt ar vērtību Y”.
Šim nolūkam ērti noder SQL mainīgie – SQLCMD variables. Ērts veids, kā parametrizēt SQL skriptu, kas tiek izpildīts dienas beigās, kad vizuālā studija to beidzot ir sabūvējusi.
Pārrokot sen rakstītos bloga ierakstus (nemaz nebiju piefiksējis, ka rakstu jau no 2007 gada - http://dotnet.lv/blogs/vi/archive/2007/07.aspx) uzgāju rakstu, kurā datubāzes projektu mainīgie tiek aplūkoti 2008 Visual Studio versijai.
Ideja paliek gandrīz tieši tāda pati, tikai nelielas izmaiņas saistībā ar 2010 versiju:
- vienkārši nav iespējams definēt dažādas mainīgo vērtības dažādām projekta konfigurācijām, kā tas bija iepriekšējā versijā.
- pašlaik visi mainīgie tiek apkopoti vienā failā – Properties/Database.sqlcmdvars
- lai organizētu vairākas versijas mainīgajiem atkarībā no projekta uzstādījumiem, nākas veidot jaunu failu (piemēram, Properties/Database-Release.sqlcmdvars) un šo failu norādīt, kā mainīgo failu konkrētajā konfigurācijā.
- jāatceras, ka šie faili visu laiku jātur būs sinhroni pie jebkurām datubāzes mainīgo skaita izmaiņām (vai nu pieliekot klāt vai dzēšot kādu mainīgo).
Kad pēc neskaitāmām iterācijām beidzot ir uzražots datubāzes skripts, kas pēc skripta autora domām ir the one :), kas jālaiž būs uz ražošanas datu bāzes, ir iespējami 2 veidi, kā šo uzģenerēto skriptu izpildīt:
- No Visual Studio
- No SQL Server Management Studio
Pirmais variants parasti vairāk drošības pēc atkrīt automātiski, jo kurš gan klients dos izstrādātāju kantorim pieeju pie viņu ražošanas SQL servera, lai izpildītu automātiskos atjauninājuma skriptus (negribas pat iedomāties, ko iesākt situācijās, kad tas nabaga developeris, testējot savu nākamo skriptu, aizmirsis pārslēgties atpakaļ uz lokālo izstrādes serveri…).
Atliek vien otrais variants – piegādāt klienta IT departamentam uzģenerēto skriptu (visticamāk nedaudz patīrītu) un pastāstīt, kā viņi var izpildīt Tavu mistisko skriptu no SSMS vides un izvairīties no kļūdām, kas līdzīgas zemāk.
Msg 102, Level 15, State 1, Line 1
Incorrect syntax near ':'.
Msg 1038, Level 15, State 4, Line 3
An object or column name is missing or empty. For SELECT INTO statements, verify each column has a name. For other statements, look for empty alias names. Aliases defined as "" or [] are not allowed. Change the alias to a valid name.
Lai vēlāk Visual Studio uzģenerēto failu būtu iespējams izpildīt no SSMS, ir jāieslēdz SQLCMD režīms pirms skripta izpildes, jo Visual Studio izmanto šo utilītas programmu, lai izpildītu skriptus no studijas pa tiešo pret datubāzi.
Režīmu iespējams ieslēgt: Query –> SQLCMD Mode
SQLCMD režīmā redzami nelieli pelēki skripta fragmenti (iekrāsoti nedaudz tumšāk), kas tiek identificēti kā SQLCMD sintakse.
Pārslēdzoties uz SQLCMD režīmu – skripta izpilde no SSMS DBA lomas pildītājam nesagādā vairāk nekādas galvassāpes (izņemot, protams, developeru sarūpētos pārsteigumus).
Cerams, ka noderēs!