お世話になります。デフォルトの楽観的排他制御について教えて下さい。
Access は一応マルチユーザで利用できるが信用できない、ボロいと言われるようですが、
デフォルトの楽観的排他制御(競合した時にクリップボードに退避できたりするあれ)は、
信用してよさそうなのでしょうか。
特に自分で SQL を書いて、version number で実装する意味はあるのでしょうか。
工数を省ければ省きたく、よろしくお願い致します。
通報 ...
お世話になります。デフォルトの楽観的排他制御について教えて下さい。
Access は一応マルチユーザで利用できるが信用できない、ボロいと言われるようですが、
デフォルトの楽観的排他制御(競合した時にクリップボードに退避できたりするあれ)は、
信用してよさそうなのでしょうか。
特に自分で SQL を書いて、version number で実装する意味はあるのでしょうか。
工数を省ければ省きたく、よろしくお願い致します。
具体的にはどのように設定しているもののことでしょうか。
DAOあるいはADOでデータ操作しているときの話なのか、
フォームからデータ入力している話なのかとか。
もう少し具体的に説明してもらえますか。
[オプション]→[クライアントの設定]→[詳細設定]での設定のことかな?
私の場合は、デフォルトではなく下記のような設定で運用してますが、
フォームの「レコードロック」プロパティは「編集済みレコード」に設定。
有線LANで5名程度の同時使用でトラブったことはないです。
デフォルトでの場合は分かりません。
環境や運用状況によると思いますので参考までに。
直々のお出ましありがとうございます。
hatena 様と同じく有線LAN5名程度(小事務所)での使用、フォームからの入力のことで思案しています。
Access(バックエンドが Access の ACE(?))の場合、
レコードレベルロックができない、ページレベルロックしかできずワークテーブルを用意して何だかんだと学んだのですが、
VBA でいろいろとお膳立てしない(Access の機能・仕様の)レコードレベル悲観ロックも
(少人数であれば)普通に実用できるということでしょうか。
このへんいまいち分からず、ご教授いただければ非常にありがたいです。
前回の回答の設定で「レコードレベルロック」は可能です。
ただし、データベースパスワードを設定できないという制限があります。
(データベースパスワードを設定すると「ページレベルロック」になる。)
AccessのDBファイルを長期的に安定して使用するには - hatena chips
上記でもふれてますが、Access95から機能追加、改修しながら使用してますが、ここ15年間ぐらいはこの設定でデータベースの破損やトラブルはありません。Access2000頃までは、たまに破損していたのでバックアップからリストアしたということはありましたが。
ワークテーブルを使うとか、非連結フォームを使うとか、特別なことはせずに、普通に連結フォームで問題なく運用しています。あくまで、当方の環境と運用においてということですが。
当方の運用
忙しいときは5名で同時入力、ただし顧客毎に担当分けしているので同じレコードを同時入力ということはほぼない。
お返事ありがとうございます。
例えば私の手持ちの『Access VBA ポケットリファレンス』(2010年)に「業務システムとして Access を利用するなら、非連結フォームを心がけて下さい」とあり、その他書籍かウェブサイトかを問わずそれ的な情報にしばしば遭遇し、最近の
『Access VBA 実践マスターガイド』(2019年)を確認してもやはり非連結フォーム、SQLでの更新をピックアップしています。ので、Access はそうしないと共有できない仕様なのかと誤解(?)しておりました。
hatena さんは、このあたりどう学習なさったのでしょうか。何か良い書籍をご存じでしょうか。
ちなみに私の当初の質問は「ロックがだめでも楽観的排他制御で工数を省けるなら省きたい」というだけで、楽観的排他制御が主目的だったわけではありません。
連投ですみません。整理すると、
大前提 「AccessのDBファイルを長期的に安定して使用するには」のようにする
その上で
・4, 5人までの利用 × 同じレコードの同時編集を回避する -> Access が用意している排他制御で OK
・それ以外 -> ワークテーブルや非連結フォームの実装必須
でいいのでしょうか。結構調べてきたつもりですがなかなか明快な説明に会えず、よろしくお願い致します。
Accessのオプションに、共有モードやレコードロックの設定があるので、連結フォームでの共有は使えるものでしょう。
MSの公式ドキュメントにも下記の記載があります。
この破損する可能性が軽減させるというのがどの程度なのか、は不明確ですので、これをどうとらえるかで結論も変わってくるでしょう。
自身の経験から、これはOKと思っています。(もちろん定期的なバックアップは取ってますが)
それ以上の場合は、 連結フォームでどこまでOKかは分かりません。同じレコードの同時編集を回避すればかなりの人数の共有まではOKではないかと予想してます。
同じレコードの同時編集が頻発する運用だと、連結フォームではきついかなという印象です。
ただ、ワークテーブルや非連結フォームで、同時編集までの排他処理を考慮して設計しようとすると、膨大な工数になるでしょう。また、ワークテーブルや非連結フォームを推奨するサイトや書籍があるのは知ってますが、同時編集の排他処理までをきちんと解説しているものは見たことがありません。
そこまでの信頼性を求めるなら、SQL Server などのデータベース サーバー製品と連携させることを検討したほうがいいようにも思います。ただ、一桁台の人数のでの共有はコスト的に見合わないと思います。
この辺は主観的な部分が多分にありますので、あくまで一個人の意見として参考にしてください。
たびたびありがとうございます。
なるほどです。Access は知って長いですが、やっと納得できる文章を目にできて感動的ですらあります。
>ワークテーブルや非連結フォームを推奨するサイトや書籍があるのは知ってますが、同時編集の排他処理までをきちんと解説しているものは見たことがありません。
私も結構読んできましたが、私も見たことが無いです。Access 職人の食い扶持として秘密なのか、「だいたい分かるよね?」みたいなことなのか。
ともあれ「解決」でクローズさせていただきたいと思います。
ありがとうございました。
推測ですが、かなりのコード量になる、その手間に対して見合う信頼性、安全性が得られるのか、というところだと思います。
そこまで人的コストをかけるなら、SQL Serverの無料版とかその他のデータベースサーバー製品にした方がコストに見合った結果が得られるということだと思います。