muroです。

水口 敬唯さん、回答ありがとうございます。

> > その場合、どのマシンがデータ修正を行っているかの情報を込みで
> > 作業用テーブルにいれていかないといけないですね。
> > 今までは、フロントエンドの方においていたため、どのマシンがという
> > 心配はなかったので。
> 「取り消し」の意味がよくわからないのですが、「入力欄とフィールドを直接バ
> インドしていて、その結果ユーザーの修正がリアルタイムに反映されるため、そ
> れを元に戻すための仕掛け」でしょうか？

まさにそれです。何か良い方法がありますか？

> クライアント側に作業用テーブルをおくような方法は、クライアント/サーバシス
> テムでは普通採用しません。こういうアプローチを取ると、帳票作成用のデータ
> が大量にネットワークを流れることになり、システム全体のパフォーマンスが落
> ちるからです。「ストアドプロシージャ」については、Accessにはなかった概念
> なのできちんと学習することをお奨めします。今までクライアント側でごちゃご
> ちゃ行ってた処理を、サーバに任せる仕掛けです。こうすることでネットワーク
> のトラフィックの負担を下げることができます。

つまり、ストアドプロシージャというのを使うと、その中での処理はサーバで行っ
て、
結果（レコードの集まり）がネットワークを流れてクライアントにくるって感じです
かね。
それでは、ビュー、ストアドプロシージャをフォーム、レポートに連結させる場合、
同じようにその中での処理は、サーバで行って、結果がネットワークを流れて
フォーム、レポートに来てると考えるのでいいのですよね。

それでは、以下のようなことが出てくるのですかね。
１．１００レコードを結果とするストアドプロシージャ
２．１レコードを結果とするストアドプロシージャ
検索を行う場合、１．をはじめに行い、その中で移動するパターンと２．を検索する
たびに
行うパターンでは違いがでてくるってことですよね。
はじめのパターンだと、ネットワークにデータが流れるのははじめだけで、その中で
の
移動の場合は、ネットワーク上には何も流れない。しかし、はじめは時間がかかる。
後のパターンだと毎回ネットワークにデータが流れるが、その1回1回はさほど時間が
かからない。
これは、正しい理解ですかね。

更には、フォームに連結されたフォームからデータを修正するよりも、フォームと
非連結にして最終的に更新のストアドプロシージャでサーバに書き込むほうが、
ネットワークの負荷かからないってことですかね。

> 「各クライアントにフロントエンド＆バックエンド両方あり、普段は、そこで処
> 理をしています。そして、何日かに一度サーバに対して、アップデート処理をか
> けます。」という、いわば手動レプリケーションを採用したことが、先見の明が
> あったといえると思います。もし、リアルタイムでクライアントからサーバの
> MDBを直接更新なんかしていたら、悲惨なことになっていたと思います。室節さん
> のようなアプローチを取るなら、Accessでもそこそこの信頼性は望めます。が、
> そのために余分な工数が発生するので、保守する側は大変でしょうね。

レプリケーションというのを今後勉強すれば、自動でできるってことですかね。
それでは、一段落着いたら今度は、レプリケーションを採用し、改版しようと思いま
す。
もし、よろしければ、レプリケーションの勉強をする上で参考にしたらいい、HP、著
書
などがありましたら、紹介していただけませんでしょうか?

> では、がんばってください。

激励ありがとうございます。
がんばります。