Потеря строк в sql-сервере

Я ввожу информацию об ошибках в таблицу ErrorLog в моей базе данных. Для этого у меня есть класс утилиты:

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

Это прекрасно работает. Однако, когда я пытаюсь получить доступ к этой таблице, разрыв строки больше не кажется присутствующим.

Если я SELECT таблица:

SELECT * from ErrorLog ORDER BY ErrorDate

в журнале нет разрывов строк. Это отчасти ожидается, так как разрывы строк в однострочных строках нарушат форматирование. Однако, если я копирую данные, символы разрыва строки теряются, а данные все в одной строке.

Как получить разрывы строк в данных в конце моего запроса, когда я помещаю разрывы строк? Я не знаю, была ли строка лишена разрывов строк при входе в таблицу или если средство просмотра в SQL Server Management Studio удалило разрывы строк.

Тип данных столбца, в который помещаются сообщения об ошибках, составляет nvarchar(Max), если это имеет значение.

EDIT: Неожиданно решение Pendri не работает.

Вот фрагмент строки непосредственно перед тем, как она переходит на SQL-сервер:

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

И вот такая же строка, когда я извлекаю ее из средства просмотра сетки в SQL Server Management Studio:

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

Место разрыва строки должно быть двойным.

Любые идеи?

Ответы

Ответ 1

SSMS заменяет разрывы строк пробелами в выходном файле сетки. Если вы используете Print для печати значений (перейдите на вкладку сообщений), тогда возврат каретки будет отображаться там, если они были сохранены с данными.

Пример:

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

Первый будет отображаться в одной ячейке в сетке без разрывов, второй будет печатать с разбиением на панель сообщений.

Быстрый и простой способ печати значений - это выбрать в переменную:

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

Ответ 2

Не нужно заменять ввод строки\вывод, вам нужно просто выбрать правильный вариант:

Tools -> Options...

> Query Results 
  > SQL Server 
    > Results to Grid 

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

И не забудьте перезапустить свою студию управления!

Чарльз Ганьон ответил

Ответ 3

Обновите пару лет спустя.

Как описано здесь, одним из способов сохранить просмотр строк в SSMS является преобразование вывода в XML:

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

К счастью, если у вас есть SSMS 2012, это уже не проблема, так как разрывы строк сохраняются.

Ответ 4

попробуйте использовать char(13) + char(10) вместо '\n' в вашей строке (определите константу и соединитесь с вашим sql)

Ответ 5

I echo Давид C ответ, за исключением того, что вы должны использовать ключевое слово TYPE, чтобы вы могли щелкнуть, чтобы открыть данные в новом окне.

Обратите внимание, что любые небезопасные символы XML не будут работать с любым из наших решений.

Вот доказательство концепции:

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;

Я могу подтвердить, что разрывы строк сохраняются при копировании из сетки в SSMS 2012.

Ответ 6

В SQL Server 2008 не предусмотрено значение "Сохранить CR\LF при копировании или сохранении" в значение "истина".

В этой проблеме я заменил char (13) на "\ r" и заменил char (10) на "\n", как показано ниже.

REPLACE(REPlACE([COLUMN_NAME],char(13), '\r'),CHAR(10),'\n')

И в коде снова я заменил "\ r\n" тегом break.

Я работал таким образом, поскольку в SQL 2008 не было ни одной опции, как упоминалось выше. Этот ответ может быть альтернативой, хотя.

Спасибо