Question

鉴于：

使用nvarchar(max)数据类型加载到表中的非常大的XML文件。这导致数据大小加倍（可能是由于SQL Server编码为unicode），然后我们从表中读取文件，解析它并对数据库中的其他表进行批量插入。

问题：

在开发服务器上，这很好用，没有问题。但是，在尝试批量插入生产服务器时，我收到以下错误：

异常：System.InvalidOperationException： String类型的给定值数据源无法转换为输入指定目标的nvarchar 柱。 ---＆GT; System.InvalidOperationException：字符串或二进制数据截断。

我注意到了几件奇怪的事情：当ftp一个ANSI版本的Xml文件（稍后由Web应用程序读取）时，它会向文件中添加几个字节，然后在插入到我们的表中时会出现DOUBLES大小。 ftp一个unicode版本时，字节保持不变但它也是DOUBLES然后惨败

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进程（可能是？），将文件复制一遍然后再回复（文件大小会闪回几个字节，但是我们会在复制它时将这些字节恢复）。

Answer 1

“截断”警告告诉我，在生产中，该列实际上不是max - 而是nvarchar(4000)之类的东西（在您必须前往{{1}之前的旧最大值}}）。

确认该列实际上是ntext。

作为旁注，如果您只是存储数据，max将是首选 - 它将避免加倍等等。如果您检查数据，varbinary(max)可能是首选。

Answer 2

由于这是应用程序的新实例，删除这两个表并重新添加它们修复了问题（这是使用SQL Compare完成的。）

这就是我解决了这个问题的方法，但我相信Marc Gravell正在做些什么。

Answer 3

列的整理是重要的。 表，数据库的排序规则，甚至 SQL Server本身的排序规则设置只是定义了下次创建新列时将使用的默认排序规则。< / p>

您可以想象，最终将单列设置为错误的归类值并不罕见。

Pinal Dave在他的博客上有几个有用的脚本，包括this one which allows you to see the current collation settings of columns：

/* 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'

还是一个非常全面的follow-up post，其中包含一整套脚本（由Brian Cidern编写），可用于识别和解决排序规则冲突。

SQL Server Production的行为与开发人员版本不同。编码是可疑的！

3 个答案: