ACCESSデータベースアクセス後、ldbが（なかなか）消えない

Question

ACCESSデータベースは使用中にロックファイル（*.ldb）を作成しますが、
データベースを閉じた（つもり）なのにこのロックファイルがなかなか消えません。

C:_Tmp\test.accdb というデータベースを用意し、
ボタンを一つ配置したような簡単な画面を作成してみました。

プロバイダは "Microsoft.Ace.OLEDB.12.0"、
データベース種類は accdb です。

デバッガでコード中(*C)の行にブレークポイントを置きます。
ボタンを押すとデータベースに接続（db.Connect()）を実行し、
すぐに切断（db.Disconnect()）を実行します。

エクスプローラを開いて C:_Tmp\test.accdb を見つつ動作させてみると、

1. コード中の(*A)の行を実行すると test.ldb が作成される。
   これは、(*A)にブレークポイントを置いてステップ実行し、
   この行が実行された際に test.ldb が作成されたことを予め確認しています。
2. ソース中(*C)のブレークポイントで止まる。
   しばらくそのまま放置する。
3. ブレークポイントで止まったまま約80秒経過したあたりで、
   エクスプローラから test.ldb が消える。

つまり、(*B)を実行した後、しばらくして非同期で消えるようなのです。
なぜこんなにも時間がかかるのか、
あるいは、プログラムに誤りなどありましたらお教えください。

ちなみに、以前はこのようなことがなく動いていたように思います。
以前と違う点は、
・Windows7 から 10 に端末を変更した。
・VisualStudio 2017 から 2019 に変更となった。
・Windows7 の端末では Office 2013 が入っていたが、
これには Office365 の 32bit が入っている。

前の Windows7 端末は没収の上初期化されてしまったので、
環境が分からなくなってしまったのですが、
何か必要なものがインストールされていないなどあるでしょうか。
（Accessランタイムなどはこの端末には入れていません。）

どうぞよろしくお願いいたします。

using System;
using System.Windows.Forms;
using System.Data.OleDb; // OleDbConnection...

namespace Test
{
    public partial class Form1 : Form
    {
        public class DB
        {
            public OleDbConnection ConnectionObj {get; private set;}

            public DB() {
                ConnectionObj = null;
            }

            public void Connect()
            {
                if (ConnectionObj == null) {
                    ConnectionObj = new OleDbConnection();
                }

                string provider = "Microsoft.Ace.OLEDB.12.0";
                string source = @"C:\_Tmp\test.accdb";
                string connectionString = $"Provider={provider};Data Source={source}";
                ConnectionObj.ConnectionString = connectionString;
                ConnectionObj.Open(); // <-------- (*A)ここでldbが作成される
            }

            public void Disconnect()
            {
                if (ConnectionObj != null) {
                    ConnectionObj.Close(); // <-------- (*B)ここでldbが破棄されるはず？
                    ConnectionObj.Dispose(); // <-------- (*C)ここでブレークポイント
                    ConnectionObj = null;
                }
            }
        }

        public Form1()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, EventArgs e)
        {
            DB db = new DB();
            db.Connect();
            db.Disconnect();
            db = null;
        }
    }
}

Comments

[Zuishin]

エクスプローラーは特にコンピューターがビジー状態の時、時間差があることがあります。コマンドプロンプトを開き、dir で消えたかどうかを確認してください。

また、Dropbox などを使っていると、消したはずのファイルが一時的に復活することがあります。普通のディレクトリであることを確認してください。

[Sitapper]

ご覧くださいましてありがとうございます。

コマンドプロンプトでも見てみましたが、やはり同じように時間がかかっていました。

ひとつ気づいたのですが、
ldb ファイルにはアクセス対象の情報が書かれるはずが、サイズが 0 で作成されます。
そのまま放置しているとしばらく経ってからサイズ 0 のまま消えます。
（コマンドプロンプトから確認しています。）

ところが、サイズ 0 で作成された ldb ファイルをエクスプローラでアクセスすると
（コマンドプロンプトから copy したり、エクスプローラでプロパティを開いたりすると）、
サイズが 64 Byteになります。

この状態で開けて見ると、アクセス情報（端末名と権限？）が書かれています。

そういうものだったかも知れませんが...。

また何かございましたらよろしくお願いします。

[Sitapper]

すみません。
対象のディレクトリは DropBox や共有フォルダでなく、普通のものになります。

Answer 1

接続 (OleDbConnection) の Close (Dispose も同じ) は Open で接続プールから取得した接続を接続プールに返すだけで、ldb を削除する訳ではなさそうです。

正常動作なので気にしないという話になると思うのですが。

それより気になるのは、例外が発生すると Close されない (接続プールに接続が戻されずリソースリークになる) ところ。using 句を使うことをお勧めします。

【追記】

下の 2020/02/07 10:36 の私のコメントで書いたことの証拠（？）画像を貼っておきます。

.accdb とのことなので .ldb ではなくて .laccdb になるはずですが、.ldb も .laccdb も見当たりませんでした。生成されているが即削除されるのかもしれませんが。

ちなみに、その .accdb をダブルクリックして Access で開くと .laccdb ファイルが生成され、Access を閉じると即削除されます。

Comments

[Sitapper]

回答をいただきましてありがとうございます。
先の YAmaGNZ さんにも指摘がありましたが、接続プールというものを知りませんでした。
大変参考になりました。

ただ、現状で２つ問題があります。

一つ目は、添付のフォームプログラムのサンプルにつきまして、
ボタンをクリックすると ldb ができ、
そのあとしばらくすると ldb が消えるのですが、
ldb が消える前にフォームを閉じる（プログラムを終了する）と ldb が残ったままになるのです。

二つ目は、添付のコードにはないのですが、
実際の業務で使用しているマスタメンテのプログラムでは、
登録ボタンを押してデータベースにデータを書き込み（つまり、ここで ldb が作成される）、
その後ウィンドウを閉じる際に

　　DAO.DBEngine eng = new DAO.DBEngineClass();
　　eng.CompactDatabase(source, target);

のような形でデータベースの最適化を実施しているのですが、
その時点で ldb が残っていると、source が他で排他的に使用中の例外になるのです。

現状では、登録ボタンを押してからウィンドウを閉じるまでの間、
ldb が消えるまで約 80 秒程度待たなければ最適化が失敗してしまうようになりました。

以前の環境ではそのようなことはなかったのですが...。

using の件はご教授ありがとうございます。
そのように対応しようと思います。

ありがとうございます。

[Sitapper]

すみません。
一つ目は間違いでした。
フォームを閉じると ldb は消えました。
このときは約 80 秒もかかっていません。
フォームを閉じてほぼ間もなく消えます。

二つ目、としている問題が今回質問させていただいたきっかけになります。

[退会済みユーザー]

> ボタンをクリックすると ldb ができ、そのあとしばらくすると ldb が消えるのですが、ldb が消える前にフォームを閉じる（プログラムを終了する）と ldb が残ったままになるのです。

自分の PC にある試験用の既存の Windows Forms アプリで試してみましたが、そういうことはなかったです。

アプリを起動すると、Form1_Load で .accdb に接続してデータを DataTabe に取得して即 Close するものです。

.accdb とのことなので .ldb ではなくて .laccdb になるはずですが、.ldb も .laccdb も見当たりませんでした。生成されているが即削除されるのかもしれませんが。

ちなみに、その .accdb をダブルクリックして Access で開くと .laccdb ファイルが生成され、Access を閉じると削除されます。

自分の PC にある試験用の既存の Windows Forms アプリなので質問者さんのコード・環境とは異なるのですが、何か変ですね。

[退会済みユーザー]

質問には、

> データベース種類は accdb です。

と書いてありましたが、それが間違いなければ、

> フォームを閉じると ldb は消えました。

アプリを起動しての .accdb への接続で .ldb ができることはあり得なくて、できるとすると .laccdb になるはずなのですか？

何か根本的に変ですよ。

[Sitapper]

SurferOnWww さま

わざわざ検証いただきありがとうございます。
PCのリカバリとアプリケーションの入れ直しをしていて、
返信に時間がかかってしまいました。
申し訳ありません。

今回の現象、原因はAccessRuntimeにあるように思われます。
以前のWin7機ではAccessRuntime2013が入っていましたが、
今回Win10機への更新を機にOffice365を導入したのですが、
それが何か悪さをしたようです。

PCリカバリー後、Office365を入れた後でAccessRuntime2013を入れると、
今回の現象は生じなくなりました。

accdbなのにldbができる件につきましては、
対象のデータベースがAccessから新規作成したのではなく、
プログラムで作成したもので、
その作成の仕方がおかしいのかもしれません。
（accdbの皮をかぶったmdb、とでもいうような状態？）
この部分ももう少し調べてみようと思います。

現在、社内事情にて、少しの間端末が手元を離れていますが、
戻りましたら継続する予定です。

いろいろとありがとうございます。

[退会済みユーザー]

> 対象のデータベースがAccessから新規作成したのではなく、プログラムで作成したもので、その作成の仕方がおかしいのかもしれません。

質問者さん独自に特別なことをしているのは第三者には分かりません。そういう独自実装・特殊事情は全て排除して、第三者が誰でも試せる条件にして検証した上で質問いただければと思います。

[Sitapper]

データベースをプログラムから作成していた件は、
今回こういう現象があったので調べているうちに判明したものでした。
ただ、別のシステムですが、まっとう（?）にAccessから作成されたAccess2003までのmdbでも、
Runtimeが2013までは正常動作していたものが2019にすると動かなくなったといった報告もあり、
AccessDBのバージョンか何かによってAccessRuntime2019（Office365）と相性がありそうな気もしています。
自前で作成したのが悪い可能性があるならAccessから作成したらどうかとか、
そのへんをもう少しきちんと試して結果が出るまでこの質問を閉じないでいようと思っていたのですが、
残念ながら別の問題の調査を指示されてこちらはしばらく先になりそうで、
ここで一旦閉じさせていただくことにしました。
この度はお時間をとって試してくださったりと、本当にありがとうございました。

[Sitapper]

少し時間が取れたので、再度試験をしてみました。
整理しますと、

1. DELL Lattitude 5400 / RAM 8 GB に Windows10 Pro 64bit をクリーンインストール
2. Office365 32bit版 をダウンロード導入
Business Premium サブスクリプションがあります。
64bit機に32bit版を導入した理由は、
64bitだと別システムで弊害があるとかで指示によります。
3. Accessを起動し新規で test.accdb を作成
4. 添付のソースでテスト
5. その結果...
オープンで test.laccdb が現れるが、
クローズでそれが消えるまでやはり 80 秒ほどかかり、
その間 test.laccdb が排他的にロックされて他から編集できない。

という状態が再現されました。
前の質問では ldb が出来ていて、これは accdb の作成の仕方がまずかったかと推察しますが、
今回は Access から作成したので laccdb になりました。

接続プールというものを今回教えていただきましたので、
オープン／クローズの瞬間に laccdb が作成／削除されるわけではないことは理解しましたが、
それにしても時間がかかりすぎに思える次第です。

YAmaGNZ さんに教えていただいたように接続文字列に
OLE DB Services=-2
を指定して接続プーリングを無効にするとこの現象は解消されました。
だったらそれでいいのかというと、知識の浅さからちょっと判断しかねているといったところです。

また再度質問を上げさせていただくかも知れません。

今回はどうもありがとうございました。

[退会済みユーザー]

> だったらそれでいいのかというと、

接続プールを無効にするわけですから、それではよくないと思います。自分が検証した時はそのような設定はしてませんけど、接続してデータ取得し Close でその直後にチェックしても .laccdb は見当たりませんでした。まだなんか変ですね。

ちなみに、自分のサンプルの接続文字列は以下の通りです。

Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\Users\surfe\Documents\Visual Studio 2015\CsProject\WindowsFormsAccess\WindowsFormsAccess\Northwind2007.accdb

[退会済みユーザー]

あと、関係ないとは思うのですが、質問者さんのコードと自分のサンプルコードで違うところを書きますと、自分のコードでは Visual Studio のデータソース構成ウィザードで作った TableAbapter を利用しており、Open / Close は OreDbDataApapter の Fill メソッドが自動的に行っているところです。

それで結果に差があるはずはないとは思いますが、念のためご連絡しておきます。

[Sitapper]

引き続いてアドバイスくださいまして、ありがとうございました。
しばらくこちらを見ておらず、お礼が遅くなりましてすみません。

接続文字列は同じように思います。
Visual Studio のデータソース構成ウィザードは使ったことがなく、
ソースにべた書きしていました。
本当は使った方が良いのでしょうが。

どうもこの現象、Windows10+AccessRunTime2016の状況で発生するように思えています。
私の端末だけでなく、別の同じような環境の端末でも同様の現象が発生しています。

正直いまはお手上げの状態です。
また、じっくり取り組まないといけなさそうです。

何度もお付き合いくださいまして、ありがとうございました。

[退会済みユーザー]

> Visual Studio のデータソース構成ウィザードは使ったことがなく、ソースにべた書きしていました。本当は使った方が良いのでしょうが。

何か特別な事情があるのでなければ絶対使った方が良いと思います。Visual Studio のデータソース構成ウィザードを利用して型付 DataSet + TableAdapter を作って、それを利用してアプリを作ると、以下の記事の図のような構造のアプリが、ほとんど自分でコードを書くこと無しに作れます。

Windows フォーム アプリケーションでのデータへの接続
https://docs.microsoft.com/ja-jp/previous-versions/wxt2cwcc(v=vs.120)

実際、自分の回答の画像の DataGridView のアプリは自分では一行もコードは書いてません。操作に慣れると 10 分もかからず作れます。自力で一からコードを書く場合のような種々の問題に悩むことはなくなり、開発工数は激減するはずです。保守工数も減るはずです。お試しください。

[Sitapper]

ありがとうございます。
今後ぜひ試してみます。
現在メンテしているシステムでは、
DBアクセスを置き換えることが時間的に難しいのですが、
次に大きく作り変える機会には移行しようと思います。
ありがとうございました。

Answer 2

接続プールにプールされ実際にCloseしきれていないというのは考えられないでしょうか？
OLE DB、ODBC、および Oracle 接続プール

Comments

[Sitapper]

回答をいただきましてありがとうございます。
接続プールというものを知りませんでした。
大変参考になりました。
ありがとうございます。

[YAmaGNZ]

接続文字列に"OLE DB Services=-2"を追加するとどうなりますか？

[Sitapper]

YAmaGNZさま

アドバイスをありがとうございます。
SurferOnWwwさまへの返答で書いたのですが、
AccessRuntimeの導入順序によって、
とりあえず現象が発生しなくなりました。
まだ調べたい点もありますが、
当面これで様子を見てみようとおもいます。

ありがとうございました。

[Sitapper]

本件、少し先になりますが、引き続いて調査検証する予定です。
YAmaGNZさまの接続文字列も試してみるつもりです。
どうもありがとうございました。

[Sitapper]

思いがけず時間が取れましたので、教えてくださった接続文字列を試してみました。
接続プーリングを無効にする設定だそうですね。
結果、今回の現象は解消されました。
オープン／クローズのタイミングで排他ファイルが作成／削除されるようです。

ただ、前は確か Windows7 に Office2013 が入っていたと思うのですが、
その際にはそのような指定がなくても今回のようにはならなかったので、
少々モヤモヤはしています。

またもう少し情報を集めて再度質問させていただくかもしれませんが、
もう少し検証して問題無さそうであれば反映させてようと思います。

どうもありがとうございました。