クライアントとしてのAccess（３） RunSQLかCurrentDB.Executeか

Docmd.RunSQLかCurrentDB.Executeか

いつも読んでいるmougでサンプルプログラムを含めて回答を入れたところ、Docmd.RunSQLを使用しているだけでメチャクチャな酷評をレスされたことがあります。プログラムのその他の部分もまずかったのですが、Docmd.RunSQLを使用しただけで、これほど酷評されるとは。
たしかに、mougを読んでいてDocmd.RunSQLからCurrentDB.Executeに変えた方が良いという記述はよく見ますが、その逆は一度も見たことがありません。

それ以来、Docmd.RunSQLを使用していたところをCurrentDB.Executeに書き換えていますが、よく考えてみるとDomcmd.RunSQLでも良いではないかと最近思っています。

Docmd.RunSQLとCurrentDB.Executeの差はDocmd.RunSQLが非同期実行に対してCurrentDB.Executeが同期実行だということです。実のところ、今まで、Docmd.RunSQLを使用していて特に不都合は一度もありません。敢えて同期実行するCurrentDB.Executeを使用する必要があるのでしょうか。

別途サーバー（PostgreSQL)を用意していて、クライアント側のAccessからSQLを実行する際、PostgreSQLからの終了信号を待って、次の処理を行わなければならないかといことです。このブログを書くに当たって、PostgreSQLのSQL実行順が保証されているか調べてみました。ずばりこれ、といった内容は確認できませんでしたが、pgpoolで「クエリーの実行順を保証するためには」といった文章があり、PostgreSQLでは実行順が保証されているのではないかと推測されます。

同期実行が必要なのはテーブルをupdateして、その内容を直ぐに参照して次の処理を行う場合でしょう。こういったケースがあるかどうか考えてみると、少なくともサーバーのデータに関しては思い当たりません。あえていうと、複雑なレポートを作成する際に一度、mdb内の仮テーブルにレポートのレコードソース用のテーブルを用意して印刷する場合がありますが、この場合でもDocmd.RunSQLを使用していて特に不都合があったことがありません。

同期、非同期とでは処理の終了を確認して次の処理を行う分、同期の方が遅くなるはずなのですが、実際のところ、同期、非同期の違いで処理速度の違いを体感したことはありません。そうなると、あえて非同期のDocmd.RunSQLを使用する必要もないけれど、CurrentDB.Executeでなければならない理由もないのではないかと思っています。