今日のトリビアADOXの接続は2通り存在する

Microsoft AccessのVBAでADOXを使うとき
事前に参照設定していあるものとする

1.通常

現在開いているaccdbファイルに適用することが通常だと思われる。
また、通常は排他モードで開いている。

Dim CAT as new adox.Catalog
Set CAT.ActiveConnection = CurrentProject.Connection

2. ほかのaccdbに使う場合

ADODBと組み合わせる

Dim cn As new adodb.connextion
Dim CAT as new adox.Catalog
CN.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0;" & _
                      "Data Source=C:\Path\To\File.accdb;" & _
                      "Mode=Share Deny None;"
Set CAT.ActiveConnection = CN

なお、現在開いているaccdbファイルで２を使うとエラーになるか、勝手に共有モードに変わる場合があるので、使わないこと。この前Copilotがお勧めしてきたが、あとでなぜか共有モードになったり、終了しなくなったりしたことがあり、これが原因の可能性がある。

Gemini君によると３つくらい考えられるそうだ
１.二重のファイルロック: Accessアプリケーション（VBAを実行しているホスト）は既にデータベースファイルを開き、独自のロックをかけています。その状態で、コード内でProvider（ACE OLEDB） を使って同じファイルへの新しい接続を確立しようとすると、OSやDBエンジンのレベルでロックの競合が発生し、どちらかの接続が予期せぬ挙動をします。

2.接続モードの不一致: 外部接続（ケース2）でMode=Share Deny Noneを指定した場合、Accessが排他モードでファイルを開いていても、VBA内の新しい接続が共有モードを要求することで、ファイルレベルのロック状態に影響を与え、アプリケーション全体のモードが意図せず共有モードに移行してしまうことがあります。

3.接続リーク/未解放: ADODB接続を明示的に開いた場合、処理後に**.CloseメソッドとSet CN = Nothingによる接続の明示的な解放が必要です。これが漏れると、ファイルへのロックが解放されず、Accessアプリケーションの終了時までロックが残り**、フリーズや「終了しない」状態を引き起こす可能性があります。

確かにDAOとAdoxを併用していたため、１がありうる。あと３もそうだ。
なので、１の方法を使うほうが安全である。
またVBS、Powershellで操作する場合も、一度accdbを開き、１．の方法でADOXを使うほうが良い。