SQL Server Production ведет себя не так, как версия разработчика. Кодировка подозрительна! - PullRequest
Новая
       1

SQL Server Production ведет себя не так, как версия разработчика. Кодировка подозрительна!

4 голосов
/ 23 марта 2011

Дано:

Очень большой файл XML, который загружается в таблицу с использованием типа данных nvarchar(max). Это приводит к удвоению размера данных (возможно, из-за кодировки SQL Server в Unicode), а затем мы читаем файл из таблицы, анализируем его и выполняем массовую вставку в другие таблицы в базе данных.

Проблема:

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

Исключение: System.InvalidOperationException: Заданное значение типа String из источник данных не может быть преобразован в введите nvarchar указанной цели колонка. ---> System.InvalidOperationException: Строковые или двоичные данные будут усеченный.

Пара странных вещей, которые я заметил: При загрузке ANSI-версии XML-файла (который будет прочитан позднее веб-приложением) он добавляет несколько байтов в файл, а затем удваивает размер при вставке в нашу таблицу. При загрузке версии Unicode байты остаются прежними, но они также удваиваются, а затем с треском проваливаются 

b e c a u s e  t h e  d a t a  s t a r t s  t o  l o o k  l i k e  t h i s.

Мы исключили неверные данные, свернув XML до одной записи под корнем. Разработка занималась этим, производство - нет.

Что-то ДОЛЖНО отличаться от конфигурации в наших серверах разработки и производственных серверах, но мы не можем этого понять. Кстати, сопоставление тоже самое.

Любая помощь будет принята с благодарностью!

РЕДАКТИРОВАТЬ: Обновление: Мы попытались прочитать файл в объект XmlDocument непосредственно с сервера и минуя процесс сохранения его в БД. Без изменений в поведении.

Второе обновление: Мы исключили процесс FTP (возможно?), Скопировав файл, а затем НАЗАД (размер файла уменьшается на несколько байтов, но мы возвращаем эти байты при его повторном копировании) .

Ответы [ 3 ]

3 голосов
/ 23 марта 2011

«Усеченное» предупреждение подсказывает мне, что в производстве столбец на самом деле не max, а скорее что-то вроде nvarchar(4000) (старый максимум, прежде чем вам нужно было перейти к ntext).

Убедитесь, что столбец действительно max.

В качестве примечания: если вы только храните данных, предпочтительнее будет varbinary(max) - это позволит избежатьудвоение и т. д. И если вы проверяете данные, xml может быть предпочтительнее.

1 голос
/ 23 марта 2011

Поскольку это был новый экземпляр приложения, удаление двух таблиц и их повторное добавление устранило проблему (это было сделано с помощью SQL Compare).

Вот как Я решил проблему, но я думаю, что Марк Гравелл что-то задумал.

0 голосов
/ 23 марта 2011

Сличение столбца имеет значение. Параметры сортировки таблицы, базы данных и даже настройки параметров сортировки самого SQL Server просто определяют, какое сопоставление по умолчанию будет использоваться при следующем создании нового столбца.

Как вы можете себе представить, нередко бывает, что в отдельных столбцах установлено неверное значение сортировки.

Пинал Дэйв имеет несколько полезных скриптов в своем блоге, включая , который позволяет вам видеть текущие настройки сортировки столбцов : 

/* Find Collation of SQL Server Database */
SELECT DATABASEPROPERTYEX('AdventureWorks', 'Collation')
GO
/* Find Collation of SQL Server Database Table Column */
USE AdventureWorks
GO
SELECT name, collation_name
FROM sys.columns
WHERE OBJECT_ID IN (SELECT OBJECT_ID
    FROM sys.objects
    WHERE type = 'U'
    AND name = 'Address')
    AND name = 'City'

Также очень подробное последующее сообщение с полным набором сценариев (написанных Брайаном Сидерном), позволяющих выявлять и разрешать конфликты сопоставления.

...