LINQ-to-SQL クエリで使用する多数のエンティティを定義する DBML ファイルがあります。SQL Server 2005 と SQL Server 2008、および統合している特定のバージョンのサード パーティ ソフトウェアで問題なく動作しています。ただし、現在、新しい OS (Windows Server 2012) およびデータベース プラットフォーム (SQL Server 2012) で、64 ビット プロセスとして実行されているサード パーティ製ソフトウェアの新しいバージョンを調査しています。
この新しい環境で、(サードパーティのソフトウェアではなく) データベースで定義したテーブルの 1 つからオブジェクトを取得しようとすると、「文字列は正確に 1 文字の長さでなければなりません」という例外が発生します。他の質問や記事から、Visual Studio が列の String ではなく Char 型として特定の列を作成するというバグのある動作が過去にあったことがわかりましたnvarchar(1)。しかし、ここで別の問題を扱っていると私が信じるに至った多くの要因があります。
nvarchar(1)DBML ファイルによると、データを取得しているテーブルには Char 列がなく、データベース列さえありません。- サード パーティのテーブルのスキーマは変更されていますが、データベース スキーマと DBML ファイルは、機能するバージョンとこの例外をスローするバージョンの間で変更されていません。また、テーブルの 1 つ ( ) のデータのみをクエリしています
Dim dtl = Aggregate i In context.FSE_ItemDetails Into First()。
助けが必要なのは、このエラーの原因となっているテーブルと列を特定することです。エラーは、データを取得しようとしているテーブルからのものであると想定していますが、スキーマを見ると、その方法を想像するのは困難です。AFormatExceptionはエラーの原因に関する情報をほとんど持っておらず、それを見つけたときには、何が起こっていたのかについてあまり情報を得ることができませんでした。コール スタック (残念ながら、文字列としてのみ提供されます) を見ると、それSystem.Convert.ToCharがそれをスローした関数であり、私たちのItemDetail.get_Item()生成された関数は、スタックにあったコードの最後のレベルです。しかし、コラムのヒントはありません。可能であれば、エラーを再現するテストプログラムを変更して、エラーを再現できる同じ環境にセットアップされたデバッグ環境を持っていないため、これを絞り込みたいと考えています。しかし、例外が自分のレベルまで巻き戻された後、プログラムでコール スタック内のデータにアクセスする方法がわかりません。
編集
私は 1 つのテーブルにしかアクセスしていなかったという事実を誤解していました。私のテスト出力が、実際に更新された可能性があるサード パーティ スキーマの関連オブジェクトを参照していたことを忘れていました。ただし、エラーの原因となっているソース列を特定する良い方法があるかどうかという疑問が残ります。テーブルには非常に多くの列があります。