| |
推測の部分もありますが、多分、こんな感じ？
各Executeメソッドが非同期で実行されている可能性があり、非同期実行によるリスクを
避ける為に、DoEventsで制御していると思われます。
-----
非同期：
非同期式クエリーもサポートします。クエリーを実行するときに、ほかの操作を始める前に
クエリーの実行が終了するのを待つ必要はありません。
-----
つまり、クエリー自体の処理件数、マシンスペックやネットワーク環境等に依存する可能性も
ありますが、
> CurrentDb.Execute "DELETE * FROM wrk1;" (1)
> DoEvents
>
> （略）
> DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel8, _
> "wrk1", strFileName, False, "", True (2)
という場合、DoEventsが無ければ、(1)が完了する前に、(2)が非同期で起動され、
最悪の場合、(2)で転送中のデータが(1)によって削除され、(2)終了時のデータに
整合が取れなくなる可能性があるということです。
> strSQL = "UPDATE wrk4 AS A INNER JOIN wrk3 AS B ON A.AName = B.AName "
> strSQL = strSQL & "SET B.ACode = A.ACode;"
>
> CurrentDb.Execute strSQL (3)
> DoEvents
>
> strSQL = "SELECT * FROM wrk1 WHERE F1 Is Null;"
> Set rs2 = CurrentDb.OpenRecordset(strSQL, dbOpenSnapshot) (4)
また、(3)でstrSQL変数に格納たものが実行されていますが、(4)の手前で
strSQLが更新されており、(3)の実行が完了していなければ、strSQL変数の
中身は整合が取れていない事になります。
# メモリの実行上は既に(3)で処理が動いているので、処理自体には問題が発生しないと
# 思われますが、私も所詮１ユーザなので、メモリ管理が内部でどう動いているかは
# 分かりません。
解決策としては、一連の処理をトランザクション化して、各SQL実行の同期を取るのが
良いと思われますが、具体的なルーチンは勘弁。
（BeginTrans等を使います。）
各SQLは前述したように、さまざまな環境に依存しますので、今回テストした時に、
DoEventsを外して早くなったので「外してOK」という判断は早計と思われます。
前任者はそういう非同期による処理異常をふせぐ事を踏まえ、DoEventsを各処理の
間に入れていると思われます。
（トランザクション化を知らなかった可能性もありますが。）
|
|
たん
- 05/9/7(水) 8:39 -
