0

我有一个 DBML 文件，它定义了大量的实体供我们的 LINQ-to-SQL 查询使用。它在 SQL Server 2005 和 SQL Server 2008 以及我们正在与之集成的第三方软件的特定版本上运行良好。但是，我们现在正在调查在新操作系统 (Windows Server 2012) 和数据库平台 (SQL Server 2012) 上运行的第三方软件的更新版本，并作为 64 位进程。

当我尝试在这个新环境中从我们在数据库（不是第三方软件）中定义的表中检索一个对象时，我遇到了异常，“字符串必须恰好是一个字符长。” 现在我从其他问题和文章中了解到，过去 Visual Studio 将某些列创建为 Char 类型而不是列的 String 类型时出现了一些错误行为nvarchar(1)。但是有很多因素让我相信我在这里处理的是一个不同的问题：

  1. 根据 DBML 文件，我从中检索数据的表中没有 Char 列，甚至没有nvarchar(1)数据库列。
  2. 尽管第三方表的架构发生了变化，但我们的数据库架构和 DBML 文件在有效版本和引发此异常的版本之间没有发生变化。而且我只是从我们的一张表（Dim dtl = Aggregate i In context.FSE_ItemDetails Into First()）中查询数据。

我需要帮助的是确定导致此错误的表和列。我假设错误来自我试图从中检索数据的表，但是当我查看架构时，很难想象如何。AFormatException几乎没有关于错误来源的信息，当我发现它时，我无法获得太多关于发生了什么的信息。我可以在调用堆栈中看到（不幸的是，仅作为字符串提供），这System.Convert.ToChar是抛出它的函数，以及我们的ItemDetail.get_Item()生成的函数是堆栈中代码的最后一层。但是没有柱子的提示。如果可能的话，我想通过更改重现错误的测试程序来缩小范围，因为我没有在可以重现错误的相同环境上设置调试环境。但是一旦异常解除到我的级别，我不知道如何以编程方式访问调用堆栈中的数据。

编辑

我误认为我只访问一张表。我忘记了我的测试输出是指来自第三方模式的关联对象，该对象确实可能已更新。但是，问题仍然存在，是否有一种好的方法来识别导致错误的源列。该表中有很多很多列。

4

1 回答 1

0

在发现我正在查看错误的表后，我只是在 XML 编辑器中打开了 DBML 文件，找到了我现在怀疑是问题的表的定义，并查找了每个Column设置Type为System.Char. 我查询了新数据库中的每一列，最后找到了一个不包含 1 个字符的列。进一步检查它表明它曾经被定义为Char(1) NULL，但现在是nvarchar(2) NULL。我通过纠正它并再次运行测试而没有错误确认这是我看到的问题的根源。

于 2013-10-21T16:43:41.777 回答