Czy SQL Server / T-SQL obsługuje kontynuację linii w celu zerwania długich ciągów?


13

Czasami mam skrypt SQL, który ma jeden lub więcej bardzo długich (czasem nawet głupich) ciągów. Zazwyczaj są to VARBINARYliterały / stałe, które reprezentują pliki / zespoły, ale czasami są one tekstem.

Podstawowym problemem związanym z naprawdę długimi łańcuchami jest to, że niektóre edytory tekstu nie radzą sobie z nimi zbyt dobrze. Na przykład mam VARBINARYliterał, którego używam w CREATE ASSEMBLY [AssemblyName] FROM 0x....instrukcji, a sam zestaw ma nieco ponad 1 MB, co odpowiada nieco ponad 2 milionom znaków w pliku tekstowym, ponieważ każdy bajt wymaga reprezentacji dwóch znaków w notacji szesnastkowej (np. 0x1F= 1ai an F). SQL Server Management Studio (SSMS) nie radzi sobie z tym dobrze i zawiesza się przez kilka sekund, gdy próbuję przewijać tę linię. W rzeczywistości niektóre wersje (nie jestem pewien, czy tak się nadal dzieje) będą nawet wyświetlać ostrzeżenie o długich liniach podczas otwierania skryptu, który ma co najmniej jedną linię na określonej długości.

Drugi problem polega na tym, że komplikuje formatowanie podczas korzystania z edytora bez włączonego zawijania słów lub publikowania w Internecie. Problem polega na tym, że suwak poziomego paska przewijania jest bardzo wąski, a nawet jego nieznaczne przesunięcie zwykle powoduje przewinięcie niezbyt długiego tekstu.

Teraz T-SQL nie kończy poleceń z nowymi liniami, a nawet średnikami (chociaż średniki są preferowane / zalecane, począwszy od SQL Server 2005). Więc od SQL Server umie analizować każde stwierdzenie takie, że nie wie, kiedy to się skończy, to wydaje się długa linia podziału na wielu liniach, oddzielone tylko przez newline/ carriage-return+ line-feed, nie wydaje się nierozsądne. Ale to nie działa w obu przypadkach.

PRINT 'Line1
Line2';

zwraca (w zakładce „Wiadomości”):

Line1
Line2

Ma to sens, ponieważ nowa linia zawiera się w literale / stałej. Ale robienie tego VARBINARYrównież nie działa.

PRINT 0x1234
5678;

daje mi błąd.

Odpowiedzi:


13

Na szczęście istnieje wsparcie dla kontynuacji linii w T-SQL za pomocą \znaku (odwrotny ukośnik). Po prostu umieść to na końcu linii, tuż przed newline/ carriage-return+ line-feed, a nowa linia zostanie zignorowana.

W przypadku ciągów tekstowych działa to następująco:

PRINT 'Line1\
Line2';

zwraca (w zakładce „Wiadomości”):

Line1Line2

W przypadku ciągów binarnych / szesnastkowych zachowuje się to następująco:

PRINT 0x1234\
5678;

zwraca (w zakładce „Wiadomości”):

0x12345678;

Aby sformatować pliki binarne (zespoły, certyfikaty) w tekstowe ciągi szesnastkowe do użytku w skryptach SQL, napisałem narzędzie wiersza polecenia o nazwie BinaryFormatter, które wydałem jako open source na GitHub. Nie tylko konwertuje plik binarny na reprezentację tekstową, ale także korzysta z kontynuacji wiersza, aby rozłożyć długie VARBINARYliterały na tyle wierszy, ile potrzeba, w oparciu o określoną liczbę znaków dla każdego wiersza. Rezultatem jest coś w stylu:

4D5A09DE34F178313345A4\
00007F4E39782EFC48D842\
00000000

które następnie kopiuję i wklejam do skryptu, jak pokazano w {...}poniższym obszarze:

CREATE ASSEMBLY [AssemblyName]
FROM 0x\
{output from BinaryFormatter}
;

Aby uzyskać dodatkowe informacje na ten temat, zobacz mój wpis na blogu: Kontynuacja linii w języku T-SQL

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.