如何在 LINQ to SQL 中识别来自 SQL Server 2012 的 FormatException 的来源

Question

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

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

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

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

编辑

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

Answer 1

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