マルチユーザーアクセス用のMS-Access DBのセットアップ
複数のユーザー用のいくつかのテーブル、フォーム、クエリを備えた小さなMS-Access DBを「成長」させることを考えています。 （別のバックエンドを使用することも別の方法ですが、残念ながら現在は受け入れられない長期的なオプションです。）
ほとんどのユーザーは読み取り専用になりますが、変更を行う必要のあるユーザー（現在1〜2人）がいます（読み取り専用ユーザーもDBを使用しています）。セキュリティの側面についてはそれほど心配していませんが、次の問題のいくつかについてはもっと心配しています。
- 他のユーザーがデータを使用している間に、書き込みユーザーがテーブルデータを変更できるようにするにはどうすればよいですか？読み取りユーザーはテーブルにロックをかけますか？書き込みユーザーはテーブルにロックをかける必要がありますか？ Accessはこれを行うのですか、それとも明示的にコーディングする必要がありますか？
- 「MS Accessトランザクション」に注意すべき一般的な問題はありますか？
- 使用中のフォーム、クエリなどで作業できますか？ユーザーの邪魔にならずに、どのように「プログラム」できますか？
- MS Accessのどの設定が物事の処理方法に影響しますか？
- 私たちのバックグラウンドは主にOracleにありますが、Accessは複数のユーザーの処理でどこが違うのですか？ Accessに「分離レベル」などはありますか？
役に立つ記事へのヒントやポインタは大歓迎です。
この質問に対する答えは、問題があり、混乱を招き、不完全であることがわかりました。そのため、私はより良い努力をするつもりです。
Q1：他のユーザーがデータを使用している間に、書き込みユーザーがテーブルデータを変更できるようにするにはどうすればよいですか？読み取りユーザーはテーブルにロックをかけますか？書き込みユーザーはテーブルにロックをかける必要がありますか？ Accessはこれを行うのですか、それとも明示的にコーディングする必要がありますか？
完全な方法でこれに実際に答えた人はいません。 Accessオプションでのロックの設定に関する情報は、読み取りロックと書き込みロックとは関係ありません。ロックなし対すべてのレコード対編集済みレコードは、WRITESのデフォルトのレコードロックを設定する方法です。
ロックなしは、OPTIMISTICロックを使用していることを意味します。つまり、複数のユーザーがレコードを編集できるようにし、その後、編集を開始してからレコードが変更されたかどうかを通知します。楽観的ロックは、それを実装するためのコーディングを必要とせず、小さなユーザー集団にとって問題を引き起こすことはほとんどないため、最初からすべきです。
すべてのレコードは、編集が開始されるたびにテーブル全体がロックされることを意味します。
編集済みレコードとは、ロックされるレコードが少ないことを意味しますが、単一のレコードであるか複数のレコードであるかは、データベースがレコードレベルのロック（Jet 4で最初に追加）またはページレベルのロックを使用するように設定されているかどうかによって決まります。率直に言って、楽観的なロックがほとんどの問題を処理するので、レコードレベルのロックを設定するのが面倒だとは思っていませんでした。
レコードレベルのペシミスティックロックを使用したいと考える人もいるかもしれませんが、ほとんどのアプリでは、2人のユーザーが同じレコードを編集することはほとんどありません。今、明らかに、特定の種類のアプリはそれの例外かもしれませんが、そのようなアプリに出くわした場合、スキーマを再設計して、2人のユーザーが同じを編集することは非常にまれになるように、おそらくそれを設計し直そうとしますレコード（通常、既存のデータを編集するのではなく、レコードを追加することで変更が行われる、代わりに何らかの形式のトランザクション編集に移動します）。
さて、実際の質問には、一部のユーザーを読み取り専用に制限し、他のユーザーに書き込み権限を付与する方法がいくつかあります。 Jetのユーザーレベルのセキュリティは、この目的のためのものであり、用語の意味のある定義に対する「セキュリティ」である限り、正常に機能します。一般的に、Jet/ACEデータストアを使用している限り、取得する最高のセキュリティはJet ULSによって提供されるものです。はい、それはクラック可能ですが、あなたのユーザーはそれを壊すことによって、もみの犯罪を犯すので、それで十分かもしれません。
私はJet ULSをまったく実装せず、代わりに、ユーザーのWindowsログオンを確認し、どのユーザーがどのアクセスを取得するかに応じてフォームを読み取り専用または書き込み可能にするようにデータ編集フォームを設計する傾向があります。グループメンバーシップをデータテーブルに記録するか、この目的のためにWindowsセキュリティグループを維持するかはユーザー次第です。 Jetワークグループファイルを使用して処理し、書き込みユーザーに別のsystem.mdwファイルを提供することもできます。読み取り専用ユーザーは管理者として透過的にログオンし、管理者としてログオンしたユーザーには読み取り専用アクセスのみが許可されます。書き込みユーザーは、他のユーザー名として（透過的に、アプリを起動するために提供するショートカットで、パスワードを指定せずに）ログオンし、フォームを読み取りまたは書き込みとして設定するために使用されます。
Jet ULSを使用している場合、正しく機能させるのは非常に困難になります。これには、すべてのテーブルを読み取り専用としてロックダウンし（または、そうでない場合もある）、RWOPクエリを使用してデータへのアクセスを提供することが含まれます。 14年間のプロフェッショナルなAccess開発で、このようなアプリを1つだけ実行しました。
あなたの質問の部分に対する私の答えを要約するには：
他のユーザーがデータを使用している間に、書き込みユーザーがテーブルデータを変更できるようにするにはどうすればよいですか？
アプリケーションでこれを実行し、ユーザーのログオンに応じて実行時にフォームを読み取り専用または編集可能に設定することをお勧めします。最も簡単な方法は、フォームを読み取り専用に設定し、書き込みユーザーがフォームを開いたときに編集可能に変更することです。
読み取りユーザーはテーブルにロックをかけますか？
意味のある意味ではありません。 Jet/ACEには読み取りロックがありますが、個々のビューの状態を維持し、ユーザーのデータを更新するためにのみ存在します。それらは、いかなる種類の書き込み操作もロックアウトしませんが、それらを追跡するオーバーヘッドは理論的に物事を遅くします。心配するだけでは十分ではありません。
書き込みユーザーはテーブルにロックをかける必要がありますか？
特にデフォルトとしてオプティミスティックロックを選択した場合は、Jet/ACEと組み合わせてAccessがこれを自動的に行います。ここで重要な点は、Accessアプリはデータバインドされているため、フォームが読み込まれるとすぐにレコードに読み取りロックが設定され、レコードが編集されるとすぐに、他のユーザーに対して書き込みロックされるかどうかが決定されることです楽観的または悲観的ロックを使用しているかどうか。繰り返しになりますが、これはAccessがバインドされたフォームでのデフォルトの動作であなたの面倒を見るようなものです。問題が発生するまでは、心配する必要はありません。
Accessはこれを行うのですか、それとも明示的にコーディングする必要がありますか？
基本的に、実行時に編集可能性を設定する（書き込みアクセス権を持つユーザーに応じて）以外に、楽観的ロックを使用している場合はコーディングは不要です。悲観的ロックを使用すると、コードにhaveはありませんが、ほとんどの場合必要になります。デフォルトの動作とエラーメッセージ。
Q2：「MS Accessトランザクション」に注意する必要がある一般的な問題はありますか？
Jet/ACEはコミット/ロールバックトランザクションをサポートしていますが、それがこの質問で意味するものかどうかは明確ではありません。一般的に、請求書の作成時、または複数のテーブルを含む更新の実行時など、原子性を維持する以外はトランザクションを使用しません。期待どおりに機能しますが、Accessアプリケーションの大部分の操作には実際には必要ありません。
おそらくここでの問題の1つは（特に最初の質問に照らして）、Accessがフォームにバインドされたデータを使用してアプリを作成するために設計されていることを十分に理解できないことです。 「トランザクション」は、バインドされていないステートレスアプリ（ブラウザーベースなど）にとって非常に重要なトピックですが、データバインドアプリの場合、編集と保存はすべて透過的に行われます。
特定の種類の操作では、これは問題になる可能性があり、バインドされていないフォームを使用してAccessでデータを編集することが適切な場合があります。しかし、私の経験では、それはめったにありません。バインドされていないフォームを使用しないということではありません-ダイアログなどに多くのフォームを使用しています-私のアプリがedit非バインドフォームを含むデータテーブル。ほとんど例外なく、すべてのアプリはバインドされたフォームでデータを編集します。
現在、非バインドフォームはAccessで実際に実装するのがかなり簡単です（特に、編集コントロールに基本フィールドと同じ名前を付ける場合）。ただし、非バインドデータ編集フォームを使用すると、Accessを使用する意味がありません。すべてあなたのためにやった。また、バインドを解除することの主な欠点は、OnInsert、BeforeUpdateなど、すべてのレコードレベルのフォームイベントが失われることです。
Q3。使用中のフォーム、クエリなどで作業できますか？ユーザーの邪魔にならずに、どのように「プログラム」できますか？
これは、適切に対処された質問の1つです。すべてのマルチユーザーアプリまたはレプリケートされたAccessアプリを分割する必要があり、ほとんどのシングルユーザーアプリも分割する必要があります。優れた設計であり、データテーブルのみが一度に複数のユーザーによって開かれるため、アプリの安定性も向上します。
Q4。 MS Accessのどの設定が物事の処理方法に影響しますか？
「もの？」どんな物？
Q5。私たちのバックグラウンドは主にOracleにありますが、Accessは複数のユーザーの処理でどこが違うのですか？ Accessに「分離レベル」などはありますか？
私はOracleについて具体的には何も知りません（私のクライアントは誰も望んでもそれを買えません）。
アクセスは、アプリケーション開発ツールです。
Oracleは、産業用強度のデータベースサーバーです。
リンゴとオレンジ。
もちろん、AccessにはデフォルトでJetと呼ばれるデフォルトのデータベースエンジンが同梱されていますが、今回はACEを改訂して名前を変更しましたが、Accessは開発プラットフォームをデフォルトのデータベースエンジンであるJet/ACEから完全に切り離すことができます。
この場合、Jet/ACEバックエンドを使用することを選択しました。これは、25歳未満の小さなユーザー人口に適している可能性があります。Jet/ ACEも最大50または100で、特に同時ユーザーのいくつかは書き込み許可を持っています。 Jet/ACEの255ユーザーの制限には読み取り専用ユーザーと書き込みユーザーの両方が含まれますが、サポートできる同時ユーザーの数を実際に制御するのは書き込みユーザーの数であり、場合によっては、ほとんど読み取りを持つアプリがあります-ユーザーのみであるため、バックエンドに問題のない優れたアプリを設計するのはそれほど難しくありません。
基本的に、Oracleのバックグラウンドが原因で、コードを記述せずに更新されるレコードソースにフォームをバインドすることが期待されるAccessでの開発方法を誤解する可能性が高いと思います。現在、効率のために、フォームをテーブル全体ではなくレコードのサブセットにバインドすることをお勧めしますが、データ編集フォームの背後にあるレコードソース内のテーブル全体であっても、AccessはJet /データテーブルに効率的にインデックスが作成されている限り、ACEテーブル（テーブル全体をワイヤに引き寄せるという古い神話はまだそこにあります）。
レコードのロックは、ほとんど心配する必要のないものであり、その理由の1つは、フォームがバックエンドで何が起こっているかを常に把握している（つまり、秒間隔、デフォルトの更新間隔）。つまり、データのコピーを取得し、元のデータ取得操作にまったく関係のないトランザクションでサーバーに編集内容をポストバックするWebページとは異なります。 Accessのようなバインドされた環境では、バックエンドデータファイルのロックファイルは、編集のためにレコードが開かれているという事実を常に追跡し続けます。これは、Accessが状態を認識してユーザーに通知するため、ユーザーの編集が他のユーザーの編集を踏みつけることを防ぎます。これはすべて、開発者側のコーディングなしで発生し、バインドされた編集モデルの大きな利点の1つです（編集をポストするためにコードを記述する必要がないことを除く）。
Accessに初めてアクセスする他のプラットフォームに精通している経験豊富なデータベースプログラマーは、Accessをエンドユーザーのように使用することを強くお勧めします。すべてのポイントを試して、機能をクリックします。フォームウィザードとレポートウィザードを実行し、それらが生成する結果を確認します。これらすべてを優れたプラクティスを実証するものとして保証することはできませんが、Accessの使用方法の背後にあるデフォルトの前提を明確に実証しています。
たくさんのコードを書いていることに気付いたら、おそらくAccessのポイントを逃しているでしょう。
最初に行うこと（まだ行っていない場合）は、データベースをフロントエンド（すべてのフォーム/レポートなどを含む）とバックエンド（すべてのデータを含む）に分割することです。 2つ目は、フロントエンドでバージョン管理を設定することです。
私の多くのデータベースでこれを行った方法は、ユーザーに小さな「ジャンパー」データベースを実行させてメインデータベースを開くことです。このジャンパーは次のことを行います
•ユーザーのCドライブにデータベースがあるかどうかを確認する
•インストールして実行しない場合
•もしそうなら、彼らが持っているバージョンを確認してください
•バージョン番号が一致しない場合は、最新バージョンをコピーしてください
•データベースを開く
通常、このチェックプロセス全体は0.5秒未満です。このモデルを使用すると、すべての開発を個別のデータベースで実行できます。「リリース」の準備ができたら、新しいmdeをネットワーク共有に配置し、次にユーザーがジャンパーを開くと、最新バージョンがコピーされます。
マルチユーザーデータベースには他にも考慮すべきことがあり、フォームをテーブル全体にバインドするなどの一般的な間違いをチェックする価値があるかもしれません。
データの書き込み中にAccessでテーブルまたはレコードのロックを使用できます。 [ツール]から[デフォルトレコードのロック]を制御できます。オプション|詳細設定タブ：
- ロックなし
- すべての記録
- 編集した記録
特定のニーズに応じて、フォームのレコードロックまたはDAO/ADOコードでこれを設定できます。
トランザクションは、正しく使用すれば問題になりません。
ベストプラクティス：テーブルを他のすべてのコードから分離します。各ユーザーにコードファイルの独自のコピーを提供し、ネットワークサーバーでデータファイルを共有します。コードの「テスト」コピー（およびテストデータファイルへのリンク）を作成し、ユーザーの個々のコードファイルを個別に更新します。データファイルの変更（テーブル、列などの追加）が必要な場合は、すべてのユーザーがアプリケーションから抜け出して変更を行う必要があります。
Oracleの比較については、他の回答をご覧ください。
あなたの場合、Accessが最良の選択だと思います。ただし、データベースを分割する必要があります： http://accessblog.net/2005/07/how-to-split-database-into-be-and-fe.html
•他のユーザーがデータを使用している間に、書き込みユーザーがテーブルデータを変更できるようにするにはどうすればよいですか？読み取りユーザーはテーブルにロックをかけますか？書き込みユーザーはテーブルにロックをかける必要がありますか？ Accessはこれを行うのですか、それとも明示的にコーディングする必要がありますか？
明示的に配置しない限り、読み取りロックはありません。 「ロックなし」を使用するだけです
「MS Accessトランザクション」に注意すべき一般的な問題はありますか？
1-2人の書き込みユーザーの問題ではないはずです
•使用中のフォーム、クエリなどに取り組むことはできますか？ユーザーの邪魔にならずに、どのように「プログラム」できますか？
データベースを分割した場合-FE設計で問題なく動作します。
•MS Accessのどの設定が物事の処理方法に影響しますか？
どういう意味ですか？
•私たちのバックグラウンドは主にOracleにありますが、複数のユーザーの処理でAccessはどこが違うのですか？ Accessに「分離レベル」などはありますか？
アクセスに分離レベルはありません。ところで、ユーザーが多く、大きなデータベースがある場合は、後でデータをOracleに移動してフロントエンドにアクセスできます。
Accessは優れたマルチユーザーデータベースです。マルチユーザーの状況を処理するための多くの機能が組み込まれています。実際、非常に人気のあるマルチユーザーデータベースです。更新と編集を同時に行うことができるユーザーの数には上限があります-開発者のアクセスに関する知識とデータベースの設計方法に応じて、20ユーザーから約50ユーザーまでです。一部のアクセスデータベースは、最大50人の同時ユーザーを処理するように構築できますが、他の多くのデータベースは、データベースを更新する20または25人の同時ユーザーを処理できます。これらの数値は、数年以上使用されているデータベースで観察されており、アクセスニュースグループで何度も議論されています。
データがRDBMSに保存されているクライアント/サーバーMicrosoft Accessアプリケーションを構築する正しい方法は、リンクテーブルメソッドを使用することです。これにより、Microsoft AccessクライアントアプリケーションとRDBMSデータ間でデータの分離と同時実行が維持され、メンテナンスがより困難になり、開発時間が増加する追加の不必要なプログラミングロジックとコードがなくなります。
参照： http://claysql.blogspot.com/2014/08/normal-0-false-false-false-en-us-x-none.html
アクセスデータベースをロックするためにVistaで導入されたSMB2プロトコルを見つけました。次のregeditによって無効にできます。
Windowsレジストリエディターバージョン5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters] "Smb2" = dword：00000000