SQL Server 生产版的行为与开发人员版不同。编码有问题！

Question

给定：

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

问题：

在开发服务器上，这工作正常，没有任何问题。但是，在尝试在生产服务器上批量插入时，我收到以下错误：

异常：System.InvalidOperationException： String 类型的给定值来自 数据源无法转换为 指定目标的类型 nvarchar 柱子。 ---> 系统.InvalidOperationException： 字符串或二进制数据将是 被截断。

我注意到一些奇怪的事情： 当 ftp-ing ANSI 版本的 Xml 文件（稍后由 Web 应用程序读取）时，它会向文件添加几个字节，然后在插入到我们的表中时大小会加倍。当 ftp-ing 一个 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 过程（也许？）。

Answer 1

由于这是应用程序的新实例，因此删除两个表并重新添加它们可以解决问题（这是使用 SQL Compare 完成的）。

这就是我解决问题的方法，但我相信 Marc Gravell 是有道理的。

Answer 2

重要的是列的排序规则。表、数据库的排序规则，甚至 SQL Server 本身的排序规则设置都简单地定义了下次创建新列时将使用的默认排序规则。

正如您可以想象的那样，最终将单个列设置为错误的排序规则值的情况并不罕见。

Pinal Dave 在他的博客上有几个有用的脚本，包括 这个可以让你查看列当前的排序规则设置：

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

也是一个非常全面的后续帖子一整套脚本（由 Brian Cidern 编写），可让您识别和解决排序规则冲突。

Answer 3

“截断”警告向我表明，在生产中，该列实际上不是 max - 而是类似于 nvarchar(4000) （之前的旧最大值）转到ntext）。

验证该列实际上是max。

附带说明一下，如果您仅存储数据，则首选 varbinary(max) - 它将避免加倍等。如果您检查 数据，xml 可能是首选。