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

Question

I have a DBML file that defines a large number of entities for use by our LINQ-to-SQL queries. It has been working fine on SQL Server 2005 and SQL Server 2008 and a particular version of third party software with which we are integrating. However, we are now investigating the newer version of the third party software running on a new OS (Windows Server 2012) and database platform (SQL Server 2012), and as a 64-bit process.

When I try to retrieve an object from one of the tables we have defined in the database (not the third party software) in this new environment, I am getting the exception, "String must be exactly one character long." Now I know from other questions and articles that there has been some buggy behavior in the past with Visual Studio creating certain columns as type Char instead of String for an nvarchar(1) column. But there are a number of factors leading me to believe I'm dealing with a different problem here:

1. The table from which I am retrieving data, according to the DBML file, has no Char columns in it and doesn't even have a nvarchar(1) database column.
2. Although the schema of the third party tables have changed, our database schema and DBML file have not changed between the version that works and the one that throws this exception. And I'm only querying data from one of our tables ( Dim dtl = Aggregate i In context.FSE_ItemDetails Into First() ).

What I need help with is determining the table and column that's causing this error. I'm assuming that the error was from the table I'm trying to retrieve data from, but as I look at the schema it's hard to imagine how. A FormatException has very little information about the source of the error, and by the time I catch it, I don't have access to much about what was going on. I can see in the call stack (provided only as a string, unfortunately), that System.Convert.ToChar is the function that threw it, and our ItemDetail.get_Item() generated function is the last level of our code that was in the stack. But there's no hint of a column. I would like, if possible, to narrow this down by changing my test program that reproduces the error because I don't have a debugging environment set up on the same environment where I can reproduce the error. But I don't know how to access the data in the call stack programmatically once the exception has unwound up to my level.

EDIT

I was mistaken about the fact that I was only accessing the one table. I forgot that my test output was referring to an associated object from the third party schema, which indeed may have been updated. The question remains, however, is there a good way to identify the source column causing the error. The table has many, many columns in it.

Answer 1

After discovering that I was looking at the wrong table I just opened up the DBML file in an XML editor, located the definition of the table I now suspected was the problem, and looked for each Column element whose Type was set to System.Char . I queried each column in the new database and finally found one that did not contain exactly 1 character. Inspecting it further showed that it used to be defined as Char(1) NULL , but is now nvarchar(2) NULL . I have confirmed this was the source of the problem I was seeing by correcting it and running the test again without error.