GO er ikke en T-SQL-kommando. Er en batch-afgrænser. Klientværktøjet (SSM, sqlcmd, osql osv.) bruger det til effektivt at klippe filen ved hver GO og send de enkelte batches til serveren. Så du kan naturligvis ikke bruge GO inde i IF, og du kan heller ikke forvente, at variabler spænder over rækkevidde på tværs af batcher.
Du kan heller ikke fange undtagelser uden at tjekke efter XACT_STATE()
for at sikre, at transaktionen ikke er dødsdømt.
Brug af GUID'er til ID'er er altid i det mindste mistænkeligt.
Brug af NOT NULL-begrænsninger og leverer en standard 'guide' som '{00000000-0000-0000-0000-000000000000}' kan heller ikke være korrekt.
Opdateret:
- Opdel ALTER og UPDATE i to batches.
- Brug sqlcmd-udvidelser til at bryde scriptet ved fejl. Dette understøttes af SSMS, når sqlcmd-tilstand er slået til , sqlcmd, og det er trivielt at understøtte det også i klientbiblioteker:dbutilsqlcmd .
- brug
XACT_ABORTfor at tvinge fejl til at afbryde batchen. Dette bruges ofte i vedligeholdelsesscripts (skemaændringer). Lagrede procedurer og applikationslogiske scripts bruger generelt TRY-CATCH-blokke i stedet, men med passende omhu:Undtagelseshåndtering og indlejrede transaktioner .
eksempel script:
:on error exit
set xact_abort on;
go
begin transaction;
go
if columnproperty(object_id('Code'), 'ColorId', 'AllowsNull') is null
begin
alter table Code add ColorId uniqueidentifier null;
end
go
update Code
set ColorId = '...'
where ...
go
commit;
go
Kun et vellykket script vil nå COMMIT . Enhver fejl vil afbryde scriptet og rulle tilbage.
Jeg brugte COLUMNPROPERTY
for at kontrollere, om kolonnen eksisterer, kan du bruge en hvilken som helst metode, du kan lide i stedet (f.eks. opslag sys.columns
).