FJTさん、こんばんわ。

> トランザクションは、元に戻すことが可能な一連の変更処理と理解していいよう
> ですね。これぞクライアントごとに用意するワークテーブルです。
> 排他処理は、レコードごとにロックを掛けるということで理解しているつもりで
> す。

はい、完全にその通りとは言えませんが、今のところはその理解で概ね正しいと
思います。で……。


> で、結論としては、データの更新にトランザクションを使ったVBAを書けば、ワー
> クテーブルは不要、、ということでいいでしょうか。

ここにお話が来るわけですね。何もVBAを書かなくても、適切にトランザクショ
ンやロックを使えるように、テーブルやビュー、フォームを設計し設定してあげ
れば、ワークテーブルは必要ありません。たとえば更新処理でしたら

　・この処理は開始してから終わるまでにどのくらいの時間がかかるのか？
　　（バッチならともかく、画面もあるなら、人間の操作時間も考慮しなくては
なりません）

　・その間に更新するテーブルはどれとどれか？

　・処理の間に、他のアプリ／ユーザーから変更される可能性のある情報は？

　・他のアプリ／ユーザーから更新された場合は、どちらを優先するのか？

……等などを考え合わせ、どんなトランザクションを作っていくのかを設計して
いくワケです。このトランザクション設計というヤツは、極めようとするとそれ
だけで何冊もの本になってしまうような奥の深いものですが(^^;)、ちゃんと設
計すれば、何台端末が増えてもちゃんと動くものが出来るのは、ワークテーブル
の概念を理解されてらっしゃるＦＪＴさんにならお判りいただけるものと思いま
す。


> そうなると、最初の疑問、テーブルをフォームで直接開いたときは？
> ＶＢＡでトランザクションやストアドプロシージャを使わなくても、
> テーブルをフォームで直接開いても、レコードを保存する操作をするまでは、
> ロックしないで誰でも見れて、更新する瞬間に排他処理してくれるから安心と
> 考えていいのでしょうか。

これは「楽観的排他処理」という考え方ですね。とにかく後からされた更新を有
効とする、という考え方です。他に「悲観的排他処理」という考え方もあります。
現在画面に表示されている／操作しているレコードには誰も触れさせない（使お
うとするとエラーになる）、そのレコードの編集が終了、あるいは別のレコード
に移動したら他のアプリケーションからアクセスできるようになる、という考え
方です。これは、どちらを考え方を採用するかによって、フォームやストアドプ
ロシージャ、ビューの記述／設定が変わってきますが、MSDEならどちらの考え方
も使えます。


肝心なことは、このトランザクション機能や排他機能は、既にRDBMSに組み込ま
れているということなのです。データベースに組み込まれているのですから、当
然信頼性も高いですし、動作は高速です。障害に対する耐性もあります。せっか
くMSDEというちゃんとしたRDBMSを使用するのですから、可能な限りワークテー
ブルを排して、こういった便利な機能を使って行きましょう、というのが、私の
言いたかったことなのです。


この辺の機能は上記の通り、非常に奥が深いものですが、頑張って身に付ければ
（この業界に居る限りは）必ず役に立つことは保証できます。私もまだまだ初心
者ですが、お互いに頑張って勉強していきましょう。



丸山　宏徳（朽木　三郎）

E-Mail:who@example.ne.jp