SQL Server / T-SQLは長い文字列を分割するために行継続をサポートしていますか？

私は、1つ以上の非常に長い（時には愚かな長い）文字列を含むSQLスクリプトを使用していることがあります。通常、これらはVARBINARYファイル/アセンブリを表すリテラル/定数ですが、テキストの場合もあります。

本当に長い文字列の主な問題は、一部のテキストエディターでは文字列をうまく処理できないことです。たとえばVARBINARY、CREATE ASSEMBLY [AssemblyName] FROM 0x....ステートメントで使用するリテラルがあり、アセンブリ自体のサイズは1 MBをわずかに超えています。これは、各バイトが16進表記で表されるために2文字を必要とするため、テキストファイルでは200万文字を少し上回ります。 （例0x1F= a 1およびan F）。SQL Server Management Studio（SSMS）はこれをうまく処理せず、その行をスクロールしようとすると数秒間ハングします。実際、一部のバージョン（これがまだ発生するかどうかは不明）では、特定の長さの行が少なくとも1行あるスクリプトを開くと、長い行に関する警告が表示されることもあります。

2番目の問題は、ワードラップを有効にせずにエディターで使用したり、オンラインで投稿したりすると、フォーマットが複雑になることです。ここでの問題は、水平スクロールバーのスライダーが非常に狭く、通常は少しでもそれを移動すると、非超長いテキストがスクロールして見えなくなるということです。

現在、T-SQLはコマンドを改行またはセミコロンで終了しません（SQL Server 2005以降、セミコロンが推奨/推奨されています）。したがって、SQL Serverは各ステートメントを解析する方法を知っているので、いつ終了するかがわかるので、newline/ carriage-return+ だけで区切られた長い行を複数の行に分割するline-feedように見えるのは、不合理に見えません。しかし、これはどちらの場合でも機能しません。

PRINT 'Line1
Line2';

戻り値（[メッセージ]タブ）：

Line1
Line2

そして、改行はリテラル/定数内にあるので、それは十分に理にかなっています。しかし、これを行うことVARBINARYもできません。

PRINT 0x1234
5678;

エラーが出ます。

ありがたいことに、\（バックスラッシュ）文字によるT-SQLの行継続のサポートがあります。それをnewline/ carriage-return+の直前の行末に置くだけline-feedで、改行は無視されます。

テキスト文字列の場合、これは次のように動作します。

PRINT 'Line1\
Line2';

戻り値（[メッセージ]タブ）：

Line1Line2

バイナリ/ 16進数文字列の場合、これは次のように動作します。

PRINT 0x1234\
5678;

戻り値（[メッセージ]タブ）：

0x12345678;

SQLスクリプトで使用できるようにバイナリファイル（アセンブリ、証明書）をテキストの16バイト文字列にフォーマットするために、GitHubでオープンソースとしてリリースしたBinaryFormatterと呼ばれるコマンドラインユーティリティを作成しました。バイナリファイルをテキスト表現に変換するだけでなく、行継続VARBINARYを使用して、各行に使用する指定された文字数に基づいて、必要な数の行に長いリテラルを分散します。結果は次のようになります。

4D5A09DE34F178313345A4\
00007F4E39782EFC48D842\
00000000

{...}次の領域に示すように、それをコピーしてスクリプトに貼り付けます。

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

このトピックの詳細については、私のブログ投稿「T-SQLでの行継続」を参照してください。