「Access '矛盾がある状態'」問題 再現について

Question

お世話になっております。

Access でデータベースが '矛盾がある状態' にあると報告される

https://support.office.com/ja-jp/article/access-%E3%81%A7%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%8C-%E7%9F%9B%E7%9B%BE%E3%81%8C%E3%81%82%E3%82%8B%E7%8A%B6%E6%85%8B-%E3%81%AB%E3%81%82%E3%82%8B%E3%81%A8%E5%A0%B1%E5%91%8A%E3%81%95%E3%82%8C%E3%82%8B-7ec975da-f7a9-4414-a306-d3a7c422dc1d

こちら、回避策や発生条件など、別フォーラムでも頻繁に議論されていますが、

確実に（または高い確率で）発生する具体的な"再現方法"について、ご存知の方はいらっしゃいますでしょうか？

「このエラーは、ネットワーク ファイル共有にデータベースが格納されていて、

　複数のユーザーが同時にデータベースを使用している場合に発生する可能性があります。」

とマイクロソフトさんから発表されていますが、詳しい再現方法については言及されていません。

具体的に「こういったテーブル・データ構造を持ち、こういったクエリ・フォームで、

このようなデータ操作した場合」「その際のOS・ネットワーク環境はこういう場合」・・・

など、"再現方法"を特定されている方がおりましたら、ご教示頂けると幸いです。

Answer 1

Makapuさん

返信遅くなり申し訳ありません。

参考情報のご提供、ありがとうございます。

リンク先のスレッドでも頻繁にやり取りされているようですね。

「イベント発生を遅延させる」点がポイントなのかなと思いますが、

やはり、いずれの方も確定した所まではたどり着いてないような印象ですね・・・。

検討してみます。

ところで、2019/7/1時点でMSからこの件に関して情報更新されていました。

https://support.office.com/ja-jp/article/access-%E3%81%A7%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9%E3%81%8C-%E7%9F%9B%E7%9B%BE%E3%81%8C%E3%81%82%E3%82%8B%E7%8A%B6%E6%85%8B-%E3%81%AB%E3%81%82%E3%82%8B%E3%81%A8%E5%A0%B1%E5%91%8A%E3%81%95%E3%82%8C%E3%82%8B-7ec975da-f7a9-4414-a306-d3a7c422dc1d

• 7 月 1 日の更新:この問題の修正プログラムをテストしていますが、現在記述した問題が発見されました。 これらの問題を解決できるように取り組んでおり、さらにテストを行います。
• この問題は複雑であり、追加の問題が発生しないようにする必要があるため、この問題のリリース プロセスは通常の修正プログラムよりも時間がかかります。 今後の更新については、引き続きこのページで確認してください。

根本的な解決にはまだ時間がかかりそうな見込みですね。

Answer 2

ssshidiufiduieurieさん、こんにちは。

参考情報になります。

・Access Database is getting corrupt again and again

16スレッド目以降で TQuasarさんが回避策を適用しなくても回避出来た方法について言及しています。

※詳細はスレッドをご確認下さい。

＜ TQuasarさん発言 一部抜粋＞

We were able to identify a combination of delete and append queries to the same table, back-to-back that would cause this issue.  After we rearranged the queries and/or entered some delay between such, we have not had the issue re-surface for weeks. 

（この問題を引き起こす可能性がある、削除するクエリと追加するクエリの組み合わせを同じテーブルに識別することができました。クエリを並べ替えたり、その間に遅延を入力したりした後、数週間問題が発生したことはありません。）

Consecutive appends to different tables does not seem to be an issue.

We did not look for consecutive appends to the same table. (Though there are several such scenarios in the database)  But, likely it is not a problem or we would have seen it create the corruption issue by now. 

（異なるテーブルへの連続した追加は問題にならないようです。

同じテーブルへの連続した追加を探しませんでした。（データベースにはそのようなシナリオがいくつかありますが）しかし、おそらくそれは問題ではないか、または今ではそれが破損の問題を引き起こすことを確認したはずです。 ）

Most instances just required a reordering of the delete queries, so they were not immediately prior to the append query to the same table.

There was one instance where I used DoEvents between the queries, which seemed to alleviate the problem.

（ほとんどの場合、削除クエリを並べ替える必要があるだけなので、同じテーブルへの追加クエリの直前ではありませんでした。

クエリ間でDoEventを使用した例が1つあり、これは問題を軽減しているように見えました。）

Were you able to identify exactly what procedures/queries/macros, etc were initiated when the file became corrupt?

As indicated in previous response, we were able to identify back to back queries where there was a delete and then append query on the same table.  Adjusting these so they were not back to back and/or introducing a delay such as doevents, seems to have resolved the issue without having to use the workaround.  There may still be something else, but it has been 6-8 weeks now without the issue.

（ファイルが破損したときにどのプロシージャ/クエリ/マクロなどが開始されたのかを正確に特定できましたか？

前の応答で示したように、削除があった場所でバックツーバックのクエリを識別し、同じテーブルにクエリを追加することができました。これらが背中合わせにならないように調整したり、イベントなどの遅延を発生させたりすることで、回避策を使用しなくても問題が解決したようです。まだ何か他のものがあるかもしれません、それは今問題なしで今6-8週でした。）