.NET アプリケーションに x ファイルの問題があります。というか、Win32 と .NET のハイブリッド アプリケーションです。
オラクルと通信しようとすると、死ぬだけです。消えます。空の大きな黒い虚空に行きます。イベント ログ メッセージも例外も何もありません。
代わりに MS SQL Server と対話するようにアプリケーションに要求するだけで、OracleConnection と関連クラスの使用を SqlConnection と関連クラスに置き換える効果があり、期待どおりに動作します。
今日、私たちは突破口を開きました。
何らかの理由で、ある顧客は、すべてのアプリケーション ファイルをデスクトップ上のディレクトリに配置することで、Oracle でも期待どおりに動作することに気付きました。ディレクトリをドライブのルート、または C:\Temp に移動すると、クラッシュが再発しました。
基本的に、デスクトップ上のディレクトリから実行するとアプリケーションが動作し、ルートのディレクトリから実行するとアプリケーションが失敗するという 100% の再現性がありました。
今日、重要な違いは、ディレクトリ名にスペースがあるかどうかであることがわかりました。
したがって、これらのディレクトリは機能します。
C:\Program Files\AppDir\Executable.exe
C:\Temp Lemp\AppDir\Executable.exe
C:\Documents and Settings\someuser\Desktop\AppDir\Executable.exe
一方、これらはそうではありません：
C:\CompanyName\AppDir\Executable.exe
C:\Programfiler\AppDir\Executable.exe <-- Program Files in norwegian
C:\Temp\AppDir\Executable.exe
これを読んでいる誰かが同様の動作を見て、「ああ、オラクルの華やかなドライバー構成でフロブをいじる必要がある」などのことを望んでいます。
誰？
フォローアップ#1: OK、今 procmon の出力を処理しました。カスケード エラーをトリガーするウィンドウを開こうとするボタンを押したときの両方のファイルです。両方のファイルの上部近くにあり、ずっと下まで追跡します。
ただし、1 つの実行が失敗すると、もう 1 つの実行が続行され、ログ出力の次の数行は次のようになります。
ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll SUCCESS Offset: 274 432, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll SUCCESS Offset: 233 472, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
この後、作業実行は引き続き実行され、スレッドが終了してアプリが終了する前に、他の実行が mscorwks.dll ファイルに数回アクセスします。したがって、失敗した実行は上記のファイルに影響しません。
フォローアップ #2: Oracle クライアント ドライバーをアップグレードしようと考えましたが、明らかに 10.2.0.1 が Windows 2003 サーバーおよび XP クライアントで利用可能な最高のバージョンです。
フォローアップ #3:ええと、ブラックボックス ソリューションになってしまいました。基本的に、問題はXPOと Oracle に関連していることがわかりました。XPO には、XPObjectType と呼ばれるシステム テーブルがあり、Oid、TypeName、AssemblyName の 3 つの列があります。私たちが話しているデータベースでOracleがどのように構成されているかにより、列名はOID、TYPENAME、およびASSEMBLYNAMEでした。通常、これは問題にはなりませんが、XPO がスキーマ情報と直接対話し、適切な列名を持つテーブルが存在するかどうかを確認し、XPO は大文字と小文字の違いを処理しないため、不明な列が 3 つある XPObjectType テーブルを認識し、列はありません。それが期待するもののうち。
XPO が現在何をしているのか正確にはわかりませんが、このテーブルを削除して、すべての列名を二重引用符で囲んで正しい大文字と小文字を区別して再作成した場合、問題は発生しません。
フォルダ名のスペースがこれに入る正確な場所はまだわかりませんが、この問題には2つの層がありました。
- 短期的な解決策として、アプリケーションがクラッシュするのを防ぎます。
- バグの修正、長期的な解決策
現在、ティア 1 は解決されており、ティア 2 はキューに戻され、優先順位が付けられます。いずれにせよ、データ層への大きな変更に直面しているため、少なくともオラクルのすべての顧客がテーブル修正によって実際に問題が解決されることを確認した場合、これは解決する必要がある問題ではない可能性があります.
プロセス モニター (ファイル モニターの兄貴分) は実際には問題を特定できませんでしたが、それを使用して、XPO が構築されたユーザー コードのブレークポイントの後にそれを判断することができたので、Dave Markleによる回答を受け入れます。このテーブルのクエリを実行すると、アプリケーションの終了に関するすべてのエントリがログに記録されるまで I/O は発生しませんでした。そのため、このテーブルが原因であるか、少なくとも何らかの形で問題に影響を与えていると思いました。
この本当の原因にたどり着いたら、投稿を更新します。