db.Close（）は1つの接続を閉じます。.ldbは、すべての接続が閉じられると自動的に削除されます。
Jetデータベース（つまりAccess）は複数の同時ユーザーをサポートしますが、非常に大規模な同時ユーザーベースにはあまり適していません。一つには、ネットワークの問題があると、それらは簡単に破損します。私は実際に今それを扱っています。それに関しては、データベースサーバーを使用することをお勧めします。
そうは言っても、私はJetデータベースをそのように何度も使用してきました。
「同期の問題」と言うときの意味がわかりません。
それ以外の点では良い答えへの追加の注意として、クライアントアプリケーションの存続期間中はダミーテーブルへの接続を開いたままにしておくことを強くお勧めします。
接続を頻繁に閉じて、毎回ロックファイルを作成/削除できるようにすることは、パフォーマンスの大きなボトルネックであり、データベースへの高速アクセスの場合には、実際にクエリと挿入が失敗する可能性があります。
私が少し前に与えたこの答えでもう少し読むことができます。
パフォーマンスと信頼性に関しては、いくつかの点に留意すれば、Accessデータベースからかなり多くのことを引き出すことができます。
クライアントの存続期間中、接続をダミーテーブルに対して開いたままにします（または、常に開いたままにしたくない場合は、少なくとも20秒の非アクティブ状態の後に接続を閉じるタイムアウトを使用します）。
クライアントアプリを設計して、発生したすべての接続（クラッシュ、ユーザーのシャットダウンなど）に関係なく、すべての接続（ダミーの接続を含む）を適切に閉じます。
ロックをそのままにしておくのは良くありません。クライアントがデータベースを不明な状態のままにしておく可能性があり、他のクライアントが古いロックを残し続けると破損する可能性が高くなる可能性があります。
データベースを定期的に圧縮して修復します。それを毎晩の仕事にしてください。
これにより、データベースが最適化され、古いデータが削除され、開いているロックが適切に閉じられます。
良好で安定したネットワーク接続は、ファイルベースのデータベースのデータ整合性にとって最も重要です。疫病のようなWiFiは避けてください。
データベースサーバー自体からすべてのクライアントを追い出す方法があります。
たとえば、MaintenanceLockクライアントが定期的にポーリングするフィールドなどのテーブルがあります。フィールドが設定されている場合、ユーザーが作業を保存する機会を与えた後、クライアントは切断する必要があります。
同様に、クライアントアプリが起動したら、データベースのこのフィールドをチェックして、クライアントがアプリに接続することを許可または禁止します。
これで、各ユーザーのところに行ってアプリを閉じるように依頼することなく、いつでもクライアントを迅速に処理できます。また、Compact＆Repairメンテナンスを実行するときに、夜間に開いたままになっているクライアントがデータベースに接続されていないことを確認することも非常に役立ちます。
Close()1つの接続のみを閉じ、他の接続は影響を受けません。実際、MSAccessはマルチ接続の使用シナリオに最適なソリューションではありません。MSSQLServerのライトバージョンであるSQLServerCompactをご覧ください。インプロセスで実行され、複数の接続とマルチスレッド、ほとんどの堅牢なT-SQL機能（ストアドプロシージャを除く）などをサポートします。