複数端末から同一レコードへの更新について
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
NFH
投稿数: 16
投稿数: 16
いつもお世話になっております。
コード │ 最終見積番号
──────────────
A │ 1
上記のような見積番号がどこまで発番されているかを管理するテーブルがあり、
新しく見積番号を取得する際には、
トランザクションモード：P=物理
トランザクション開始：N=なし
ロック方式：I=即時
のバッチタスクにて照会リンクでテーブルにアクセスし、
「最終見積番号」項目をカウントアップしその値を使用する、ということを行っています。
この処理を２台のＰＣで同時に行った際に、
ＰＣ１・ＰＣ２ともに同じ番号を取得してしまうことが稀にあり(5,000回に1回ぐらい？)困っております。
複数ＰＣから同レコードに対して処理する場合、
１台目のＰＣのみ処理されて、他のＰＣは「レコードロックの解除待ち」でロックが解除されるまでリトライする、
という様に動作すると考えていたのですが、思惑通りになりません。
なにか確認するべき設定等、ご教示頂けますでしょうか。
よろしくお願い致します。
---------------------------------------
■環境
ＰＣ：
Windows7(32bit) SP1
Magic V9 Plus Ver 9.40J SP6b PT1
ＤＢ：
Pervasive PSQL 11
---------------------------------------
コード │ 最終見積番号
──────────────
A │ 1
上記のような見積番号がどこまで発番されているかを管理するテーブルがあり、
新しく見積番号を取得する際には、
トランザクションモード：P=物理
トランザクション開始：N=なし
ロック方式：I=即時
のバッチタスクにて照会リンクでテーブルにアクセスし、
「最終見積番号」項目をカウントアップしその値を使用する、ということを行っています。
この処理を２台のＰＣで同時に行った際に、
ＰＣ１・ＰＣ２ともに同じ番号を取得してしまうことが稀にあり(5,000回に1回ぐらい？)困っております。
複数ＰＣから同レコードに対して処理する場合、
１台目のＰＣのみ処理されて、他のＰＣは「レコードロックの解除待ち」でロックが解除されるまでリトライする、
という様に動作すると考えていたのですが、思惑通りになりません。
なにか確認するべき設定等、ご教示頂けますでしょうか。
よろしくお願い致します。
---------------------------------------
■環境
ＰＣ：
Windows7(32bit) SP1
Magic V9 Plus Ver 9.40J SP6b PT1
ＤＢ：
Pervasive PSQL 11
---------------------------------------
投票数:0
平均点:0.00
cabin
投稿数: 48
投稿数: 48
Terminal番号を設定していますか？
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
cabin 様
返信ありがとうございます。
MAGIC.INIの[MAGIC_ENV]Terminalでしょうか。
PC毎に違う値を設定しております。
返信ありがとうございます。
MAGIC.INIの[MAGIC_ENV]Terminalでしょうか。
PC毎に違う値を設定しております。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
同じデータの画面で修正するとレコードロックはかかりますか？
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
ISHIJIMA 様
オンラインタスクで修正、ということでしょうか。
「レコードロック解除待ちです」となります。
最初にご相談したバッチタスクでも基本的には「レコードロック解除待ちです」となるのですが、
稀にそうならない時があるのだと思われます。
オンラインタスクで修正、ということでしょうか。
「レコードロック解除待ちです」となります。
最初にご相談したバッチタスクでも基本的には「レコードロック解除待ちです」となるのですが、
稀にそうならない時があるのだと思われます。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
レコードロックがかかるという事であれば設定に問題ないと思います。
そうなると環境なのでしょうか？
データベースの設定とか詳細を提示してみると良いかも・・
そうなると環境なのでしょうか？
データベースの設定とか詳細を提示してみると良いかも・・
投票数:0
平均点:0.00
cabin
投稿数: 48
投稿数: 48
データソースを、アクセス=W 共有=N にしてみてください。
これでロック中は他の端末はアクセスできません。
これでロック中は他の端末はアクセスできません。
投票数:1
平均点:10.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
READMEの中のデータベース固有の追加情報を確認してみて下さい。
リトライが関係しているかもしれません。
リトライが関係しているかもしれません。
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
ISHIJIMA 様
ご返信ありがとうございます。
・READMEの中のデータベース固有の追加情報を確認してみて下さい。
リトライが関係しているかもしれません。
試しにDBMSのPervasiveのパラメータに「/RTRY=10:500」と入れてみましたが、
変わらず現象が発生してしまいました。
同じREADMEに記述されている「キャッシュエンジンの使用について」の
" ただし、他のクライアントによるデータ更新の直後に同じデータを読み込んだ場合、更新前のデータが取得されることがあります。
運用上支障が出る場合は、Pervasive Control Centerで以下の設定を行ってください。
設定 → クライアント → パフォーマンスチューニング → キャッシュエンジンの使用をOff "
が、状況的に当てはまると思ったのですが、元からキャッシュエンジンの使用はOffになっておりました。
ご返信ありがとうございます。
・READMEの中のデータベース固有の追加情報を確認してみて下さい。
リトライが関係しているかもしれません。
試しにDBMSのPervasiveのパラメータに「/RTRY=10:500」と入れてみましたが、
変わらず現象が発生してしまいました。
同じREADMEに記述されている「キャッシュエンジンの使用について」の
" ただし、他のクライアントによるデータ更新の直後に同じデータを読み込んだ場合、更新前のデータが取得されることがあります。
運用上支障が出る場合は、Pervasive Control Centerで以下の設定を行ってください。
設定 → クライアント → パフォーマンスチューニング → キャッシュエンジンの使用をOff "
が、状況的に当てはまると思ったのですが、元からキャッシュエンジンの使用はOffになっておりました。
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
cabin 様
ご返信ありがとうございます。
・データソースを、アクセス=W 共有=N にしてみてください。
これでロック中は他の端末はアクセスできません。
[共有=N:なし]又は[共有=R:読込]にして検証してみようと思います。
ただ、同じ現象がテーブルロックをする訳にはいかない様な
テーブルでも発生してしまう、あるいはもう既に発生しているのではないかと不安が残ります・・・
ご返信ありがとうございます。
・データソースを、アクセス=W 共有=N にしてみてください。
これでロック中は他の端末はアクセスできません。
[共有=N:なし]又は[共有=R:読込]にして検証してみようと思います。
ただ、同じ現象がテーブルロックをする訳にはいかない様な
テーブルでも発生してしまう、あるいはもう既に発生しているのではないかと不安が残ります・・・
投票数:0
平均点:0.00
dongzy
投稿数: 4
投稿数: 4
うちのシステムには、次のような採番タスクがあります。
リンク書出でレコードを参照、更新
ロック方式：O=入力時
多分ロック方式によって、検証が行われるかどうかの違いだと思います。
I=即時……検証は行われません。
O=入力時……検証が行われます。
リンク書出でレコードを参照、更新
ロック方式：O=入力時
多分ロック方式によって、検証が行われるかどうかの違いだと思います。
I=即時……検証は行われません。
O=入力時……検証が行われます。
投票数:1
平均点:10.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
５０００回に１回との事なので再現性がないと思っていたのですがわざと発生させる事はできるのでしょうか？
であればいろいろ設定を変更して確認するしかないと思います。
であればいろいろ設定を変更して確認するしかないと思います。
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
dongzy 様
バッチタスクで[O=入力時]のロック方式はあまり経験がないのですが、確認してみたいと思います。
情報ありがとうございます。
ISHIJIMA 様
�‐伐颯螢鵐�でレコードにアクセス
�▲譽魁璽標綵萢�で番号をカウントアップ
��カウントアップした番号を親タスクに戻す
�た謄織好�で別テーブルに保存
というようなことを複数台で同時に処理して、わざとロックが発生するようにしたところ再現できました。
バッチタスクで[O=入力時]のロック方式はあまり経験がないのですが、確認してみたいと思います。
情報ありがとうございます。
ISHIJIMA 様
�‐伐颯螢鵐�でレコードにアクセス
�▲譽魁璽標綵萢�で番号をカウントアップ
��カウントアップした番号を親タスクに戻す
�た謄織好�で別テーブルに保存
というようなことを複数台で同時に処理して、わざとロックが発生するようにしたところ再現できました。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
�‐伐颯螢鵐�でレコードにアクセス
�▲譽魁璽標綵萢�で番号をカウントアップ
ここで警告メーセージ等で中断させる
��カウントアップした番号を親タスクに戻す
�た謄織好�で別テーブルに保存
基本的にはその他の人はレコードロック状態が続くはずですがどうなりますか？
�▲譽魁璽標綵萢�で番号をカウントアップ
ここで警告メーセージ等で中断させる
��カウントアップした番号を親タスクに戻す
�た謄織好�で別テーブルに保存
基本的にはその他の人はレコードロック状態が続くはずですがどうなりますか？
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
「レコードロックの解除待ちです」と表示された状態が続き、
警告メッセージを閉じると「レコードロックの解除待ちです」が消えます。
警告メッセージを閉じると「レコードロックの解除待ちです」が消えます。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
その状態で問題が発生していますか？
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
問題が発生しているのであれば警告メッセージをカウントアップした番号を表示すれば解除待ちのメッセージの後に警告メーセージが表示され順番に解除されていきますよね
この時に番号が同じ番号になっているという事ですか？
この時に番号が同じ番号になっているという事ですか？
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
しばらく2台で番号を採番し続けたところ、
1420個目の番号が重複して採番されてしまいました。
・・・
1323〜1366：PC2が採番
1367〜1420：PC1が採番
1420〜1499：PC2が採番
1500〜1554：PC1が採番
・・・
となりました。
1420個目の番号が重複して採番されてしまいました。
・・・
1323〜1366：PC2が採番
1367〜1420：PC1が採番
1420〜1499：PC2が採番
1500〜1554：PC1が採番
・・・
となりました。
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
引用：
警告画面には番号を出していなかったので、もう一度やってみます。
ISHIJIMAさんは書きました：
問題が発生しているのであれば警告メッセージをカウントアップした番号を表示すれば解除待ちのメッセージの後に警告メーセージが表示され順番に解除されていきますよね
この時に番号が同じ番号になっているという事ですか？
警告画面には番号を出していなかったので、もう一度やってみます。
投票数:1
平均点:0.00
NFH
投稿数: 16
投稿数: 16
引用：
222個目の採番で再発しました。
220：PC1が採番
221：PC1が採番
222：PC1が採番
222：PC2が採番
223：PC2が採番
224：PC2が採番
という順番で表示されました。
ISHIJIMAさんは書きました：
問題が発生しているのであれば警告メッセージをカウントアップした番号を表示すれば解除待ちのメッセージの後に警告メーセージが表示され順番に解除されていきますよね
この時に番号が同じ番号になっているという事ですか？
222個目の採番で再発しました。
220：PC1が採番
221：PC1が採番
222：PC1が採番
222：PC2が採番
223：PC2が採番
224：PC2が採番
という順番で表示されました。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
警告メッセージを表示した場合は交互に採番されませんか？
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
Pervasive PSQL 11の設定でローカルエンジンの構成でデータ整合性の中にトランザクション一貫性保守はチェックが入っていますか確かこの設定は奨励されていると思います。
投票数:1
平均点:10.00
NFH
投稿数: 16
投稿数: 16
・警告メッセージを表示した場合は交互に採番されませんか？
交互には表示されませんでした。
再試行までの待機時間があるのでしょうか。
・Pervasive PSQL 11の設定でローカルエンジンの構成でデータ整合性の中にトランザクション一貫性保守はチェックが入っていますか確かこの設定は奨励されていると思います。
確認したところチェックが入っておりませんでした。
おっしゃるとおりREADMEにも推奨環境設定として記述がありました。
これが原因でしょうか。サーバーの設定はすぐに変更できそうもないので、
Workgroupで確認してみようと思います。
情報頂きありがとうございます。
交互には表示されませんでした。
再試行までの待機時間があるのでしょうか。
・Pervasive PSQL 11の設定でローカルエンジンの構成でデータ整合性の中にトランザクション一貫性保守はチェックが入っていますか確かこの設定は奨励されていると思います。
確認したところチェックが入っておりませんでした。
おっしゃるとおりREADMEにも推奨環境設定として記述がありました。
これが原因でしょうか。サーバーの設定はすぐに変更できそうもないので、
Workgroupで確認してみようと思います。
情報頂きありがとうございます。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
もう少しＲＥＡＤＭＥと同じになっているか確認された方が良いかもしれません。
今まで排他制御で問題になった事はないですよ
今まで排他制御で問題になった事はないですよ
投票数:0
平均点:0.00
Tanda
投稿数: 2151
投稿数: 2151
照会リンクで「最終見積番号」にアクセスするより、最終見積番号取得専用のバッチタスクを経由したほうが確実ですよ。
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
ISHIJIMA 様
ReadMe - データベース固有の追加情報 - Pervasive.SQLの内容を参考に、
下記の設定で再度検証してみたいと思います。
■採番タスク
トランザクションモード：物理
トランザクション開始：なし
ロック方式：即時
■MAGIC.INI
・データベース - データベース特性
MAGICロック：B=両方、T=ﾃｰﾌﾞﾙ(両方確認)
ロックパス：空白
・DMBS - DBMS特性
パラメータ：/EXTENDED=Y/RTRY=10:500
・動作環境 - マルチユーザー
ロックファイル：mglock.dat
■Pervasive(Client - MicroKaernelルーターの構成)
・アクセス
ゲートウェイの一貫性保守：on
・パフォーマンスチューニング
キャッシュエンジンの使用：off
■Pervasive(Server - ローカルエンジンの構成)
・アクセス
リモートリクエストの受付：on
キャッシュエンジン接続の許可：off
・データ整合性
ゲートウェイの一貫性保守：on
オペレーションバンドル制限：65535(デフォルト)
起動時間制限：10000(デフォルト)
・メモリの使用
システムキャッシュ：off
Tanda 様
はい。採番機能は採番専用のプログラムで行っており、それをコールする形をとっております。
その採番プログラムで照会リンクを使用して目的のレコードにアクセスしています。
ReadMe - データベース固有の追加情報 - Pervasive.SQLの内容を参考に、
下記の設定で再度検証してみたいと思います。
■採番タスク
トランザクションモード：物理
トランザクション開始：なし
ロック方式：即時
■MAGIC.INI
・データベース - データベース特性
MAGICロック：B=両方、T=ﾃｰﾌﾞﾙ(両方確認)
ロックパス：空白
・DMBS - DBMS特性
パラメータ：/EXTENDED=Y/RTRY=10:500
・動作環境 - マルチユーザー
ロックファイル：mglock.dat
■Pervasive(Client - MicroKaernelルーターの構成)
・アクセス
ゲートウェイの一貫性保守：on
・パフォーマンスチューニング
キャッシュエンジンの使用：off
■Pervasive(Server - ローカルエンジンの構成)
・アクセス
リモートリクエストの受付：on
キャッシュエンジン接続の許可：off
・データ整合性
ゲートウェイの一貫性保守：on
オペレーションバンドル制限：65535(デフォルト)
起動時間制限：10000(デフォルト)
・メモリの使用
システムキャッシュ：off
Tanda 様
はい。採番機能は採番専用のプログラムで行っており、それをコールする形をとっております。
その採番プログラムで照会リンクを使用して目的のレコードにアクセスしています。
投票数:0
平均点:0.00
Tanda
投稿数: 2151
投稿数: 2151
ここは照会リンクではなく、オーソドックスにメインソースにしたほうが良いと思いますよ。
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
照会リンクでアクセス→採番という形を多用してしまっているのですが、メインソースとリンクの違いで、どのような影響が考えられますでしょうか。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
ゲートウェイの一貫性保守：onではなくトランザクション一貫性保守です。
データ整合の下になっているので書き間違えかもしれませんが・・・
データ整合の下になっているので書き間違えかもしれませんが・・・
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
すみません。トランザクション一貫性保守の書き間違いでした。
クライアント側のゲートウェイの一貫性保守と混同していました。
クライアント側のゲートウェイの一貫性保守と混同していました。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
昔のことでよく覚えていませんがＭＡＧＩＣロックは基本的にはＮ＝なしにしてあり、遅延等を使用した場合はＢ＝両方にしてたような気がします。
投票数:0
平均点:0.00
Tanda
投稿数: 2151
投稿数: 2151
照会リンクは常にリンクの再計算が伴いますので、タイミングによっては最新レコードにリンクしていないケースもあり得るかと思います。
これに対してメインソースの物理トランザクションですと、レコードレベルでトランザクション処理すれば確実にレコードがロックされます。
これに対してメインソースの物理トランザクションですと、レコードレベルでトランザクション処理すれば確実にレコードがロックされます。
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
Tanda 様
返信ありがとうございます。
現在下記の検証を行っています。
・採番タスクを３万回コールするプログラムを４台のＰＣでほぼ同時にスタート。
・取得した番号に重複・抜けがないか。
・下記の設定をそれぞれ組み替えて結果に変化がないか。
トランザクション一貫性保守：on/off
トランザクションモード：P=物理
トランザクション開始：N=なし/L=ﾚｺｰﾄﾞﾛｯｸ時
ロック方式：I=即時
MAGICロック：T=ﾃｰﾌﾞﾙ/B=両方
レコードアクセス方法：メインソース/照会リンク
返信ありがとうございます。
現在下記の検証を行っています。
・採番タスクを３万回コールするプログラムを４台のＰＣでほぼ同時にスタート。
・取得した番号に重複・抜けがないか。
・下記の設定をそれぞれ組み替えて結果に変化がないか。
トランザクション一貫性保守：on/off
トランザクションモード：P=物理
トランザクション開始：N=なし/L=ﾚｺｰﾄﾞﾛｯｸ時
ロック方式：I=即時
MAGICロック：T=ﾃｰﾌﾞﾙ/B=両方
レコードアクセス方法：メインソース/照会リンク
投票数:0
平均点:0.00
NFH
投稿数: 16
投稿数: 16
私の環境では下記の結果となりました。
ﾄﾗﾝｻﾞｸｼｮﾝ一貫性保守／MAGICﾛｯｸ／ﾄﾗﾝｻﾞｸｼｮﾝ開始/ﾚｺｰﾄﾞｱｸｾｽ方法 の順に
on／T=ﾃｰﾌﾞﾙ／N=なし／ﾒｲﾝｿｰｽ ･････････････ 重複無し
on／T=ﾃｰﾌﾞﾙ／N=なし／照会ﾘﾝｸ ････････････ 重複無し
on／T=ﾃｰﾌﾞﾙ／L=ﾚｺｰﾄﾞﾛｯｸ時／ﾒｲﾝｿｰｽ ･･･････ 重複無し
on／T=ﾃｰﾌﾞﾙ／L=ﾚｺｰﾄﾞﾛｯｸ時／照会ﾘﾝｸ ･･････ 重複無し
on／B=両方／N=なし／ﾒｲﾝｿｰｽ ･･････････････ 重複有り
on／B=両方／N=なし／照会ﾘﾝｸ ･････････････ 重複有り
on／B=両方／L=ﾚｺｰﾄﾞﾛｯｸ時／ﾒｲﾝｿｰｽ ････････ 重複無し
on／B=両方／L=ﾚｺｰﾄﾞﾛｯｸ時／照会ﾘﾝｸ ･･･････ 重複無し
off／T=ﾃｰﾌﾞﾙ／N=なし／ﾒｲﾝｿｰｽ ････････････ 重複無し
off／T=ﾃｰﾌﾞﾙ／N=なし／照会ﾘﾝｸ ･･･････････ 重複無し
off／T=ﾃｰﾌﾞﾙ／L=ﾚｺｰﾄﾞﾛｯｸ時／ﾒｲﾝｿｰｽ ･･････ 重複無し
off／T=ﾃｰﾌﾞﾙ／L=ﾚｺｰﾄﾞﾛｯｸ時／照会ﾘﾝｸ ･････ 重複無し
off／B=両方／N=なし／ﾒｲﾝｿｰｽ ･････････････ 重複有り
off／B=両方／N=なし／照会ﾘﾝｸ ････････････ 重複有り
off／B=両方／L=ﾚｺｰﾄﾞﾛｯｸ時／ﾒｲﾝｿｰｽ ･･･････ 重複有り
off／B=両方／L=ﾚｺｰﾄﾞﾛｯｸ時／照会ﾘﾝｸ ･･････ 重複有り
[MAGICﾛｯｸ：T=ﾃｰﾌﾞﾙ]だと問題が発生しないようなのですが、理由がよくわかりません。
ﾄﾗﾝｻﾞｸｼｮﾝ一貫性保守／MAGICﾛｯｸ／ﾄﾗﾝｻﾞｸｼｮﾝ開始/ﾚｺｰﾄﾞｱｸｾｽ方法 の順に
on／T=ﾃｰﾌﾞﾙ／N=なし／ﾒｲﾝｿｰｽ ･････････････ 重複無し
on／T=ﾃｰﾌﾞﾙ／N=なし／照会ﾘﾝｸ ････････････ 重複無し
on／T=ﾃｰﾌﾞﾙ／L=ﾚｺｰﾄﾞﾛｯｸ時／ﾒｲﾝｿｰｽ ･･･････ 重複無し
on／T=ﾃｰﾌﾞﾙ／L=ﾚｺｰﾄﾞﾛｯｸ時／照会ﾘﾝｸ ･･････ 重複無し
on／B=両方／N=なし／ﾒｲﾝｿｰｽ ･･････････････ 重複有り
on／B=両方／N=なし／照会ﾘﾝｸ ･････････････ 重複有り
on／B=両方／L=ﾚｺｰﾄﾞﾛｯｸ時／ﾒｲﾝｿｰｽ ････････ 重複無し
on／B=両方／L=ﾚｺｰﾄﾞﾛｯｸ時／照会ﾘﾝｸ ･･･････ 重複無し
off／T=ﾃｰﾌﾞﾙ／N=なし／ﾒｲﾝｿｰｽ ････････････ 重複無し
off／T=ﾃｰﾌﾞﾙ／N=なし／照会ﾘﾝｸ ･･･････････ 重複無し
off／T=ﾃｰﾌﾞﾙ／L=ﾚｺｰﾄﾞﾛｯｸ時／ﾒｲﾝｿｰｽ ･･････ 重複無し
off／T=ﾃｰﾌﾞﾙ／L=ﾚｺｰﾄﾞﾛｯｸ時／照会ﾘﾝｸ ･････ 重複無し
off／B=両方／N=なし／ﾒｲﾝｿｰｽ ･････････････ 重複有り
off／B=両方／N=なし／照会ﾘﾝｸ ････････････ 重複有り
off／B=両方／L=ﾚｺｰﾄﾞﾛｯｸ時／ﾒｲﾝｿｰｽ ･･･････ 重複有り
off／B=両方／L=ﾚｺｰﾄﾞﾛｯｸ時／照会ﾘﾝｸ ･･････ 重複有り
[MAGICﾛｯｸ：T=ﾃｰﾌﾞﾙ]だと問題が発生しないようなのですが、理由がよくわかりません。
投票数:0
平均点:0.00
ISHIJIMA
居住地: 静岡県
投稿数: 1827
居住地: 静岡県
投稿数: 1827
今まで意識した事はありませんがたまたま問題ない状況になったのだと思います。（Ｖ９以前・ＩＳＡＭ）
デフォルトではＭＡＧＩＣロックはＢ＝両方になっています。
トランザクション開始は昔からレコードロック時を使用しています。
トランザクション一貫性保守は必ずＯＮにしています。
ただヘルプにはＩＳＭＡ系のＭＡＧＩＣロックはＴ＝テーブルを奨励していたみたいです。
デフォルトではＭＡＧＩＣロックはＢ＝両方になっています。
トランザクション開始は昔からレコードロック時を使用しています。
トランザクション一貫性保守は必ずＯＮにしています。
ただヘルプにはＩＳＭＡ系のＭＡＧＩＣロックはＴ＝テーブルを奨励していたみたいです。
投票数:0
平均点:0.00