クライアントとしてのAccess（２） 連結フォームか非連結フォームか？

やはり一番問題なのは、フォームを連結フォームとして作成するか、非連結フォームとして作成するかという問題だと思います。ここでいうフォームはデータを入力したり、編集したりする場合のフォームです。単に参照するだけのフォームは当然、連結フォームとして作成します。
以前読んだホームページでは、その人はプロのプログラマーだったようですが、「Accessで連結フォームでプログラムを書いたことがない。」という記述がありました。
mdb内（あるいはaccdb内で。以下、mdb内でとします。）でテーブルもフォームも完結している場合、よく入門書にあるように連結フォームとして作成して、レコードセレクターでレコードを選択して更新、「*」をクリックして新規作成といった方法でも可能かもしれません。しかし、本格的なデータベースのクライアントしてAccessを使用する場合、この方法はとれません。
一つにはフォームとテーブルを更新可能なフォームとして連結することで、他のクライアントとレコードがロックする可能性がかなり高くなります。また、テーブルが大きくなるとレコードセレクターでいちいちレコードを移動しならがらレコードを選択するといった作業は実用的とは言えません。フィルターをかけてレコード数を限定したとしてもやはりレコードセレクターでのレコードの移動は面倒です。
更新不可とした参照用フォームからレコードを選んで、更新フォームでは対象となる１レコードのみと連結するかどうかです。このフォームを連結フォームとするか、非連結とするかといった問題です。

パターンとしては次の３種類が考えられます。
１．データベースの１レコードのみをレコードソースとする連結フォーム
２．データベースと同じテーブル構造を持ったmdb内のテーブルと連結したフォーム
２．非連結フォーム

それぞれメリット、デメリットがあります。
１は例えば、サーバーのPostgreSQLのテーブルと１レコードのみ連結したフォームです。この方法では更新時に何らかの理由でフォームが落ちてしまっても、データは変更されています。特に、更新時にクエリーを実行しなくてもデータが変更できます。フォームを閉じてしまえば、更新処理は完了です。Accessの基本的な方法と言えます。デメリットとしては他の人がデータを更新しようとした場合、PostgreSQLのデフォルトでの設定では行ロックがかかってしまいます。設定によって行ロックをかけない方法もあるのかもしれませんが、よくわかりません。また、ロックをかけるべきだと思います。一つのレコードを全く同時に二人の人が編集しているというのは適切でないと思います。

２の方法は更新したいレコードを端末である自分のPC内に一度、取り込んでそれを編集する方法です。フォームが存在するmdb内にテーブルを用意してそのテーブルにデータを取り込みます。フォームはそのテーブルと連結します。この方法だと、フォームが落ちても編集したデータそのものはmdb内に残っています。ただし、編集終了時にはサーバーのテーブルにupdateしてやらなければなりません。この方法で気をつけなければならないのは、VBAでレコードを編集する際、あくまで連結したフォームのテキストボックスの値を書き換えてやらなければならないということです。VBAでいきなり、連結テーブルをupdateしてはいけません。こんなことをすると、フォームとコード両方でフェッチしてしまい。フォームを閉じる時、「他のユーザーが編集しています。」といったメッセージボックスが表示され、フォームで編集したデータが更新されません。あくまで、編集するのはフォームのテキストボックスです。

３番目の方法はアッサリ、非連結フォームにしてしまうという方法です。データ更新時には更新したいレコードをフォームのテキストボックスに代入してやり、終了時にはテキストボックスの値をサーバーのテーブルにupdateします。この方法だとロックがかかったり、「他のユーザーが編集しています。」状態には絶対になりません。Accessの自動的な機能を全く使用しない方法です。

私自身は、販売管理プログラム作成前に上記の「Accessで連結フォームでプログラムを書いたことがない。」という記述を読んでいたために、主として３番目の方法で作成しました。売上伝票入力画面、受注伝票入力画面のように入力行の制限がある（紙伝票の入力可能行数の制限で一度に入力できる明細行数が限られている）場合はこの場合に当たります。

また、仕入伝票入力画面、入金伝票入力画面、支払伝票入力画面は２番目の方法で作成しました。仕入伝票は仕入先から送られてくる納品書を元に入力しますが、１枚の伝票行数を忠実に守る必要はありません。何行でも連続して入力しても全く問題ありません。実際、仕入先から送られてくる伝票１枚の明細行数は一定ではありません。決まった行数しか入力できないフォームは使いにくいです。入金、支払については全くの社内処理なので、入力行数に決まった制限はありません。

実は１番目の方法でフォームを作成したこともあります。比較的最近のブログで書きましたが、サーバーのテーブルと直接連結したフォームを作成して、たまにロックがかかってしまいます。そのフォームというのは本当にたまにしか変更しないマスターファイルです。同時に２つ以上の端末から修正する可能性がほとんどないマスターファイルの修正はこの方法でフォームを作成したものがあります。実際、たいしたコードを書かなくても所用の動作を行うことができるので、一番簡単ではあります。しかし、この方法はあまりよくありません。フォームを閉じた後もロックが残ってしまうと、サーバーのKeepAlive頼みでロック解除を待つしかありません。新規作成の場合もPostgreSQLの主キーをSerial型にしておけば、そのフォームを開いて閉じるだけで新規作成できます。本当に簡単なのですが。