この質問への答えは問題があり、混乱し、不完全であると思うので、私はより良いことをするように努力します。
Q1：他のユーザーがデータを使用しているときに、書き込みユーザーがテーブルデータに変更を加えることができるようにするにはどうすればよいですか？読み取りユーザーはテーブルにロックをかけますか？書き込みユーザーはテーブルにロックをかける必要がありますか？Accessはこれを実行しますか、それとも明示的にコーディングする必要がありますか？
完全な方法でこれに実際に答えた人は誰もいません。アクセスオプションでのロックの設定に関する情報は、読み取りロックと書き込みロックとは関係ありません。ロックなしvs.すべてのレコードvs.編集済みレコードは、WRITESのデフォルトのレコードロックを設定する方法です。
ロックがないということは、OPTIMISTICロックを使用していることを意味します。つまり、複数のユーザーがレコードを編集し、自分の編集を開始してからレコードが変更されたかどうかを事後に通知できます。楽観的ロックは、それを実装するためのコーディングを必要とせず、小規模なユーザー集団にとっては問題を引き起こすことはほとんどないため、最初から始める必要があります。
すべてのレコードは、編集が開始されるたびにテーブル全体がロックされることを意味します。
編集済みレコードとは、ロックされるレコードが少ないことを意味しますが、単一のレコードであるか複数のレコードであるかは、データベースがレコードレベルのロック（Jet 4で最初に追加）またはページレベルのロックを使用するように設定されているかどうかによって異なります。率直に言って、楽観的ロックがほとんどの問題を処理するので、レコードレベルのロックを設定するのに苦労する価値があるとは思っていませんでした。
レコードレベルの悲観的ロックを使用したいと思うかもしれませんが、実際のところ、ほとんどのアプリでは、2人のユーザーが同じレコードを編集することはほとんどありません。さて、明らかに、特定の種類のアプリはそれの例外かもしれませんが、私がそのようなアプリに遭遇した場合、2人のユーザーが同じものを編集することは非常にまれになるようにスキーマを再設計することによってそれを設計しようとするでしょうレコード（通常、既存のデータを編集するのではなく、レコードを追加することによって変更が行われる、代わりに何らかの形式のトランザクション編集に移動します）。
さて、実際の質問では、一部のユーザーを読み取り専用に制限し、他のユーザーに書き込み権限を付与する方法はいくつかあります。Jetユーザーレベルのセキュリティはこの目的を目的としており、用語の意味のある定義の「セキュリティ」である限り、正常に機能します。一般に、Jet / ACEデータストアを使用している限り、取得する最高のセキュリティはJetULSによって提供されるものです。それはクラック可能です、はい、しかしあなたのユーザーはそれを壊すことによって窮屈な犯罪を犯しているでしょう、それでそれで十分かもしれません。
私はJetULSをまったく実装せず、代わりにデータ編集フォームを設計して、ユーザーのWindowsログオンをチェックし、どのユーザーがどのアクセスを取得するかによって、フォームを読み取り専用または書き込み可能にする傾向があります。グループメンバーシップをデータテーブルに記録するか、この目的のためにWindowsセキュリティグループを維持するかは、あなた次第です。Jetワークグループファイルを使用してそれを処理し、書き込みユーザーに別のsystem.mdwファイルを提供することもできます。読み取り専用ユーザーはadminとして透過的にログオンし、adminとしてログオンしたユーザーには読み取り専用アクセスのみが許可されます。書き込みユーザーは、他のユーザー名としてログオンし（透過的に、アプリを起動するためにユーザーに提供するショートカットで、パスワードを指定しません）、フォームを読み取りまたは書き込みとして設定するために使用されます。
Jet ULSを使用する場合、それを正しく行うのは非常に困難になる可能性があります。これには、すべてのテーブルを読み取り専用（または読み取り専用ではない可能性があります）としてロックダウンし、RWOPクエリを使用してデータへのアクセスを提供することが含まれます。私はまだ行っていませんが、14年間のプロフェッショナルなAccess開発でそのようなアプリを1つ作成しました。
あなたの質問の部分に対する私の答えを要約すると：
他のユーザーがデータを使用しているときに、書き込みユーザーがテーブルデータに変更を加えることができるようにするにはどうすればよいですか？
アプリケーションでこれを行うことをお勧めします。ユーザーのログオンに応じて、実行時にフォームを読み取り/専用または編集可能に設定します。最も簡単な方法は、フォームを読み取り専用に設定し、書き込みユーザーがフォームを開いたときに編集可能に変更することです。
読み取りユーザーはテーブルにロックをかけますか？
意味のある意味ではありません。Jet / ACEには読み取りロックがありますが、読み取りロックは、個々のビューの状態を維持し、ユーザーのデータを更新するためにのみ存在します。それらを追跡するオーバーヘッドは理論的に物事を遅くしますが、それらはいかなる種類の書き込み操作もロックアウトしません。心配するだけでは十分ではありません。
書き込みユーザーはテーブルにロックをかける必要がありますか？
Jet / ACEと組み合わせたAccessは、特にデフォルトとして楽観的ロックを選択した場合に、これを自動的に行います。ここで重要なのは、Accessアプリはデータバインドされているため、フォームが読み込まれるとすぐにレコードに読み取りロックが設定され、レコードが編集されるとすぐに、他のユーザーに対して書き込みロックされるかどうかが次のように決定されます。楽観的または悲観的なロックを使用しているかどうか。繰り返しになりますが、これは、バインドされた形式でのデフォルトの動作でAccessが処理する種類のものです。問題が発生するまでは、心配する必要はありません。
Accessはこれを実行しますか、それとも明示的にコーディングする必要がありますか？
基本的に、実行時に編集可能性を設定する以外に（書き込みアクセス権を持つユーザーに応じて）、楽観的ロックを使用している場合はコーディングは必要ありません。ペシミスティックロックを使用すると、コーディングする必要はありませんが、デフォルトの動作とエラーメッセージでユーザーを動かないようにすることはできないため、ほとんどの場合、コーディングする必要があります。
Q2：「MSAccessトランザクション」に注意すべき一般的な問題はありますか？
Jet / ACEはコミット/ロールバックトランザクションをサポートしていますが、それがこの質問の意味であるかどうかは私にはわかりません。一般に、請求書を作成するときや、複数のテーブルを含む更新を行うときなど、原子性を維持することを除いて、トランザクションは使用しません。これは、期待どおりに機能しますが、Accessアプリケーションの大部分の操作には実際には必要ありません。
おそらく、ここでの問題の1つは（特に最初の質問に照らして）、Accessがフォームにバインドされたデータを使用してアプリを作成するために設計されていることを十分に理解していない可能性があることです。「トランザクション」は、バインドされていないステートレスアプリ（ブラウザベースなど）にとって非常に重要なトピックですが、データバインドされたアプリの場合、編集と保存はすべて透過的に行われます。
特定の種類の操作では、これが問題になる可能性があり、バインドされていないフォームを使用してAccessでデータを編集することが適切な場合があります。しかし、私の経験では、そうなることはめったにありません。バインドされていないフォームを使用しないわけではありません。ダイアログなどに多くのフォームを使用します。アプリがバインドされていないフォームでデータテーブルを編集しないだけです。ほとんど例外なく、すべてのアプリはバインドされたフォームでデータを編集します。
現在、バインドされていないフォームは実際にはAccessで実装するのはかなり簡単です（特に、編集コントロールに基になるフィールドと同じ名前を付ける場合）が、バインドされていないデータ編集フォームを使用することは、Accessを使用する意味がありません。すべてあなたのために行われます。また、バインド解除の主な欠点は、OnInsert、BeforeUpdateなどのすべてのレコードレベルのフォームイベントが失われることです。
Q3。フォームやクエリなどを使用しながら作業できますか？ユーザーの邪魔にならずに、どうすれば「プログラミング」できるでしょうか。
これは、よく取り上げられている質問の1つです。すべてのマルチユーザーまたはレプリケートされたAccessアプリを分割する必要があり、ほとんどのシングルユーザーアプリも分割する必要があります。データテーブルのみが一度に複数のユーザーによって開かれるため、これは優れた設計であり、アプリをより安定させます。
Q4。MS Accessのどの設定が、処理方法に影響を与えますか？
"もの？" どんな物？
Q5。私たちのバックグラウンドは主にOracleにありますが、Accessは複数のユーザーを処理する点でどこが違うのでしょうか。Accessに「分離レベル」などはありますか？
私はOracleについて具体的に何も知りませんが（私のクライアントは誰もそれを望んでいたとしてもそれを買う余裕はありませんでした）、AccessとOracleの比較を求めることは、どこかで根本的な誤解を裏切っています。
Accessはアプリケーション開発ツールです。
Oracleは、産業用の強力なデータベースサーバーです。
リンゴとオレンジ。
もちろん、Accessには元々Jetと呼ばれ、現在は改訂されてACEに名前が変更されたデフォルトのデータベースエンジンが付属していますが、Accessの開発プラットフォームをデフォルトのデータベースエンジンであるJet/ACEから完全に切り離すことができるレベルはたくさんあります。
この場合、Jet / ACEバックエンドを使用することを選択しました。これは、小規模なユーザー集団、つまり25歳未満の場合に問題ない可能性があります。Jet/ ACEは、特に同時ユーザーの中には書き込み権限を持っている人はほとんどいません。Jet / ACEの255ユーザーの制限には、読み取り専用ユーザーと書き込みユーザーの両方が含まれますが、サポートできる同時ユーザーの数を実際に制御するのは書き込みユーザーの数です。この場合、ほとんどが読み取りのアプリがあります。 -ユーザーのみなので、バックエンドに問題のない優れたアプリを設計することはそれほど難しいことではありません。
基本的に、Oracleのバックグラウンドにより、Accessでの開発方法を誤解している可能性があります。この場合、予想されるアプローチは、コードを記述せずに更新されるレコードソースにフォームをバインドすることです。効率を上げるために、フォームをテーブル全体ではなくレコードのサブセットにバインドすることをお勧めしますが、データ編集フォームの背後にあるレコードソースにテーブル全体がある場合でも、AccessはJet/の編集でかなり効率的になります。データテーブルが効率的にインデックス付けされている限り、ACEテーブル（テーブル全体をネットワーク上でプルするという古い神話はまだ存在します）。
レコードロックは、ほとんど心配する必要のないものです。その理由の1つは、フォームがバックエンドで何が起こっているかを常に（まあ、間隔を置いて）知っているバインドされた編集によるものです。 2番目に、デフォルトの更新間隔）。つまり、データのコピーを取得してから、元のデータ取得操作とはまったく関係のないトランザクションで編集内容をサーバーにポストバックするWebページとは異なります。Accessのようなバインドされた環境では、バックエンドデータファイルのロックファイルは、誰かが編集のためにレコードを開いているという事実を常に追跡します。これにより、Accessは状態を認識してユーザーに通知するため、ユーザーの編集が他のユーザーの編集を踏みにじることを防ぎます。
初めてAccessにアクセスする他のプラットフォームに精通している経験豊富なデータベースプログラマーのすべての人には、エンドユーザーのようにAccessを使用することを強くお勧めします。すべてのポイントアンドクリック機能を試してみてください。フォームウィザードとレポートウィザードを実行し、それらが生成する結果を確認します。グッドプラクティスを示すものとしてそれらすべてを保証することはできませんが、Accessが使用されることを意図した方法の背後にあるデフォルトの仮定を確実に示しています。
たくさんのコードを書いていることに気付いた場合は、Accessのポイントを見逃している可能性があります。