interruzioni di riga persi in sql server

Question

sto entrando informazioni di errore in una tabella ErrorLog nel mio database. Ho una classe di utilità per fare questo:

ErrorHandler.Error("Something has broken!!\n\nDescription"); 

Questo funziona bene. Tuttavia, quando provo ad accedere a questa tabella, le interruzioni di riga non sembrano più essere presenti.

Se SELECT tabella:

SELECT * from ErrorLog ORDER BY ErrorDate 

non ci sono interruzioni di riga presenti nel registro. Questo è come previsto, poiché le interruzioni di riga nelle righe di una riga interromperanno la formattazione. Tuttavia, se copio i dati, i caratteri di interruzione di riga sono stati persi e i dati sono tutti su una riga.

Come posso ottenere interruzioni di riga nei dati alla fine della mia domanda quando ho messo le interruzioni di linea in? Non so se la stringa è stata rimossa dalle interruzioni di riga quando entra nella tabella o se il visualizzatore in SQL Server Management Studio ha rimosso le interruzioni di riga.

Il tipo di dati della colonna in cui i messaggi di errore sono messi è nvarchar(Max), se questo fa la differenza.

EDIT: Inaspettatamente, la soluzione di Pendri non ha funzionato.

Ecco un estratto della stringa poco prima che passi al server SQL:

POST /ipn/paymentResponse.ashx?installation=272&msgType=result HTTP/1.0\n\rContent-Length: 833\n\rContent-Type: 

E qui è la stessa stringa quando estraggo dal spettatore griglia in SQL Server Management Studio:

POST /ipn/paymentResponse.ashx?installation=272&msgType=result HTTP/1.0 Content-Length: 833 Content-Type: 

il luogo in cui l'interruzione di riga deve essere stato doppio distanziati.

Qualche idea?

Answer 1

SSMS sostituisce linebreaks con spazi nell'output griglia. Se si utilizza Stampa per stampare i valori (verrà visualizzata la scheda dei messaggi), i ritorni a capo verranno visualizzati lì se sono stati memorizzati con i dati.

Esempio:

SELECT 'ABC' + CHAR(13) + CHAR(10) + 'DEF' 
PRINT 'ABC' + CHAR(13) + CHAR(10) + 'DEF' 

la prima schermata sarà in una singola cella della griglia, senza interruzioni, la seconda stamperà con una pausa nel riquadro messaggi.

Un modo rapido e semplice per stampare i valori sarebbe quella di selezionare in una variabile:

DECLARE @x varchar(100); 
SELECT @x = 'ABC' + CHAR(13) + CHAR(10) + 'DEF'; 
PRINT @x; 

Answer 2

prova utilizzando char(13) + char(10) invece di '\ n' nella stringa (definiscono una costante e concatenare allo SQL)

Answer 3

aggiornare un paio di anni più tardi.

Come descritto here, una soluzione per preservare linebreaks visualizzazione in SQL Server Management Studio è quello di convertire l'output XML:

SELECT * FROM (
    SELECT * from ErrorLog ORDER BY ErrorDate 
) AS [T(x)] FOR XML PATH 

Fortunatamente, se si dispone di SQL Server Management Studio 2012, questo non è più un problema, come interruzioni di riga sono mantenuto.

Answer 4

I echo David C's answer, eccetto che è necessario utilizzare la parola chiave "TYPE" in modo che sia possibile fare clic per aprire i dati in una nuova finestra.

Si noti che tutti i caratteri XML non sicuri non funzioneranno correttamente con nessuna delle nostre soluzioni.

Ecco una prova di concetto:

DECLARE @ErrorLog TABLE (ErrorText varchar(500), ErrorDate datetime); 
INSERT INTO @ErrorLog (ErrorText, ErrorDate) VALUES 
    ('This is a long string with a' + CHAR(13) + CHAR(10) + 'line break.', getdate()-1), 
    ('Another long string with' + CHAR(13) + CHAR(10) + '<another!> line break.', getdate()-2); 
SELECT 
    (
     SELECT ErrorText AS '*' 
     FOR XML PATH(''), TYPE 
    ) AS 'ErrorText', 
    ErrorDate 
FROM  @ErrorLog 
ORDER BY ErrorDate; 

Posso confermare che le interruzioni di riga sono conservati durante la copia di una griglia in SSMS 2012.

Answer 5

Nessuna necessità di sostituire stringa di input \ output, è sufficiente selezionare l'opzione corretta:

Tools -> Options... 

> Query Results 
    > SQL Server 
    > Results to Grid 

set "Retain CR\LF on copy or save" to true. 

E non dimenticare di riavviare il tuo studio di gestione!

secondo Charles Gagnon answer