スキルアップ・問題解決なら、モーグにおまかせ！

このために、
１.サーバーテーブルをローカルテーブルへコピー
２.帳票フォームでローカルテーブルを表示しつつ、レコード入力・変更時にはローカルテーブルを変更
３.そのローカルテーブルをもとにサーバーのテーブルをフィールド単位で更新する
４.更新されたサーバーテーブルをローカルテーブルへコピー
という形を検討しています。
　※一つの帳票フォームでの使用であり、別の入力フォームの作成は不可。
 
２.〜４.はなんとか解決できた（トピック：コントロールソースを別テーブルに動的設定したい）のですが、１.のコピーについては、常に最新のサーバーテーブルを表示するようにしたいがレコード件数が約13万件、フィールド数が約140あり、コピーするにも時間がかかり現実的でないと思っています。
 
フォームの表示内容と更新等の処理を切り分けて考えることでできれば、できるような気がするのですが、Access自体の知識も乏しく良い方法が思いつきません。
何か良い方法や作り方があれば、ご教示お願いします。
 
よろしくお願いします。

引用:
１.サーバーテーブルをローカルテーブルへコピー
２.帳票フォームでローカルテーブルを表示しつつ、レコード入力・変更時にはローカルテーブルを変更

引用:
１.のコピーについては、常に最新のサーバーテーブルを表示するようにしたいがレコード件数が約13万件、フィールド数が約140あり、コピーするにも時間がかかり現実的でないと思っています。

引用:
ただ。。。
単票フォームなら、連結フォームとせず、非連結フォームとしてしまった方が楽でしょう。

引用:
1：編集前の表示の画面では、サーバーテーブルのレコードを表示　その中から編集するレコード指定
2：編集画面を開く際に、サーバーかローカルに 当該レコードをコピー
　　編集画面にはローカルのコピーしたレコードを表示　になります。
2： で表示するレコードが 1件のみであれば、単票フォームになるでしょうから
　　連結フォームにするメリットがありません。非連結フォームで十分です。

引用:
非連結フォームを処理する流れとしては
1：編集前の表示の画面では、サーバーテーブルのレコードを表示　その中から編集するレコード指定
ここは一緒。
 
2：非連結フォームの、各コントロールに 1で指定した レコードの値を代入。
　　(編集を行う 単票フォームのレコードソースやレコードセットには何も指定せず
　　コントロールのコントロールソースにも何も指定しません)
 
　保存ボタンを押した際に、画面上の値を サーバーの当該レコードの各フィールドの値として保存します。
　ローカルテーブルは必要ありません。

おーさん0729 さんの引用:
このやり方だと帳票フォームと入力フォームを分ける必要がありませんか？
 
編集前の表示の画面（帳票フォーム）上で入力・更新といった編集をしたいです。

引用:
１.サーバーテーブルをローカルテーブルへコピー
 
１.のコピーについては、常に最新のサーバーテーブルを表示するようにしたいがレコード件数が約13万件、フィールド数が約140あり、コピーするにも時間がかかり現実的でないと思っています。
 
フォームの表示内容と更新等の処理を切り分けて考えることでできれば、できるような気がするのですが、

引用:
フォームの表示内容と更新等の処理を切り分けて考えることでできれば、できるような気がするのですが、

いつも返信ありがとうございます。
 
編集前の表示の画面（帳票フォーム）でサーバーテーブルをソースにして、
レコードの検索結果のうち、検索結果レコードに表示フラグをもたせ、ローカルテーブルに追加、
ローカルテーブルレコードの表示フラグでフィルター設定する（ローカルテーブルにあるレコードだけを表示するように）
で直接サーバーテーブルを編集しつつ、表示はローカル依存にできるのではないかと考えました。
また、テーブルは、サーバーとローカルで、IDでリレーションさせてます。
 
この場合、サーバーテーブルをレコードソースにもつフォームをローカルテーブルのフィールドでフィルター設定することは可能でしょうか。
もしくは、一致クエリを使えば可能でしょうか。
設定を間違っているのか、うまく設定できません。
自分自身、Accessの理解がまだあまりできておらず、あいまいな説明になっていて申し訳ありません。

引用:
編集前の表示の画面（帳票フォーム）でサーバーテーブルをソースにして、
レコードの検索結果のうち、検索結果レコードに表示フラグをもたせ、ローカルテーブルに追加、
ローカルテーブルレコードの表示フラグでフィルター設定する
（ローカルテーブルにあるレコードだけを表示するように）
で直接サーバーテーブルを編集しつつ、表示はローカル依存にできるのではないかと考えました。

引用:
検索結果レコードに表示フラグをもたせ、ローカルテーブルに追加、

引用:
ローカルテーブルレコードの表示フラグでフィルター設定する
　（ローカルテーブルにあるレコードだけを表示するように）

引用:
　テーブルは、サーバーとローカルで、IDでリレーションさせてます。

引用:
Fld1 Fld2 Fld3 Fld4
1 A J K

引用:
同一レコードに対し、同時に複数ユーザーが 別のフィールドのValue を更新する

ありがとうございます。

引用:

記述されている処理の内容が理解できかねます。
その処理の目的・意図は何でしょうか？

引用:

方法.B

引用:
ローカルテーブルレコードの表示フラグでフィルター設定する
　（ローカルテーブルにあるレコードだけを表示するように）

引用:
　テーブルは、サーバーとローカルで、IDでリレーションさせてます。

　から ※1 の処理の意図を推測すると、
　　ローカルテーブルに、表示したい ID の値を保存。
　　その ID を、
　　SELECT * FROM
      サーバーテーブル INNER JOIN ローカルテーブル ON サーバーテーブル.ID = ローカルテーブル.ID
　　の様な感じに使いたい。
　　とも読めるのですが、
　　そうであるなら、ローカルテーブルにフィルターを適用するだけで、※1 の必要性がありません。

引用:

当方の前提条件は
・複数人ユーザーによる
・同一レコードにおいて、それぞれのフィールドの値を、それぞれ別のユーザーが同時に編集状態に入る
　　（フィールドA は ユーザーA、フィールドB は ユーザーB、・・・）があり得る
・を 帳票フォーム(帳票フォームの様に見えるを含む)で処理する
であり、
先のスレッド
https://www.moug.net/faq/viewtopic.php?t=81934

引用:
Fld1 Fld2 Fld3 Fld4
1 A J K

の実現を前提として検討しています。
23/01/06 08:59:23

引用:
同一レコードに対し、同時に複数ユーザーが 別のフィールドのValue を更新する

をお聞きしていますが、その回答を得られていません。
前提条件が違うのかどうなのか、説明をお願いします。

引用:

その前提条件が同じで、
　同一レコードに対し、別ユーザーが別フィールドに値を更新する為に
 23/01/06 21:28:52 の仕組みをお考えなら、先に説明した様に、
　レコードソースがサーバーテーブルである以上、実現できません。
前提条件が別で、 23/01/06 21:28:52 の仕組みをお考えなら、その意図をお聞かせください

引用:

他の方の質問の中でも、うまくいきません の様な 記載がある事が多いです。
でも うまくいかない だけでは、回答者には、何が希望と違うのかが判らず
原因も答えようがない事が多いです。
その様な事も考慮し、記載する事をお願いします。

1. 常に最新のサーバーテーブルを表示するようにしたい
2. レコード件数が約13万件、フィールド数が約140あり
3. 複数人ユーザーが同一レコードを同時編集することがある、その場合、最後に編集したユーザーのデータがテーブルに格納されればよい
4. 帳票フォーム上で入力・更新
 
ご希望の要点だけ抜き出すと上記のようなことでしょうか。
 
1.に関しては、サーバーテーブルのリンクテーブルを帳票フォームのレコードソースに設定することになるでしょう。
2.のデータ量だと表示に時間がかかるでしょうし、13万ものレコードを帳票表示して目的のレコードをスクロールして探すのは現実的ではないので、なんらかの抽出条件を設定して表示件数を絞り込んで、そのなかから目的のレコードを探すということになるでしょう。
 
3.は非連結フォームに帳票フォームのカレントコードのデータをコピーして、編集後、帳票フォームのレコードに上書きして保存すればいいでしょう。更新クエリで更新するという手もありますが、VBAで帳票フォームのカレントレコードに代入してレコード保存すれば一瞬ですので、更新クエリと大差ないでしょう。
 
ローカルテーブルにこだわっているようですが、要件からみてローカルテーブルにする必要性があるとは思えません。
そもそもご自身が最初に「コピーするにも時間がかかり現実的でないと思っています。」といっていますし。
 
4.に関しては、投稿日時: 23/01/06 17:20:18 の回答で提示した、非連結フォームを帳票フォームのカレントレコードに重ねて表示させればいいでしょう。
非連結フォームは帳票フォームの詳細セクションのレイアウトと同じにしておけばユーザーは帳票フォーム上で編集しているようにみえると思います。
 
非連結フォームを重ねるタイミングが難しいですが、編集ボタンを配置してそれをクリックして編集開始ということにしておけばそのタイミングで重ねればいいでしょう。保存も保存ボタンクリックで実行すればいいでしょう。
 
最初に提示した要件なら、私ならこのような設計にします。

同一レコード に対し、複数人ユーザーが 別々のフィールドを編集する 事を前提に回答していましたが
それを諦めるのであれば、
　サーバーテーブルをソースとする連結の帳票フォームで良いです。

引用:
あとで編集したデータが優先される仕組み、もしくは、「編集できなかった」と表示される仕組みを作れれば、良さそうです。

引用:
サーバーテーブルに表示フラグを持たせると、複数人使用時に検索結果の画面が同じになってしまう

「あとで編集したデータが優先される仕組み、もしくは、「編集できなかった」と表示される仕組み」とあるので、
 
前スレッドでの
 
同一レコードに対し、複数人がそれぞれ別フィールドの値を同時に更新する→それぞれの更新がテーブルに反映されるようにしたい
 
はあきらめたと解釈しましたが、可能なら実現したいということなら、
 
非連結フォーム(1レコードのみのワークテーブルでもいいですが)で、
どのフィールドを更新したかを配列にでも記録しておいて、
保存ボタンを押して、レコード保存するときに、
帳票フォームを Refeshメソッドでカレントレコードの最新データを読み込んで、
非連結フォームの更新していないフィールド値と帳票フォームの最新値と異なっていたら、
最新値の方で更新するというロジックでいいと思います。
 
これらの処理をVBAで短時間にすれば( Refeshメソッドはカレントレコードのみの読み込みなので時間はかからない)、Refesh → レコード保存が、複数ユーザーで重なることは稀ではあると思いますが、重なる場合を考慮するなら、Refesh → レコード保存の間はレコードロックをかけておくという処理を追加すればいいでしょう。更新時にロックされていて更新に失敗したら少し時間を置いて再トライするという処理にすればいいでしょう。

Suzu さんの引用:
同一レコード に対し、複数人ユーザーが 別々のフィールドを編集する 事を前提に回答していましたが
それを諦めるのであれば、
　サーバーテーブルをソースとする連結の帳票フォームで良いです。

引用:
あとで編集したデータが優先される仕組み、もしくは、「編集できなかった」と表示される仕組みを作れれば、良さそうです。

これも、更新時に同様の趣旨のメッセージが表示されます。
それでも、先の方法にこだわるのであれば、不満がおありなのだと思います
不満の内容は何でしょうか？

引用:

抽出にしても、帳票フォームに対し、フォームフィルター を適用する事で事足りると思います。
　検索条件を入れるにしても
　　・フォームォームヘッダーへ配置し、フォームフィルターを適用する
　　・単票フォームに条件を入れ、そこから帳票フォームを開くにしても
　　　Docmd.OprnForm の WhereCondition 引数 へ その条件を渡せば フォームフィルターへ適用できます。
　　・単票フォーム に、条件を入れる 各コントロールとサブフォームコントロールを配置
　　　サブフォームコントロールのコントロールソースをを帳票フォームとし、
　　　　リンク親子 を、条件を入れる各コントロール
　　等の方法もあります。
 
　抽出条件を別のフォームやレポートで利用したいなら、
　その 抽出条件 を 設定する事になる
　　Me.Filter プロパティー の 値 を
　　　対象となる オブジェクトの Filterプロパティに渡す
　　　対象となる オブジェクトを開く際の WhereCondition引数に渡す　
　で実現できます。
 
レコードソースとなるテーブルに 表示フラグを持たせる方法を採るにしても

引用:
サーバーテーブルに表示フラグを持たせると、複数人使用時に検索結果の画面が同じになってしまう

これは、表示フラグ Yes/No型 で考えていますよね？
Yes/No型 ではなく、「ユーザー名」またはユーザーを特定する数値を入れるフィールドを配置
その 値 で抽出する様にすれば 良いです。

引用:

何にしても、前スレッドで提案した、ローカルテーブルを持たせる手法は
【　同一レコードに対し、複数人がそれぞれ別フィールドの値を同時に更新する　】
　　を実現させる為に提案しています。
そうでないなら、サーバーテーブル（にリンクしたリンクテーブル）をソースにした
帳票フォームを作成すれば良いと思います。

hatena さんの引用:
「あとで編集したデータが優先される仕組み、もしくは、「編集できなかった」と表示される仕組み」とあるので、
前スレッドでの
同一レコードに対し、複数人がそれぞれ別フィールドの値を同時に更新する→それぞれの更新がテーブルに反映されるようにしたい
はあきらめたと解釈しましたが、可能なら実現したいということなら、
非連結フォーム(1レコードのみのワークテーブルでもいいですが)で、
どのフィールドを更新したかを配列にでも記録しておいて、
保存ボタンを押して、レコード保存するときに、
帳票フォームを Refeshメソッドでカレントレコードの最新データを読み込んで、
非連結フォームの更新していないフィールド値と帳票フォームの最新値と異なっていたら、
最新値の方で更新するというロジックでいいと思います。
これらの処理をVBAで短時間にすれば( Refeshメソッドはカレントレコードのみの読み込みなので時間はかからない)、Refesh → レコード保存が、複数ユーザーで重なることは稀ではあると思いますが、重なる場合を考慮するなら、Refesh → レコード保存の間はレコードロックをかけておくという処理を追加すればいいでしょう。更新時にロックされていて更新に失敗したら少し時間を置いて再トライするという処理にすればいいでしょう。

引用:
現時点では、保存ボタンの作成は考えていません。

引用:
表示フラグ Yes/No型でしてますが、フィールドが１つしかないと個別の値にしても、使用者AとBの検索結果がかぶったときに上書きされて、最初の人は表示されなくなりませんか？

フィールド毎に更新されたらそく反映する場合、
非連結フォームを重ねるという方法を提案しましたが、今、もっといい方法があるのを思い出しました。
 
帳票フォームの連結テキストボックスの背面に非連結テキストボックスを配置する方法です。連結テキストボックスと非連結テキストボックスのサイズを同じにしておけば、通常は非連結テキストボックスは連結テキストボックスの背面に隠れています。非連結ボックスにフォーカスが当たると前面に出てくるという性質があります。
 
連結テキストボックスのタブストップは「いいえ」にしてフォーカスが来ないようにしておいて、フォーカス取得時に、非連結へフォーカス移動するようにしておきます。
 
非連結テキストボックスの更新後処理に下記のような処理を設定しておきます。
 
Me.Refresh で最新データの読み込み
フィールドに非連結の値を書き込み
Me.Refresh でレコード保存、再読込
 
コードとしては下記のようになります。
 

Private Sub 連結テキストボックス_Enter()
    Me.非連結テキストボックス.SetFocus
End Sub

Private Sub 非連結テキストボックス_AfterUpdate()
    Me.Refresh
    Me.連結テキストボックス.Value = Me.非連結テキストボックス.Value
    Me.Refresh
End Sub

もう一度 良く読み返し
 
当方の認識から

引用:
2.のデータ量だと表示に時間がかかるでしょうし、13万ものレコードを帳票表示して目的のレコードをスクロールして探すのは現実的ではないので、なんらかの抽出条件を設定して表示件数を絞り込んで、そのなかから目的のレコードを探すということになるでしょう。

引用:
自分なら、クライアント側に ID と 表示フラグ(Yes/No型) のフィールドのみのテーブルを作成しておいて、サーバーのリンクテーブルとIDで外部結合させればいいでしょう。

引用:
フィールドが１つしかないと個別の値にしても、使用者AとBの検索結果がかぶったときに上書きされて、最初の人は表示されなくなりませんか？

引用:
「サーバーテーブル（にリンクしたリンクテーブル）をソースに」が何とリンクさせているのか、いまいちよく分かっていません...

面白そうだったので、投稿日時: 23/01/12 10:47:36 の回答の方法のサンプルを作成してみました。
 
ソースのテーブルは下記
 
ID 主キー　オートナンバー型
F1 短いテキスト
F2 短いテキスト
F3 短いテキスト
F4 短いテキスト
F5 短いテキスト
 
上記のテーブルを元に帳票フォームを作成。
各連結テキストボックス名はフィールド名と同じ。
上記のテキストボックスをコピーして貼り付け。
コントロールソースを削除、
名前を txtF1, txtF2 ・・・・というように前に連結テキストボックス名の前にtxtを追加したものに変更。
 
フォームモジュールに下記のコードを記述。
 

Option Compare Database
Option Explicit
Private OldValue

Private Function FocusChange()
    Me("txt" & Me.ActiveControl.Name).SetFocus
End Function

Private Function txtGotFocus()
    MyRefresh
    OldValue = Me.ActiveControl.Value
End Function

Private Function txtAfterUpdate()
    Dim NewValue, CurValue
    Me.Refresh '最新データ読み込み
    NewValue = Me(Mid(Me.ActiveControl.Name, 4)).Value
    If NewValue <> OldValue Then
        If MsgBox("他のユーザーがこのフィールドを更新しました。編集した値で上書きしてもいいですか。", vbYesNo) = vbNo Then
            MyRefresh
            Exit Function
        End If
    End If
    Me(Mid(Me.ActiveControl.Name, 4)).Value = CurValue
    MyRefresh
End Function

Public Sub MyRefresh()
    Me.Refresh '最新データ読み込み
    '↓非連結テキストボックスを最新データに更新
    Dim ctl As Control
    For Each ctl In Me.Controls
        If ctl.Name Like "txt*" Then
           ctl.Value = Me(Mid(ctl.Name, 4)).Value
        End If
    Next
End Sub

hatena さんの引用:

上記のようにすると、イベントとFunctionプロシージャを関連付けることができるので、各コントロールのイベント処理を共通化できます。(Accessはクラスを使わなくてもこのような方法で共通化できるので楽です。)

引用:
よくわからずに、モジュールに書いたFunctionをCallで呼び出してたのですが、もっと簡単にできるってことですよね？

hatena さんの引用:

ソースのテーブルは下記
ID 主キー　オートナンバー型
F1 短いテキスト
F2 短いテキスト
F3 短いテキスト
F4 短いテキスト
F5 短いテキスト
 
上記のテーブルを元に帳票フォームを作成。
各連結テキストボックス名はフィールド名と同じ。
上記のテキストボックスをコピーして貼り付け。
コントロールソースを削除、
名前を txtF1, txtF2 ・・・・というように前に連結テキストボックス名の前にtxtを追加したものに変更。
 
フォームモジュールに下記のコードを記述。
 

Option Compare Database
Option Explicit
Private OldValue

Private Function FocusChange()
    Me("txt" & Me.ActiveControl.Name).SetFocus
End Function

Private Function txtGotFocus()
    MyRefresh
    OldValue = Me.ActiveControl.Value
End Function

Private Function txtAfterUpdate()
    Dim NewValue, CurValue
    Me.Refresh '最新データ読み込み
    NewValue = Me(Mid(Me.ActiveControl.Name, 4)).Value
    If NewValue <> OldValue Then
        If MsgBox("他のユーザーがこのフィールドを更新しました。編集した値で上書きしてもいいですか。", vbYesNo) = vbNo Then
            MyRefresh
            Exit Function
        End If
    End If
    Me(Mid(Me.ActiveControl.Name, 4)).Value = CurValue
    MyRefresh
End Function

Public Sub MyRefresh()
    Me.Refresh '最新データ読み込み
    '↓非連結テキストボックスを最新データに更新
    Dim ctl As Control
    For Each ctl In Me.Controls
        If ctl.Name Like "txt*" Then
           ctl.Value = Me(Mid(ctl.Name, 4)).Value
        End If
    Next
End Sub

 
ID以外の連結テキストボックスを選択した状態で、プロパティのフォーカス取得時に
=FocusChange()
と設定。
非連結テキストボックスを選択した状態で、プロパティのフォーカス取得後に
=txtGotFocus()
更新後処理に
=txtAfterUpdate()
と設定。

一番の課題は、検索した後の表示レコードの表示の仕方だと気付きました。
紆余曲折してすみません。

引用:
「表示フラグ」の必要性が理解できてませんが、必要なら、ユーザー毎に表示フラグを持たせる場合、自分なら、クライアント側に ID と 表示フラグ(Yes/No型) のフィールドのみのテーブルを作成しておいて、サーバーのリンクテーブルとIDで外部結合させればいいでしょう。
一対一関係になりますので扱いにちょっとこつがいりますが、下記を参考にしてみてください。
一対一関係のテーブル設計 - hatena chips
https://hatenachips.blog.fc2.com/blog-entry-29.html

おーさん0729 さんの引用:

同じように作成したのですが、NewValue=""となってしまい、入力後に空欄になってしまいました。

Me(Mid(Me.ActiveControl.Name, 4)).Value = CurValue

Me(Mid(Me.ActiveControl.Name, 4)).Value = Me.ActiveControl.Value

おーさん0729 さんの引用:
一番の課題は、検索した後の表示レコードの表示の仕方だと気付きました。
紆余曲折してすみません。

おーさん0729 さんの引用:

参考に一対一のリレーションは（たぶん）できたのですが、リンクの例で言うと、
�@フォームに従のレコード表示ができない（ソースの設定がうまくいかない？）
�A従のレコードを使用したフィルター設定ができない
で困っています。

hatena さんの引用:

おーさん0729 さんの引用:

同じように作成したのですが、NewValue=""となってしまい、入力後に空欄になってしまいました。

あっ、すみません。いろいろ修正していたのですが、修正する前のもの貼り付けていたようです。
Function txtAfterUpdate()内の下記の部分を修正してください。
 

Me(Mid(Me.ActiveControl.Name, 4)).Value = CurValue

↓
 

Me(Mid(Me.ActiveControl.Name, 4)).Value = Me.ActiveControl.Value

hatena さんの引用:
検索(抽出)処理はうまくできているということですか。(処理速度的にも問題ないですか。)
抽出した後、さらに、チェックボックスで表示するレコードを絞り込むということでしょうか。

引用:
リンク先を参考にクエリを作成したのでしょうか。
そのクエリのSQL文を提示してもらえますか。文を提示してもらえますか。

おーさん0729 さんの引用:

�@サーバーレコードを特定検索（自作処理）
�A該当するレコードをローカルレコード（ID、表示フラグ）に追加。
�Bそのローカルレコードと同じサーバーレコードだけを表示。（フィルター設定？）
です。
 
したいことは「ローカルレコードに存在するレコードと同じサーバーレコードの表示」です。
もしくは、「抽出条件をローカルレコードにしたサーバーレコードの表示」です。
あくまでも、表示するのはサーバーレコードです。
投稿日時: 23/01/11 14:42:58や投稿日時: 23/01/12 08:20:21でも触れている内容です。
表示フラグにこだわりません。表示するレコードがサーバーレコードであり、複数の使用者で共用にならなければ、大丈夫だと思います。

引用:
�@サーバーレコードを特定検索（自作処理）とは、具体的にどのような処理なのでしょう。
抽出条件を生成してフィルターをかけるということでしょうか。
もし、そうならその時点で目的のサーバーレコードの絞り込みはできているということではないですか。
その抽出条件を帳票フォームのフィルターに設定すれば済む話だと思いますが。あるいは、抽出条件を設定したクエリをレコードソースに設定すればいいと思いますが。
ローカルテーブルが必要になる必然性が分かりません。
抽出条件の生成ではないのなら、�@サーバーレコードを特定検索（自作処理）[/color]の具体的に内容を説明してください。

コードを提示していただいたので、解読を試みたが、とてもじゃなけど読めません。
未定義の変数が多数あり、無駄な処理が多数あり、・・・・
そもそも、コンパイルエラーで実行不可、
 

引用:
�@検索用フォームに検索ワードを入力する。複数入力、and,or可能（見た目は表示用フォームと同じ）
�A対応するフィールドで検索ワードを使い、抽出。
�B表示フラグを持たせる
�C表示フラグでフィルター設定

テーブル
　T_サーバー        ID(COUNTER:主キー), 他フィールド
　T_ローカル        |D(Long), 選択(Yes/No)
 
 
処理
1　検索用 帳票フォーム
　　ソース
    SELECT T_サーバー.*, T_ローカル.選択
    FROM T_サーバー INNER JOIN T_ローカル ON T_サーバー.ID INNER JOIN T_ローカル.ID
 
　　詳細セクションに
    T_サーバーの 表示したいフィールド と　T_ローカルの 選択 をソースとしたコントロールを配置
 
　　フォームヘッダーに
    検索用のコントロールを配置
 
2　検索用フォーム を開く前に T_サーバーの ID の最大値を取得
    T_ローカルのID に、最大値までの値を全て追加
    (更新クエリにて、T_ローカルの選択を全て False に変更)
 
3　検索用フォームを開く (Filter = Off)
 
4　ユーザーは、検索用フォーム フォームヘッダーに検索条件を入力し
　　フィルターにて、レコード抽出(Filter = On)
 
5　ユーザーは 表示したいレコードの「選択」をチェック
 
6　適当なイベントで
　　レコードソースを
    SELECT T_サーバー.*, T_ローカル.選択
    FROM T_サーバー INNER JOIN T_ローカル ON T_サーバー.ID INNER JOIN T_ローカル.ID
    WHERE T_ローカル.選択=True
　　としたフォームを開き
　　検索フォームを閉じる
 
全体はこんな感じで良いのでは？
 
 
別になりますが、
表示したいテーブルを、フォームとして表示した状態で、
そのテーブルを、SQL の UPDATE 〜 等で 更新しない方が良いです。
 
フォーム として表示しているという事は、レコードを使用している状態です。
ここで、SQL UPDATE〜 を 処理すると言う事は、別ルートでテーブルにアクセスしています。
 
・フォームを閉じる
・フォームのレコードが表示されない様にし、レコードソースに "" を渡し、
　　一時的に非連結フォームとし、処理が終わったら、レコードソースを元に戻す
・UPDATE〜 を使用しないで、フォームのレコードセットに対しループ処理
等の方が接続数を減らすという意味で、良いと思います。

hatena さんの引用:
コードを提示していただいたので、解読を試みたが、とてもじゃなけど読めません。
未定義の変数が多数あり、無駄な処理が多数あり、・・・・
そもそも、コンパイルエラーで実行不可、
 
�@�Aで抽出ができている、つまり、抽出条件が生成できているので、それを帳票フォームにフィルターに設定するだけのこと。
�B�Cは不要です。
 
これが理解できないなら、私とは次元の違う位置にいると思われますので、これ以上の私からのアドバイスはないです。

Suzu さんの引用:
テーブル
　T_サーバー        ID(COUNTER:主キー), 他フィールド
　T_ローカル        |D(Long), 選択(Yes/No)
 
 
処理
1　検索用 帳票フォーム
　　ソース
    SELECT T_サーバー.*, T_ローカル.選択
    FROM T_サーバー INNER JOIN T_ローカル ON T_サーバー.ID INNER JOIN T_ローカル.ID
 
　　詳細セクションに
    T_サーバーの 表示したいフィールド と　T_ローカルの 選択 をソースとしたコントロールを配置
 
　　フォームヘッダーに
    検索用のコントロールを配置
 
2　検索用フォーム を開く前に T_サーバーの ID の最大値を取得
    T_ローカルのID に、最大値までの値を全て追加
    (更新クエリにて、T_ローカルの選択を全て False に変更)
 
3　検索用フォームを開く (Filter = Off)
 
4　ユーザーは、検索用フォーム フォームヘッダーに検索条件を入力し
　　フィルターにて、レコード抽出(Filter = On)
 
5　ユーザーは 表示したいレコードの「選択」をチェック
 
6　適当なイベントで
　　レコードソースを
    SELECT T_サーバー.*, T_ローカル.選択
    FROM T_サーバー INNER JOIN T_ローカル ON T_サーバー.ID INNER JOIN T_ローカル.ID
    WHERE T_ローカル.選択=True
　　としたフォームを開き
　　検索フォームを閉じる
 
全体はこんな感じで良いのでは？

引用:

別になりますが、
表示したいテーブルを、フォームとして表示した状態で、
そのテーブルを、SQL の UPDATE 〜 等で 更新しない方が良いです。
 
フォーム として表示しているという事は、レコードを使用している状態です。
ここで、SQL UPDATE〜 を 処理すると言う事は、別ルートでテーブルにアクセスしています。
 
・フォームを閉じる
・フォームのレコードが表示されない様にし、レコードソースに "" を渡し、
　　一時的に非連結フォームとし、処理が終わったら、レコードソースを元に戻す
・UPDATE〜 を使用しないで、フォームのレコードセットに対しループ処理
等の方が接続数を減らすという意味で、良いと思います。

そもそもFileMaker と Access は違うものであり、当然GUIも違います。
それらしく 見せる事はできるかも知れませんし、できないかも知れません。
少なくとも、全く同じにする事は無理だと思います。
 
少なくとも、当方は FileMaker を知りませんから、具体的な GUI をどうするかは全く判りません。
 
 

引用:
完全再現はできなかったのですが、４から６を一緒に処理するのが理想かもです。
５の必要がなく、検索結果が表示されれば、良いです。
また、ボタン一つで検索結果の反対（False）レコードの表示やフィルターのリセット（レコードソースの設定？）もしたいです。

引用:
抽出条件 を指定し、抽出結果を表示、更にその抽出結果に対し、表示するレコードを「選択」し画面に表示する

Suzu さんの引用:
そもそもFileMaker と Access は違うものであり、当然GUIも違います。
それらしく 見せる事はできるかも知れませんし、できないかも知れません。
少なくとも、全く同じにする事は無理だと思います。
少なくとも、当方は FileMaker を知りませんから、具体的な GUI をどうするかは全く判りません。
5の必要が無い？？
抽出条件 を指定し、抽出結果を表示、更にその抽出結果に対し、表示するレコードを「選択」し
画面に表示するのではなかったのでしょうか？
それなのに、その「選択」が必要ないのですか？

引用:
当方は 大まかな処理の流れを提示させて頂いただけであり、
希望とそぐわない部分があれば、希望の動作になる様に、修正すれば良いです。
おおまかな流れについての当方の認識は、

引用:
抽出条件 を指定し、抽出結果を表示、更にその抽出結果に対し、表示するレコードを「選択」し画面に表示する

違うのであれば、どう動かしたいのか説明くさい。質問者さんの理想が、どうあるのか当方には判りません。
当方は、処理を行うための大まかな流れや、部分的なコードは提示するかもしれませんが
希望の動作そのものをする全体コードは提示しませんので、ご承知ください。

引用:
見た目は少なくとも同じ感じ。処理は同じように処理できれば大丈夫です。

引用:
帳票フォームで全件100件表示状態から、検索用フォームを使い、偶数を抽出（検索）する。

引用:
2,4,6,...と偶数50件を帳票フォームに表示する。

引用:
50件表示状態から再抽出しても、全件から再抽出できるように。

引用:
少し別件なのですが、
ここの即効テクニック→Access一般機能→データ操作→他のテーブルのデータを直接参照する
にあるDlookUp関数をコントロールソースにしたデータはフィルター設定にできないですか？
=DLookUp("[ローカル用.表示]","[ローカル用]","[ローカル用].[ID]=[サーバー].[ID]")
を帳票フォームに配置して、これをフィルターかけれたら、解決するのではと思っています。

引用:
1.帳票フォームで全件100件表示状態から、検索用フォームを使い、偶数を抽出（検索）する。
「検索用フォーム」にて 抽出条件を指定 これは判ります
　　念のため・・ これは、抽出条件のみを入れる、非連結単票フォームですよね？

引用:
3.50件表示状態から再抽出しても、全件から再抽出できるように。
？？？ 　2.で、50件は表示されているのですよね？ 同じレコードを表示する？
　　　　2. と何が違うのでしょうか？
　　　　　　抽出条件が変わるのですか？
　　　　　　表示するフォームが変わるのですか？

引用:
抽出したい 値を持つコントロールを選択し、手動で、抽出が適用できれば
Filter で出来るでしょう。

引用:
帳票フォームをコピーしてコントロールを非連結にしている"非連結帳票フォーム"にしてます。
メニュー→表示フォーム→検索フォーム→表示フォームです。
また、"非連結単票フォーム"タイプのものもあります。
こちらは、メニュー→検索フォーム→表示フォームで使っています。

引用:
もしかして、設定を間違っているだけで、常に全件から抽出できるんですかね？(表示されているレコードから抽出されるものだと思ってました。)

    Dim strWhere As String
    strWhere = Forms![フォーム].Filter

　　'フィルタープロパティーが適用済みか判断
    If Len(strWhere) > 0 AND Forms![フォーム].FilterOn = True Then
      'フィルター適用済み
      '既存のフィルターに【 区分2="いい" 】を追加
      Forms![フォーム].Filter = Forms![フォーム].Filter & " And 区分2=""いい"""
　　Else
      'フィルター適用なし
      'フィルターに【 区分2="いい" 】を渡す
      Forms![フォーム].Filter = "区分2=""いい"""
　　End If
    Forms![フォーム].FilterOn = True

引用:
抽出条件を入力させるフォームが 検索フォームなのですね。
　（非連結 の 帳票フォーム は 作成できません。
　　非連結にした段階で単票になるはずです。）

引用:
フィルター適用済みのフォームに対し

引用:
　　MSGBOX Forms![フォーム].Filter

とでもして
Filterの内容を確認しましょう。
保存した クエリの SQL の WHERE句 以降と同じはずです。
先のコードでも示しましたが、
変数 = Forms![フォーム].Filter とでもすれば、Filter の文字列を退避できます。
必要な時に、
Forms![フォーム].Filter = 変数
と戻せばFilterの抽出を再現できます。

引用:
質問者さんは、Filter の処理の 認識が違うので

引用:
3.50件表示状態から再抽出しても、全件から再抽出できるように。

この動作が必要と感じたのでしょうが、
そもそも、全件からの抽出になるので、処理自体必要無いと言う事で良いでしょうか？

引用:

-----------------------------------------------------------------------------------
VBA は、手動操作 を 自動化します。
手動で操作を行っている事を 楽にする為　
或いは、
ユーザーインターフェイスとして、ボタンやテキストボタンを配置しユーザー操作の簡易化を図ります。
ですから、Accessにどんな機能があるか 動作がどうなるか を知ったうえで使った方が良いです。
また、手動できちんと動作する事を確認し、
その上で、VBAでどう自動化するかを考えましょう。
一般的には、一般機能を知った上で、VBAを使い操作します。
対し、 質問者 さん は 一般機能 についての 理解が不足している様に思います。
回答者としては
コードでこの機能を使っているのであれば、この辺りは理解しているだろうと 推測する部分について
質問者の 理解が 不十分であったり、間違っている事で　表現に対し認識の齟齬が発生している状況です。
手動で、操作し動作する事を確認しましょう。

質問者さんの 希望の動作が出来た様で何よりです。
 
 

引用:
検索用テーブルを作り、それと連結させていました！
そのフィールドの値を変数に持たせて、検索ワードで使っています。

引用:
この辺を参考になんとか形にできました。
フィルターが働いていなかった原因は、別のところで違うレコードソースを設定していたからみたいです。

引用:
フィルターの設定の仕方が悪かったものだと思われます！なんとかなりました！

Suzu さんの引用:

結局、勘違いや、設定違い ですか・・ 今までの 時間は・・
それも、結局は 気付けなかった自分自身も悪いのですが・・
SQL JOIN に別テーブルを指定し、その別テーブルに抽出条件となるキーワードを設定
確かに、在りますね
上記を採ると、一致条件が完全一致になり ユーザー目線で使いたいと思える、
【フィールドの内容の一部に 指定したキーワードが含まれいる部分一致の抽出】
に不向きであり、思考の枠外においていました。
とりあえず、今回の質問に関しては解決された様でなによりです。

マルチユーザーによる使用について VBAで作成するのは 難易度として高い部類です。
 
失礼とは思いますが、質問者の方はVBAコーディングのスキルはお持ちの様ですが
抽出についての考え方に現れている様に Accessの機能 への 習熟が不足していて、
容易な手法があるにも関わらず煩雑な手法を採用し VBAコーディングになっている様に拝見します。
 
既存のFileMakerシステムを Accessへ移植させる それが会社(上司)の意思とは拝聴しましたが
既存のモノを移植するのに、1年以上掛けているのであれば、会社としては
質問者の方に、VBA云々もでしょうが、Accessのスキル習得も期待しているのではないでしょうか？
 
色々と齟齬が出て把握しきれていないとの事ですが
状況の把握を行い、移行進捗・問題点を含め、上司の方と相談された方が良いと思います。

Suzu さんの引用:
マルチユーザーによる使用について VBAで作成するのは 難易度として高い部類です。
 
失礼とは思いますが、質問者の方はVBAコーディングのスキルはお持ちの様ですが
抽出についての考え方に現れている様に Accessの機能 への 習熟が不足していて、
容易な手法があるにも関わらず煩雑な手法を採用し VBAコーディングになっている様に拝見します。
 
既存のFileMakerシステムを Accessへ移植させる それが会社(上司)の意思とは拝聴しましたが
既存のモノを移植するのに、1年以上掛けているのであれば、会社としては
質問者の方に、VBA云々もでしょうが、Accessのスキル習得も期待しているのではないでしょうか？
 
色々と齟齬が出て把握しきれていないとの事ですが
状況の把握を行い、移行進捗・問題点を含め、上司の方と相談された方が良いと思います。

引用:
調べながらでしたので、拾ってきた情報をそのまま流用して、帳尻を合わせて行き当たりばったりに作っていた感じです。なので、いろいろ支障をきたしています。

リレーショナル・データベース・マネージメント・システム(RDMS)をどこまで理解されてますか。また、内部でどんな手法で管理されているか理解していますか。データベースとは膨大なデータを蓄積して、必要なデータを素早く取り出せなければなりません。
 
 
例えば、自宅・本屋・図書館などで書籍を手に取ったとします。その書籍で〇〇の記述を知りたい場合、どんな方法が考えられますか。先頭ページから最終ベージまで〇〇を片っ端から探していたら非現実なことは理解できると思います。ではどんな方法なら今知りたいその情報が書かれているページにたどり着けますか。
 
書籍は一般的に
・目次
・本文
・検引
で構成されています。さらに書籍はページ番号が重複なしの連番が振られています。そして、検引には用語とその記載ページが用語順に並んでいます。読者はその情報を手がかりに、数秒で目的のページにたどり着けます。
 
 
話を戻します。約13万件の情報を素早く取り出すには、どんな内部構造にすれば良いのでしょう。もちろん、情報は追加され、約14万件にもなるでしょう。そんなときでも目的の情報にすぐに取得できないと話になりません。
 
データベースは主キーがあり、インデックスがあります。そのインデックスが書籍でいう検引です。そしてページ番号ですが、実際ににはページ番号ではなく、アドレス(情報の場所)です。つまり、accdbファイルの先頭から何バイト目に実データが記録されているかです。
主キー・インデックスはインデックスはソートされれ主キーを指定すると最短で情報を取り出せます。このことから主キーの重要性が理解できると思います。
 
さて、レコードを追加した際、内部でどんな処理が必要でしょうか。書籍を例にすると、情報はページに追加することになります。そのページに余白があれば、空き余白に情報を追加します。その後、インデックス情報を更新します。
ページに空きスペースが足りなかったらどうなるのでしょう。たとえば、13ページに情報を追加したいけど、空きが無い場合です。このときは、13.5ページを追加して、13ページの情報の半分を13.5ページに移動。これで13ページ・13.5ページに空きスペースが出来るので、次回のレコード追加に対応出来ます。
 
このとき、重要なのが追加した13.5ページの実際の情報はaccdbファイルのどこかにあれば良い。つまり、ソートする必要はない。ソートするのはインデックスだけです。つまり、実情報はデータベース内部ではバラバラの位置に記録されています。
 
 
さて、ここまでは、Accsessが自動でやってくれます。なので本来知る必要はありません。
 
更新が一人たけならね。
 

データ更新ですが、言い換えれば、accdbファイルの書き換えです。
 
つまり、accdbファイルは自身のパソコンのローカルにあり、自分のパソコン以外からは書き換え出来ません。つまり、書き換えるのは自身のパソコンだけです。実際の処理はAccsessが行います。
 
マルチユーザーでは、accdbファイルを別のパソコンからアクセスできる状態にしますよね。この時点でどのパソコンでも更新(書き換え)出来ます。
 
さて、自身のパソコンでデータ更新をします。このとき、別のパソコンでもデータ更新をしているかも知れません。さきほどの解説で実情報はページに、その後インデックス更新の話をしました。このとき、同時に同じデータを数台のパソコンから書き換えたら、どうなるのでしょう。
 
なんか、すごく、キケンだと、思いませんか。
 
もちろん、Accsesは一応対応しているはずです。Windowsにはファイルはロックされます。Accsess自身も他で処理中でない上で処理していることでしょう。しかし、言い換えれば、それしかありません。
 
 
 
話は変わって新幹線のチケット予約。今では、みどりの窓口以外にも、自身のパソコンでも予約可能です。新幹線の席って、一人しか座れません。一つの席は一人にしか販売出来ません。(当たり前)
 
当然、データベースが使われているわけですが、ある席を今、2台のパソコンから同時に予約したらどうなるのでしょう。当然、片方は予約完了。もう片方は予約不可です。ダブルブッキングとか予約されてなかったとか、聞いたこと無い。
 
これはパソコンから予約しても、JRのサーバーに情報を送っているだけで、実際の処理はサーバーが行っています。なので処理が重なったときは片方は待ちの状態です。
 
マルチユーザーの場合、本来サーバーが必要です。サーバーなら、同時に書き換えても、実際の処理はサーバーが行うので、問題ありません。データ破損は起きません。
 
 
Accsessって本来シングルマザー向けです。一人なら同時に書き換えがありませんから。
また、同時書き換えの頻度が低いならサーバー無くても実用では問題発生の可能性は低いです。
 
 
 
なお、こういった知識は、リレーショナル・データベース・マネージメント・システムの書籍に書かれています
マルチユーザー向けの処理では、基礎知識として必要なことだと思います。
 
そういった書籍を読むことをおすすめします。
 

Suzu さんの引用:

質問者さんの 他の業務や、システムとしての進捗も判りかねますので
当方から言える事としては、
 このままの進め方で進めたとき、その成果物がいつ頃になりそうか 見通しを含め 上司 に相談
でしょうか。
今更 ではあるかもしれませんが、
・Accessを選んだ理由
・求める機能
　　 (単純に、FileMakerでしている事をそのまま出来る ではなく もっと具体的な 処理内容)
・質問者さんが 開発を担当する理由(外に出さない理由、質問者さんが開発する事で何を期待するのか)
　：
 単に、やらされれている から では なく、上司の方と相談してみてはどうでしょうか。

MMYS さんの引用:
なお、こういった知識は、リレーショナル・データベース・マネージメント・システムの書籍に書かれています
マルチユーザー向けの処理では、基礎知識として必要なことだと思います。
そういった書籍を読むことをおすすめします。

引用:
具体的には、週一で週の進捗、月一で月の進捗を報告しています。
併せて、予定表も作成しています。（このフォーム一式はいつまでといった形で）

引用:
※このフィルターやマルチーユーザー使用関連で進んでいないため、数か月分の遅れが発生しています。

Suzu さんの引用:
元々の計画は、どなたかが作成されたモノを質問者さんが 押し付けられたモノですよね。
質問者さんの見通しはどうなっっていますか？ いつ 終わる予定でしょうか？
○○遅れです ではなく、 いつまで掛かるか？ の見通しを出しましょう。
また、それが発生した要因は何でしょうか？ 工程内に同じ様な事で 遅れが生じる工程はありませんか？
数か月の遅れを自分一人で 一瞬で取り戻す事は不可能です。
ではどうするか、予定を見直すか、工数を投入するか。工数を投入する見通しは無いですよね？
であれば、予定を見直す必要があるのではありませんか？

引用:
今後、他のAccess とも連携するなら、
他のAccess の機能であったり、を理解する必要があります。
仕様書等も無いのであれば、自分でその機能を 調査する必要があります。
調査には、一般機能の内容が多く含まれているのではありませんか？
トラブル対応で、その 他のAccessシステムのメンテナンスを行う場面が来て
対応できる スキルを求められていて、そのスキルアップも目的のはずなのに、
今回、コードゴリゴリで対応して、目的が達せられるのでしょうか？

引用:
・遅れに対しての原因と対策
　ここは、スキルが無いと、原因も対策も出せないと思うので、無くても良いでしょう。

引用:
お勧めの本と言っても、スキル次第です。
本屋でパラっとめくって、半分くらい知らなかった事が載っていたら 購入しても良いでしょう。
まるまるの一からなのであれば、講習を受けるのも良いと思います。

Access を 社内研修で 実施する所は少ないと思います。
自分で講習を見つけて受ける様にしましょう。費用は会社に相談できませんか？
 
流れとしては
　・講習を受け、一般機能 の内容を知る
　・既に Access のシステムがあるなら、コード内容を覗いてみる
　　テーブルの作りや フォームの構成、ざっとで良いのでコードの流れを掴む
　　ここで、自分の知らない（覚えていない）書き方や機能を使っているでしょうから、
　　その辺りをメモするなり、頭の片隅に置き知識とする
　・開発する段階で こんな機能を実現させるのに、どんな機能を使っていたかを参考に
 
でしょうか。
 
開発時にコードを自分で組んだり、拾ったりしてその時には、判ったつもりでいても、時が経てば忘れます。
できればドキュメントとして残すに越した事はありませんが、そこまで時間が取れないのであれば
コード内にコメントを置くなりし、後で見たときに コードを読み解く手助けになる様にしておきましょう。
 
 
時間をとってでも、一般機能にどんな事があり、どんな使い方ができるのか は身に着けておきましょう

Suzu さんの引用:
Access を 社内研修で 実施する所は少ないと思います。
自分で講習を見つけて受ける様にしましょう。費用は会社に相談できませんか？
流れとしては
　・講習を受け、一般機能 の内容を知る
　・既に Access のシステムがあるなら、コード内容を覗いてみる
　　テーブルの作りや フォームの構成、ざっとで良いのでコードの流れを掴む
　　ここで、自分の知らない（覚えていない）書き方や機能を使っているでしょうから、
　　その辺りをメモするなり、頭の片隅に置き知識とする
　・開発する段階で こんな機能を実現させるのに、どんな機能を使っていたかを参考に
でしょうか。

引用:
開発時にコードを自分で組んだり、拾ったりしてその時には、判ったつもりでいても、時が経てば忘れます。
できればドキュメントとして残すに越した事はありませんが、そこまで時間が取れないのであれば
コード内にコメントを置くなりし、後で見たときに コードを読み解く手助けになる様にしておきましょう。
時間をとってでも、一般機能にどんな事があり、どんな使い方ができるのか は身に着けておきましょう

おーさん0729 さんの引用:
一般機能とは、「即効テクニック」にある「一般機能」のような内容を指してますか？

Suzu さんの引用:

おーさん0729 さんの引用:
一般機能とは、「即効テクニック」にある「一般機能」のような内容を指してますか？

 
そうですね。
 
追加で、テーブル設計の知識もあった方が良いでしょうね。
「Access テーブル設計」で WEB検索すれば ヒットします。

どんな経緯で競合が発生しているか判りませんが
競合が発生した状態で、VBAでレコードの強制保存を行う危険性を理解していますか？
  
場当たり的な処置で対応する事で データに齟齬が生じますよ？
  
  
元データ
FLD1 FLD2 FLD3
1 A い
  
User1 User2
--------------------　　　　　　----------------------
FLD1 FLD2 FLD3 FLD1 FLD2 FLD3
1 B い 1 A ろ
  
User1 の レコードを強制保存した場合 ↓　　【ろ】の変更は消える
  
FLD1 FLD2 FLD3 FLD1 FLD2 FLD3
1 B い 1 B い
  
-----------------------------------------------------------------------------------------------
　　　　　　　　　　　　　　　　場合によっては、ここでもデータが競合する旨が発生強制保存を行う
FLD1 FLD2 FLD3 FLD1 FLD2 FLD3
1 A ろ 1 A ろ
　　：
FLD1 FLD2 FLD3 FLD1 FLD2 FLD3
1 B い 1 B い
強制保存の連鎖の発生の可能性
  
これが、2人ではなく、3人 で FLD4 までのレコードだったら？
  
  
MMYS さんは JRの例を挙げていました。
レコードを、チケット情報だと考えてみてください。
  
FLD1：チケット番号(主キー)
FLD2：席番号
FLD3：チケット取得者
FLD4：取得者連絡先
  
FLD2、FLD3、FLD4 を 別々に更新し、強制保存を繰り返すと
どこの席の、誰のチケットなのか 変な状態のレコードが発生
仮に この途中で チケットの印刷がされたら・・？
FLD3 が い のとき、ろ のとき それぞれで印刷
　　席番号はそれぞれ 違う チケット・・　→ 席番号が重複している 取得者 がいる可能性
　　↓
　システムに依っては、席の一覧を持っていて、「い」 と 「ろ」で席が重複しているにも関わらず
　席の一覧では、どちらか あるいは 全く別の「は」の名前が載っている状態から、席が満席になりました。
当日、満席の状態で 「い」「ろ」は 「A席」「B席」のチケットを持って・・・
振替の利かない満席の状態で、「い」「ろ」はダブルブッキング・・・
 
　はい。見事不具合発生。
 
そんな 事も有りうるのですよ。
Accessは リレーショナルデータベースであり、（前後の）レコード毎に監視します。
 
今の FileMakerは判りませんが、昔はカード型のデータベースと言われるデータベースであり
レコード毎の監視ではなかったはず。
そんな経緯もあり、Accessと挙動は違う事もあり得るのでしょう。
 
 
何にしても、レコード毎の監視ベースなので
複数から更新された場合、Accessは 自動では保存せず、破棄されるのも ユーザーには悪いので
ダイアログを出し、警告・選択をさせるのですよ。
”競合がでてますよ。ユーザーさん選択してくださいね”って
 
それが、Accessの 連結フォームの良いところです。
 
  
#################################################################################
競合しても良く
上書きであり、.RecordsetClone.Update で 実施できなかったのであれば
　メッセージ発生を破棄
　　↓
 
　レコードセットなり、UPDATEステートメントで
　画面内コントロールの値を保存すれば良いです。
 
或いは、リレーショナルデータベース の特性から、フィールド毎の監視は
元々できませんので
 
テーブル構造を
----------------------------------
テーブル
Fid1、Fld2、Fld3、Fld4・・・
----------------------------------
 から
----------------------------------
テーブル1
Fid1(主キー)、Fld2
 
テーブル3
ID(主キー)、Fld1(外部連結 テーブル1.Fld1)、Fld3
 
テーブル4
ID2(主キー)、Fld1(外部連結 テーブル1.Fld1)、Fld4
----------------------------------
の様に、フィールド毎に分ける必要があるのです。
(これは以前のスレッドでも方法の一つとして挙がっています)
 
#################################################################################
 
何にしても、
・レコード/フィールド毎の更新 としたい
・帳票フォームで表示したい
 
上記を 両立させる為、
　VBA で更新するなら、競合については自前で 仕組みを作る必要があるのです。
 
 
それを、その理由も考えず、ダイアログが出る事が悪い と考え進めるのは
まさに 行き当たりばったりの帳尻合わせ でしかありません。
 
要因を考えずに、対処を行うのですから
検討が足りておらず 色々な部分で 意図しない事が起こって当然でしょう。
 
エラーが出ない様に
　何故エラーが出るのか、エラーが出る原因は何か、原因を回避する為にはどうすべきか
を考えましょう。
 
考える為には知識が必要であり、それを求めると言っておきながら
何故起きるかを考えず対処方法だけを求める姿勢は感心できませんよ。

今回のシステム開発を行うに当たり、 おーさん0729 さんの基礎知識が不足していると思います。とりあえず作れば良い。動けば良い。なんて考えていませんか。趣味であれば、それで問題ありません。なぜなら、
 
　　作る人 ＝ 使う人
 
だから。使うのは自分一人。何か問題あっても、誰にも迷惑かけない。困るのは自分だけ。
社内開発で、過去にも作成実績ありとのことですか、それはスタンドアロンではありませんか。スタンドアロンなら、そんな手法で開発しても問題起きませんので。
 
実務において重要なのが
・安定性
・パフォーマンス
・エラー耐性
などです。
 
下記の事例、なぜ起きるのか、技術的に説明できますか。原因が分からないと対策も出来ないですよね。
 
https://risingsun-system.biz/7-reasons-access-filemaker-migration/
 

引用:

1-3.Accessで苦労したこと
一方、Accessで苦労したのはデータ共有、そしてmdbファイルのもろさです
<中略>
半ば神頼みのようにファイルサーバでmdbフィアルを共有して運用したことがあるのですが、パフォーマンスは出ない、mdbファイルは頻繁に破損するといった事態が発生し、

Suzuさん

引用:
何にしても、
・レコード/フィールド毎の更新 としたい
・帳票フォームで表示したい
上記を 両立させる為、
　VBA で更新するなら、競合については自前で 仕組みを作る必要があるのです。
それを、その理由も考えず、ダイアログが出る事が悪い と考え進めるのは
まさに 行き当たりばったりの帳尻合わせ でしかありません。
要因を考えずに、対処を行うのですから
検討が足りておらず 色々な部分で 意図しない事が起こって当然でしょう。
エラーが出ない様に
　何故エラーが出るのか、エラーが出る原因は何か、原因を回避する為にはどうすべきか
を考えましょう。
考える為には知識が必要であり、それを求めると言っておきながら
何故起きるかを考えず対処方法だけを求める姿勢は感心できませんよ。

引用:
今回のシステム開発を行うに当たり、 おーさん0729 さんの基礎知識が不足していると思います。とりあえず作れば良い。動けば良い。なんて考えていませんか。趣味であれば、それで問題ありません。なぜなら、作る人 ＝ 使う人 だから。使うのは自分一人。何か問題あっても、誰にも迷惑かけない。困るのは自分だけ。
社内開発で、過去にも作成実績ありとのことですか、それはスタンドアロンではありませんか。スタンドアロンなら、そんな手法で開発しても問題起きませんので。

引用:
下記の事例、なぜ起きるのか、技術的に説明できますか。原因が分からないと対策も出来ないですよね。
https://risingsun-system.biz/7-reasons-access-filemaker-migration/

引用:
2-2.Delphi+Oracleのプロジェクトを失敗…
例えばFileMakerでは、CTRL+Fのショートカットで検索モードに入り、自分の好きな条件で、如何様な条件でも検索を実行することができます。
しかし一般的に、我々プログラマがソフトウェア開発する場合は、まず最初に「どのような検索パターンがあるか？」「どのような検索要件があるか？」を洗い出し、それを検索機能として実装します。
このような「一般論」をお話した上で、エンドユーザさんにヒヤリングしても「どんな条件でも検索できるようにして欲しい」「FileMakerではどんな条件でも検索できる。」「なぜ高い金を払ってシステムを開発するのに、今よりも不便になるのか？」
…といった、エンドユーザさんからの目線では至極まともな、しかしプログラマサイドからすると至極理不尽な要求が次々につきつけられます。
それ以外にも、お客様に必要な情報は全て画面上に表示して欲しい。フォントサイズは小さくなるが、拡大ボタンを押せばその部分だけを拡大できるような機能を実装して欲しいという要求がありました。
FileMakerには、レイアウトの左下にウインドウを拡大・縮小できる拡大ボタンが標準で実装されています。今で言うところのピンチイン・ピンチアウトの機能が標準で実装されているのです。
その機能を便利に使っていたエンドユーザさんは、当然新システムにも同等の機能実装を求めてきます。

引用:
社内で運用段階で、おーさん0729 さんが自信をもって、「ファイルが壊れたりはしません」と言えなければなりません。もちろん、技術的根拠を持ってです。
過去のレスに「FileMakerから変えたい理由として、更新やサーバー等の費用面」とありますが、なぜ、サーバーが必要なのか理由の説明は出来ますか。

引用:
また、
・排他処理
・共有ロック、専有ロック
・トランザクション
・例外処理
など、当然理解してますよね。
エラー発生・更新失敗時は、ユーザーにその旨表示。データ・ベースを更新前の状態に戻す。データベースは壊さないようにしなければならない。実務なら当たり前です。実装してますよね。

引用:
テーブル設計ですが、すでに終了。プログラム実装の段階ですよね。当然、
・概念モデル/論理モデル/物理モデル
・ER図
・テーブル定義書
・CRUD図
・PK
・FK
・インデックス
など理解し、必要なドキュメントも作成済みですよね。そのドキュメントを元に実装に入っているはずですが、その認識でよろしいですか。

引用:
外注、もしくは現在使用しているFileMakerの延命の方向で考えてみます。

引用:
今まで先伸ばしにしていただけで、自分自身がプログラミングに向いていないことがよくわかりました。趣味の範囲内か自分の業務の効率化くらいにとどめておくべきでした。

Suzu さんの引用:
別の機能を実装するならば、ユーザーインターフェイスを変えても言い訳はたつのでしょうが、機能そのままで ユーザーインターフェイスを変えただけの場合、
どうしても、既存システムと比較されます。
開発側からしたら、それは難しい と判っていても
ユーザー側からしたら、関係ない事です。
まさに今回のはそれに当たる事案であり、開発者泣かせの事案でしょう。

引用:
Accessの機能について知識が不十分であるにも関わらず
ここまで進められたのは、とても素晴らしく、プログラミングに向いていないとは思えません。
Accessの開発ではなく、メンテナンスから入り、Accessの仕組みを知りえた上で
今回の開発であれば、今よりは容易に進める事が出来たと思います。
そういう意味では、理不尽だなと思います。
今回の件は、新しい事への取り組み時の進め方の教訓にしてください。

そもそも、目的は、
・運用では、FileMakerを使っている。運用は変えたくない。
・社内システムの一部がAccessで、将来的に連携させたい。
ですよね。また、サーバー等の費用面の削減も、このまま進めても期待した効果は低いと思います。(逆に足が出る可能性が高いと思う)
 
上記が目的なら、私だったら直接、FileMaker Serverからデータを取得を考えます。FileMaker Serverから直接、最新データを取得できれば、社内のAccessの社内システムと連携できますよね。その辺は検討されたのですか。
 
FileMakerは、メーカーから、ODBCドライバ が用意されています。つまり、AccsessVBA・Excel-VBAなどから、直接、FileMaker Server のデータを取得できるはずです。調べた限りでは、コード自体は、標準的な手法で、他のデータベース(SQL-Server・Oracleなど)からのデータ取得と同じです。
 

おーさん0729 さんの引用:

一般的にどうなのかはわかりませんが、わからないところで詰まったときは業務外で解決先を試行錯誤し、実務は業務中にするように言われます。業務の効率化と言われればそれまでかもしれませんが...

MMYS さんの引用:
そもそも、目的は、
・運用では、FileMakerを使っている。運用は変えたくない。
・社内システムの一部がAccessで、将来的に連携させたい。
ですよね。また、サーバー等の費用面の削減も、このまま進めても期待した効果は低いと思います。(逆に足が出る可能性が高いと思う)
上記が目的なら、私だったら直接、FileMaker Serverからデータを取得を考えます。FileMaker Serverから直接、最新データを取得できれば、社内のAccessの社内システムと連携できますよね。その辺は検討されたのですか。
FileMakerは、メーカーから、ODBCドライバ が用意されています。つまり、AccsessVBA・Excel-VBAなどから、直接、FileMaker Server のデータを取得できるはずです。調べた限りでは、コード自体は、標準的な手法で、他のデータベース(SQL-Server・Oracleなど)からのデータ取得と同じです。

引用:
想定外はよくあることです。それは業務内で行うのが普通です。ただし、原因が推測出来て、その解決手法を知りたいケースです。基礎知識・動作原理を理解してれば、原因は推測出来ますので。
日常で、5分とか10分とかの短時間の空き時間ってありますよね。そういう空き時間に、さっと読む。それを毎日繰り返す。それを繰り返せば、どんどん知識が溜まっていきます。

ありがとうございました。