C# と VB.NET の質問掲示板

■No102633 (eb さん) に返信
>>> 行ロックのテストをしているのですが、
>>> インデックスが設定されたフィールドの値を更新した際の挙動で悩んでいます。
>>> 助けていただければ幸いです。よろしくお願いします。
>> 第三者が検証できるようなテスト手順を共有できますか?
> 結論から言うと、あくまで私の試行錯誤結果ですが、

テスト手順が不明瞭なまま「両方否になるはずなのに、行ロックの成否が分かれました」と
言われても状況が分からないので、検証手順を共有して欲しい、と伝えたつもりでした…。

今回の「試行錯誤の結果」には、どのようなテーブルをどう操作したのかが曖昧ですし、
DAO の話なのか ADO の話なのか、パラメーター指定はどうなっているのかなど、
状況説明が不足しすぎていて、どのようなテスト手順だったのか、まったくもって分からないです。
更新クエリの場合、バインドしたフォームから編集した場合、Recordset を編集する場合などなど。

> 悲観ロックして Update 実行前までが行ロック、
> Update 実行後から CommitTrans までがページロックだと確認されました。

それは共有ロックが排他ロックに切り替わる「タイミング」の話でしょうか。
質問の本題は、行ロック/ページロックの差異、すなわちロックされる「範囲」の違いの話かと思っていたのですが。

DAO の場合、Edit メソッドを読んだ時点でロックが取得され、Update 時に解放されます。
この動作は LockEdits プロパティの影響を受けます。
http://sennin.image.coocan.jp/access/access15/access15.htm
https://learn.microsoft.com/ja-jp/office/client-developer/access/desktop-database-reference/recordset-lockedits-property-dao?WT.mc-id=DT-MVP-8907

一方、ADO の場合は、Collect プロパティなどに書き込みを開始した時点が、
DAO でいうところの Edit メソッド相当の動作にあたります。
そして編集開始時にロックが開始されるか、Update 時にロックが開始されるかは
OLE DB Provider の実装と、カーソルの種類によって異なります。
クライアントカーソルでは後者だったかな…? ちょっとうろ覚え。

それと、Access の場合、テーブルを Form や Report にバインドして使うことが多いですが、
こちらは RecordLocks プロパティの影響を受けます。既定値は0:楽観的ロックですが、
1:すべてのレコードにすれば、そのテーブルを開いた時点でテーブルロックが取得されますし、
2:編集済みのレコードになれば、編集開始時点で排他的ロックが取得されます。
https://youtu.be/_bstegbUBPA?t=468

ADO のトランザクションの場合、ACID特性の分離レベル(isolaction)の影響もあるのですが、
私は対 Access での動作を検証したことが無いです。
https://techracho.bpsinc.jp/kotetsu75/2018_12_14/66410

一方 DAO には、ADO の IsolationLevel プロパティにあたる仕組みは無かったはず。
(ODBCDirect ワークスペース用の IsolateODBCTTrans ってのがある程度)

> MS 公式の文章からは、私では到底予想できませんでした……。
Micorost 公式の MDAC SDK 関連サイトも軒並み無くなっていますしね。
紙媒体の古い資料だと、DAO だと ISBN:9784756121899 、ADO だと 9784798101309 で
読んだ記憶があるんですが、今どちらも手元になくて確認できません。

前の記事(元になった記事)	次の記事(この記事の返信)
←Re[2]: JET/ACE ロックとインデックスフィールドの値の更新 /eb	→Re[4]: JET/ACE ロックとインデックスフィールドの値の更新 /eb
上記関連ツリー
JET/ACE ロックとインデックスフィールドの値の更新 / eb (23/11/28(Tue) 05:01) #102625
`└` Re[1]: JET/ACE ロックとインデックスフィールドの値の更新 / 魔界の仮面弁士 (23/11/28(Tue) 06:08) #102627
`└` Re[2]: JET/ACE ロックとインデックスフィールドの値の更新 / eb (23/11/28(Tue) 19:30) #102633
`└` JET/ACE ロックとインデックスフィールドの値の更新 / 魔界の仮面弁士 (23/11/29(Wed) 09:38) #102634 ←Now
`└` Re[4]: JET/ACE ロックとインデックスフィールドの値の更新 / eb (23/11/29(Wed) 19:35) #102645
`└` Re[5]: JET/ACE ロックとインデックスフィールドの値の更新 / eb (23/12/02(Sat) 04:37) #102667 解決済み
`└` Re[6]: JET/ACE ロックとインデックスフィールドの値の更新 / 魔界の仮面弁士 (23/12/04(Mon) 10:35) #102670 解決済み
`└` Re[7]: JET/ACE ロックとインデックスフィールドの値の更新 / eb (23/12/06(Wed) 05:17) #102674 解決済み
上記ツリーを一括表示 / 上記ツリーをトピック表示
上記の記事へ返信

前の記事(元になった記事)

次の記事(この記事の返信)

←Re[2]: JET/ACE ロックとインデックスフィールドの値の更新 /eb

→Re[4]: JET/ACE ロックとインデックスフィールドの値の更新 /eb
　

上記関連ツリー

JET/ACE ロックとインデックスフィールドの値の更新 / eb (23/11/28(Tue) 05:01) #102625

└

Re[1]: JET/ACE ロックとインデックスフィールドの値の更新 / 魔界の仮面弁士 (23/11/28(Tue) 06:08) #102627

└

Re[2]: JET/ACE ロックとインデックスフィールドの値の更新 / eb (23/11/28(Tue) 19:30) #102633

└ JET/ACE ロックとインデックスフィールドの値の更新 / 魔界の仮面弁士 (23/11/29(Wed) 09:38) #102634 ←Now

└

Re[4]: JET/ACE ロックとインデックスフィールドの値の更新 / eb (23/11/29(Wed) 19:35) #102645

└

Re[5]: JET/ACE ロックとインデックスフィールドの値の更新 / eb (23/12/02(Sat) 04:37) #102667 解決済み

└

Re[6]: JET/ACE ロックとインデックスフィールドの値の更新 / 魔界の仮面弁士 (23/12/04(Mon) 10:35) #102670 解決済み

└

Re[7]: JET/ACE ロックとインデックスフィールドの値の更新 / eb (23/12/06(Wed) 05:17) #102674 解決済み

上記ツリーを一括表示 / 上記ツリーをトピック表示
　

上記の記事へ返信

名前 (*必須)
E-Mail (任意)
Web サイト (任意)
投稿モード	通常モード　　図表モード (ソースコードを貼る場合はこちらを使用)
本文　(質問の場合は、開発環境・使用言語のバージョンなどを最初に書いてください) ■No102634 (魔界の仮面弁士さん) に返信 > ■No102633 (eb さん) に返信 > >>> 行ロックのテストをしているのですが、 > >>> インデックスが設定されたフィールドの値を更新した際の挙動で悩んでいます。 > >>> 助けていただければ幸いです。よろしくお願いします。 > >> 第三者が検証できるようなテスト手順を共有できますか? >>結論から言うと、あくまで私の試行錯誤結果ですが、 > > テスト手順が不明瞭なまま「両方否になるはずなのに、行ロックの成否が分かれました」と > 言われても状況が分からないので、検証手順を共有して欲しい、と伝えたつもりでした…。 > > 今回の「試行錯誤の結果」には、どのようなテーブルをどう操作したのかが曖昧ですし、 > DAO の話なのか ADO の話なのか、パラメーター指定はどうなっているのかなど、 > 状況説明が不足しすぎていて、どのようなテスト手順だったのか、まったくもって分からないです。 > 更新クエリの場合、バインドしたフォームから編集した場合、Recordset を編集する場合などなど。 > > >>悲観ロックして Update 実行前までが行ロック、 >>Update 実行後から CommitTrans までがページロックだと確認されました。 > > それは共有ロックが排他ロックに切り替わる「タイミング」の話でしょうか。 > 質問の本題は、行ロック/ページロックの差異、すなわちロックされる「範囲」の違いの話かと思っていたのですが。 > > DAO の場合、Edit メソッドを読んだ時点でロックが取得され、Update 時に解放されます。 > この動作は LockEdits プロパティの影響を受けます。 > http://sennin.image.coocan.jp/access/access15/access15.htm > https://learn.microsoft.com/ja-jp/office/client-developer/access/desktop-database-reference/recordset-lockedits-property-dao?WT.mc-id=DT-MVP-8907 > > 一方、ADO の場合は、Collect プロパティなどに書き込みを開始した時点が、 > DAO でいうところの Edit メソッド相当の動作にあたります。 > そして編集開始時にロックが開始されるか、Update 時にロックが開始されるかは > OLE DB Provider の実装と、カーソルの種類によって異なります。 > クライアントカーソルでは後者だったかな…? ちょっとうろ覚え。 > > それと、Access の場合、テーブルを Form や Report にバインドして使うことが多いですが、 > こちらは RecordLocks プロパティの影響を受けます。既定値は0:楽観的ロックですが、 > 1:すべてのレコードにすれば、そのテーブルを開いた時点でテーブルロックが取得されますし、 > 2:編集済みのレコードになれば、編集開始時点で排他的ロックが取得されます。 > https://youtu.be/_bstegbUBPA?t=468 > > ADO のトランザクションの場合、ACID特性の分離レベル(isolaction)の影響もあるのですが、 > 私は対 Access での動作を検証したことが無いです。 > https://techracho.bpsinc.jp/kotetsu75/2018_12_14/66410 > > 一方 DAO には、ADO の IsolationLevel プロパティにあたる仕組みは無かったはず。 > (ODBCDirect ワークスペース用の IsolateODBCTTrans ってのがある程度) > > >>MS 公式の文章からは、私では到底予想できませんでした……。 > Micorost 公式の MDAC SDK 関連サイトも軒並み無くなっていますしね。 > 紙媒体の古い資料だと、DAO だと ISBN:9784756121899 、ADO だと 9784798101309 で > 読んだ記憶があるんですが、今どちらも手元になくて確認できません。
編集キー	自分の投稿を編集する時に必要です (半角8文字以内)
解決済み /解決したらチェックしておきましょう。
プレビュー/

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト