初めて質問させて頂きます。現在、XP + VB6(SP5) + DAO3.6 + Access97という環境でプログラムを作っています。開発途中まで何の問題もなかったデータベースのオープンが、あるとき突然「パスワードが正しくありません」というエラーが発生するようになりました。同組合せのPGは過去に何品か実績があるのですが、このようなエラーは初めてです。当然パスワードは合っていますし、過去のPGも動作するため、OS環境の変化ではなさそうです。
ちなみに、この組合せは
・英語版OSインストーラをVB6ディストリビューション＋IPDKで作成するため、SP5である必要がある
・大量のデータを扱うため、容量の小さいAccess97
・処理速度優先なので、DAO
という理由からです。
どなたかこのような症状をご存知でしたら原因と対処法を教えていただけないでしょうか？

> どなたかこのような症状をご存知でしたら原因と対処法を教えていただけないでしょうか？

　　そのＭＤＢは、Access97で正常に開きますか？
　　要はＭＤＢが破損していないかどうか・・・です。

以上。

> 　　そのＭＤＢは、Access97で正常に開きますか？
> 　　要はＭＤＢが破損していないかどうか・・・です。

こちらで行ってみた検証を返答させて頂きます。
・単体では全く問題なく開けます。データ操作も行えます。（Access97にて）
・対象DBを過去プログラムで開いてみるとオープン可能です。
・過去DBは対象PGでは同症状でオープンできません。

というところから、VB(DAO)側の問題のようなのですが、DBをオープンするモジュールは過去も対象も共通です。では何が原因？？？って感じでお手上げです。

[プロジェクト][参照設定]  Microsoft DAO 3.6 Object Library

'------------------------------ パスワード
Public Const strDbOpenPwd = "MS Access;PWD=1234"

'------------------------------ Db変数
Public Dbs As Database

'------------------------------ データベースオープン
Function OpenDatabase(strFilePath) As Boolean
On Error GoTo Er
    If Dir(strFilePath) <> "" Then
        Set Dbs = OpenDatabase(strFilePath, False, False, strDbOpenPwd)
        OpenDatabaseSystem = True
    End If
    Exit Function
Er:
    OpenDatabaseSystem = False
End Function

> [プロジェクト][参照設定]  Microsoft DAO 3.6 Object Library

　　Access97 は、通常、DAO 3.5 だと思いますが・・・
　　旧プログラム（動作していたやつ）でも、DAO 3.6 を使って
　　いるのですか？

以上。

> 　　Access97 は、通常、DAO 3.5 だと思いますが・・・

そうなんです。私もそう思います。(してることと矛盾してますが・・)
通常はAccess2000を使うのですが、わざわざOS再インストールまでしてこの環境にしてます(;;)

> 　　旧プログラム（動作していたやつ）でも、DAO 3.6 を使って
> 　　いるのですか？

開発や動作も同PC 且つ 環境や設定は全く同じなのです。

あれからいろいろ検証してみた結果、ついさっきデータベースファイル名が 「System.mdb」だと症状が現れることが確認できました。
予約語だとまずいのですかね・・無知なのかバグなのか・・すっきりしないまま原因は解明できました。
何度もご返答ありがとうございました。基本的なことを見直すきっかけになりました。

> あれからいろいろ検証してみた結果、ついさっきデータベースファイル名が 「System.mdb」だと症状が現れることが確認できました。
> 予約語だとまずいのですかね・・無知なのかバグなのか・・すっきりしないまま原因は解明できました。

　　http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1225970817

　　予約語のようです・・・

以上。参考まで

> 　　予約語のようです・・・

なるほど。。。 何から何までありがとうございました。

> > あれからいろいろ検証してみた結果、ついさっきデータベースファイル名が 「System.mdb」だと症状が現れることが確認できました。
> > 予約語だとまずいのですかね・・無知なのかバグなのか・・すっきりしないまま原因は解明できました。
> 　　http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1225970817
> 　　予約語のようです・・・

予約語といって良いのかどうかは分かりませんが、system.mdb や system.mdw は、
ワークグループ情報ファイルの既定のファイル名となっています。

その設定さえ変更すれば、System.mdb というファイル名を通常利用する事も可能です。

# JET では、ファイル名の制限が比較的緩やかになっています。VB6 とは異なり、
# Unicode ファイル名もサポートしていますし、"C:\Folder\Sample:TEST.MDB"
# といった、代替ストリームさえも利用可能となっています。


さてその設定ですが、DAO の場合には、DBEngine.SystemDB プロパティ、
ADO の場合には、OLE DB の "Jet OLEDB:System database" 動的プロパティで
指定する事ができます。

これらの指定が無い場合には、レジストリの
　DAO 3.5x  … HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\3.5\Engines
　DAO 3.6   … HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines
　DAO 12.0  … HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\12.0\Access Connectivity Engine\Engines
にある SystemDB という文字列値が初期値として使用されます。
(そしてこの SystemDB という項目の初期値が、"system.mdb" となっています)

ちなみに、上記レジストリの Jet 設定は、OS 全体に影響を与えるものですが、
DBEngine.IniPath (ADO では "Jet OLEDB:Registry Path")を併用することで、
アプリ別の設定エントリを用意することも出来るようになっています。

なお、Microsoft Access からの操作の場合：たとえば Access 97 ならば、
　HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\8.0\Access\Jet\3.5\Engines
の方の SystemDB が利用される事になっています。
(こちらの既定値は、"system.mdb" ではなく "system.mdw" です)

> 予約語といって良いのかどうかは分かりませんが、system.mdb や system.mdw は、
> ワークグループ情報ファイルの既定のファイル名となっています。

ありがとうございます。大変よく分かりました。
国内・海外で数十台動作するので管理が大変な上、レジストリ変更は抵抗があるので実施はせずにノウハウとして覚えておきます。
Win7の時期に .Net(2008) + SQL にアップしようとしておりますが、同様の制限があるか試してみる必要がありますね・・・あ、その前にこの組合せの処理速度(VB6→.NET自体が遅くなりそうですが・・)が先か・・・何せ速度＋容量が最優先なPGなもので・・・
ご返答下さった方々本当にありがとうございました。

MSDN の契約があれば、すでに Windows 7 製品版を下記からダウンロードできますね。
http://msdn.microsoft.com/ja-jp/subscriptions/dd179326.aspx

> Win7の時期に .Net(2008) + SQL に
クライアント側のスタンドアロン データベースですか?
それともサーバーデータベースですか? (Windows 7 は、クライアント OS ですよね)

> アップしようとしておりますが、
その時期次第では、
　VB2010 (.NET 4.0)
　SQL Server 2008 R2
　Windows Server 2008 R2
　Windows 7
という組み合わせになるかもしれませんね。


> 同様の制限があるか試してみる必要がありますね・・・
ちなみに 2008 R2 以降の Windows Server / SQL Server では、
32bit 版が提供されず、64 bit 版のみとなります。
今のうちに、64bit 化への移行も進めておく必要があるかと。

たとえば、印刷系・入力系のコンポーネントなどにおいて、
サードパーティ製品を使うことを検討しているなら、
それらに 64bit 版があるのか(あるいは提供予定があるか)も
調べなければならないと思います。API の確認も必要かも知れません。

# パフォーマンスを落としても良いなら、
# WOW64 で 32bit エミュレーションするという手もありますが…。

> クライアント側のスタンドアロン データベースですか?

スタンドアロンプログラムです(今のところは)。将来システムのネットワーク化でサーバー構築する必要があるかもしれませんが・・今は考えないでおきます。
そのときはDB指定も考えられるし、別予算も出るでしょうからそのとき考えます。

> その時期次第では、
> 　VB2010 (.NET 4.0)
> 　SQL Server 2008 R2
> 　Windows Server 2008 R2
> 　Windows 7
> という組み合わせになるかもしれませんね。

ですね。Serverは使わなくてよさそうなのでともかくとしても.NETも4.0ですか・・ついていけない・・ ^^;

> ちなみに 2008 R2 以降の Windows Server / SQL Server では、
> 32bit 版が提供されず、64 bit 版のみとなります。
> 今のうちに、64bit 化への移行も進めておく必要があるかと。

そうなんですか！？ それは全く知りませんでした。これはまだまだ猛勉強が必要ですね。
零細で人手が足らず勉強時間が取れないのでヘロヘロになりそうです ;_;

> サードパーティ製品を使うことを検討しているなら、

印刷系やら細かなモノはゴリゴリ自作してます。あとはスプレッドシートくらいかな？？

なにからなにまで情報頂き本当にありがとうございました。