私は、作業指示管理に Access ベースのデータベースを使用している中小企業で働いています。このシステムは何年も前から使用されており、ISV のカスタム ソフトウェアを使用してデータベースにアクセスしている PC が 6 ～ 7 台あります。データベースには、マップされたドライブ (Z:) 接続を介してアクセスします。
数か月前、次のエラーが断続的に発生し始めました。
データ ソース名が見つからず、既定のドライバーが指定されていません
その結果、ISV はデータベースに接続して修復を実行し、データベースを回復する必要があります。表示されるエラーはもう少し具体的で、ファイル形式が破損していることを示しています。サポート技術者は、この問題はネットワークを介したトランザクションの失敗によって発生したと示唆しています。そのために、私たちはいくつかのことを試しました。
- 元の「サーバー」PCに問題が発生した場合に備えて、データベースを別のホストに移動しました。
- ネットワークスイッチを交換しました
- 問題児を隔離するために、クライアントを一つずつネットワークから外し始めたが、一貫した結果は得られなかった。
今のところ運がない。
質問は、PC の 1 台がドライブ マッピングを閉じて、開いているデータベースを破損している可能性がありますか? Windows 7 で何か新しいことが邪魔になっている可能性がありますか? 原因を特定するためのより良い方法をお勧めいただけますか?
答え1
これはほぼ間違いなく32ビットと64ビットのDSNの問題です。64ビット環境で32ビットDSNを使用するには、C:\Windows\SysWoW64\odbcad32.exe
弊社の社内アプリケーションにも同様の制限があります。今後この問題を回避するには、最新のものをインストールすることをお勧めします。SQL Server ネイティブ クライアントグループ ポリシーを使用して、32 ビットと 64 ビットの両方の DSN をすべてのマシンに展開します。
答え2
「NET USE」ではなく SUBST.exe コマンドを使用してドライブをマップすると、「NET USE」とは異なり、マップされたドライブが失われたときに接続は常に再試行されます。この方法を実行すると、SUBST.exe コマンドを知らない人にとってドライブのマップ解除が困難になることに注意してください。ドライブがこのようにマップされると、Windows エクスプローダから切断することはできません...これは機能しません。
個人的には、これは 64 ビットの問題であることに同意します。
32 ビットおよび 64 ビットの ODBC DSN コントロール パネルは、特定の方法で動作すると予想されますが、場合によっては逆の動作をすることを覚えておいてください。たとえば、64 ビット システムで 64 ビットの「ユーザー DSN」を追加しようとすると、接続が失敗しますが、「システム DSN」を使用すると接続が機能することに気付く場合があります。これは、ODBC パネルが実際には 64 ビット ODBC コントロール パネルの「ユーザー」タブで「32 ビット DSN」を生成しているのに対し、「システム」タブでは期待される 64 ビット DSN を生成するためです。コントロール パネルが期待どおりに動作しない可能性があることを認識していれば、どの構成でも困ることはないと思います。