A volte ho uno script SQL che ha una o più stringhe super-lunghe (a volte anche stupide). In genere si tratta di VARBINARY
valori letterali / costanti che rappresentano file / assiemi, ma a volte sono testo.
Il problema principale con stringhe molto lunghe è che alcuni editor di testo non li gestiscono così bene. Ad esempio, ho un valore VARBINARY
letterale che uso in CREATE ASSEMBLY [AssemblyName] FROM 0x....
un'istruzione e l'Assemblea stessa ha dimensioni di poco più di 1 MB, il che equivale a poco più di 2 milioni di caratteri in un file di testo poiché ogni byte richiede che due caratteri siano rappresentati in notazione esadecimale (es. 0x1F
= a 1
e an F
). SQL Server Management Studio (SSMS) non lo gestisce bene e si blocca per alcuni secondi mentre provo a scorrere su quella linea. E in effetti, alcune versioni (non sono sicuro che ciò accada ancora) mostreranno anche un avvertimento sulle righe lunghe quando si apre uno script che ha almeno una riga su una certa lunghezza.
Un problema secondario è che complica la formattazione quando si utilizza in un editor senza il ritorno a capo abilitato o la pubblicazione online. Il problema qui è che il cursore per la barra di scorrimento orizzontale è molto stretto e spostandolo anche solo un po 'di solito scorre il testo non molto lungo fuori dalla vista.
Ora, T-SQL non termina i comandi con newline o anche punti e virgola (anche se i punti e virgola sono preferiti / consigliati, a partire da SQL Server 2005). Quindi, poiché SQL Server sa come analizzare ogni istruzione in modo tale che sappia quando finisce, sembra che dividere la linea lunga su più linee, separate solo da un newline/ carriage-return+ line-feed, non sembra irragionevole. Ma questo non funziona in entrambi i casi.
PRINT 'Line1
Line2';
ritorna (nella scheda "Messaggi"):
Line1
Line2
E questo ha abbastanza senso in quanto la newline è all'interno di una costante / letterale. Ma farlo anche per un VARBINARY
non funziona.
PRINT 0x1234
5678;
mi dà un errore.