連番ファイルの最終連番確保処理について
- このフォーラムに新しいトピックを立てることはできません
- このフォーラムではゲスト投稿が禁止されています
LIMS008
投稿数: 3
投稿数: 3
連番ファイルの最終連番確保の際、次のようなサブプログラムにて、確保処理をしておりました。
親タスク（バッチ）：連番ファイルをDSリンク Ｑ ＷＷ
子タスク（バッチ）：連番ファイルをASリンク Ｃ ＷＷ
連番←親タスクの連番＋１を代入
最終連番が１１の状態で、ａ端末、ｂ端末から上記サブプログラムをコールしたところ、（ａ端末が一瞬先にコール）
下記のような結果になりました。
�。瓩砲藤隠欧魍諒檗覆靴燭弔發蝓�
�■瓩僚萢�が完了前に、ｂでも１２を確保しに行く
�２燭蕕�の事情でｂが先に処理完了（ｂが１２を確保）
�ぃ瓩粒諒櫃麓最圓掘◆屮ぅ鵐妊奪�スが重複しています。テーブル：（テーブル名）」とメッセージ表示される。
動作予想（理想）は、下記のつもりでした。
�。瓩砲藤隠欧魍諒檗覆靴燭弔發蝓�
�■瓩僚萢�が完了前に、ｂでも１２を確保しに行く
��ｂでは、「レコードロックの解除待ち」
�ぃ瓩粒諒歃萢�が完了（１２を確保）
�ゥ譽魁璽疋蹈奪�が解除され、ｂは１３を確保
V4,V7では、予想通りの動作でしたが、V9になってこのようなことになっています。
環境は、magic：9.30J SP5 DB：Pervasive2000i SV：Win2000sv です。
よろしくおねがいします。
親タスク（バッチ）：連番ファイルをDSリンク Ｑ ＷＷ
子タスク（バッチ）：連番ファイルをASリンク Ｃ ＷＷ
連番←親タスクの連番＋１を代入
最終連番が１１の状態で、ａ端末、ｂ端末から上記サブプログラムをコールしたところ、（ａ端末が一瞬先にコール）
下記のような結果になりました。
�。瓩砲藤隠欧魍諒檗覆靴燭弔發蝓�
�■瓩僚萢�が完了前に、ｂでも１２を確保しに行く
�２燭蕕�の事情でｂが先に処理完了（ｂが１２を確保）
�ぃ瓩粒諒櫃麓最圓掘◆屮ぅ鵐妊奪�スが重複しています。テーブル：（テーブル名）」とメッセージ表示される。
動作予想（理想）は、下記のつもりでした。
�。瓩砲藤隠欧魍諒檗覆靴燭弔發蝓�
�■瓩僚萢�が完了前に、ｂでも１２を確保しに行く
��ｂでは、「レコードロックの解除待ち」
�ぃ瓩粒諒歃萢�が完了（１２を確保）
�ゥ譽魁璽疋蹈奪�が解除され、ｂは１３を確保
V4,V7では、予想通りの動作でしたが、V9になってこのようなことになっています。
環境は、magic：9.30J SP5 DB：Pervasive2000i SV：Win2000sv です。
よろしくおねがいします。
投票数:0
平均点:0.00
atushi
居住地: 長野県
投稿数: 30
居住地: 長野県
投稿数: 30
LIMS008様、こんにちは
<質問事項と予想対策>
(1)V4、V7でうまく動作していたことを考えると、V9での
タスク特性のロック方式の設定が気になる所ではあります。
ロック方式によって、レコードロックがかかっていない
状態で処理されたのかもしれません。
バッチタスクデフォルトの[I=即時]以外は要確認です。
(2)リンクＱは照会、リンクＣは登録とわかりますが、
DSは[降順]、ASは[昇順]という意味でしょうか？
(3)単純に、親タスクのリンクと、子タスクのリンクのみで、
メインテーブルがないのであれば、１つのタスクで
まとめて２つリンク定義しても良いのでは？
(4)連番ファイルのデータ構造は、連番がキー項目になっていて、
常に最終の連番が追加登録された複数行のレコードということ
でしょうか？
その場合は、1レコードしかないデータ構造に変更して、
そこに最終の連番が入るようにすると処理しやすいと思います。
例えば、管理番号という項目を追加して、それをキーにします。
管理番号は、常に[1]を代入及び位置付とします。
そうすれば、管理番号[1]のレコードに対して、
レコードロックがかかり、連番には最終の連番が入ります。
以下、そのときのサブプログラム例です。
タスクはバッチタスクを１つ作成し後置終了とします。
<レコードメイン>
セレクト パラメータ P_連番
リンク書込 連番ファイル 管理番号で[昇順]
セレクト 管理番号 [代入][位置付の小大]に[1]を設定
セレクト 連番
リンク終了
<レコード後>
項目更新 P_連番 式[連番+1] 代入
項目更新 連番 式[連番+1] 代入
(5)(4)によるデータ構造の変更を行わないで対応する方法として、
サブプログラム内の連番ファイルのＤＢ設定をアクセスＷ、
共有Ｒでテーブルロックをかければ、A端末が実行中は、
B端末は必ずテーブルロックエラーとなり、バッチ処理の
完了待ちになると思います。
原因がわからず、緊急回避したい場合に有効です。
<質問事項と予想対策>
(1)V4、V7でうまく動作していたことを考えると、V9での
タスク特性のロック方式の設定が気になる所ではあります。
ロック方式によって、レコードロックがかかっていない
状態で処理されたのかもしれません。
バッチタスクデフォルトの[I=即時]以外は要確認です。
(2)リンクＱは照会、リンクＣは登録とわかりますが、
DSは[降順]、ASは[昇順]という意味でしょうか？
(3)単純に、親タスクのリンクと、子タスクのリンクのみで、
メインテーブルがないのであれば、１つのタスクで
まとめて２つリンク定義しても良いのでは？
(4)連番ファイルのデータ構造は、連番がキー項目になっていて、
常に最終の連番が追加登録された複数行のレコードということ
でしょうか？
その場合は、1レコードしかないデータ構造に変更して、
そこに最終の連番が入るようにすると処理しやすいと思います。
例えば、管理番号という項目を追加して、それをキーにします。
管理番号は、常に[1]を代入及び位置付とします。
そうすれば、管理番号[1]のレコードに対して、
レコードロックがかかり、連番には最終の連番が入ります。
以下、そのときのサブプログラム例です。
タスクはバッチタスクを１つ作成し後置終了とします。
<レコードメイン>
セレクト パラメータ P_連番
リンク書込 連番ファイル 管理番号で[昇順]
セレクト 管理番号 [代入][位置付の小大]に[1]を設定
セレクト 連番
リンク終了
<レコード後>
項目更新 P_連番 式[連番+1] 代入
項目更新 連番 式[連番+1] 代入
(5)(4)によるデータ構造の変更を行わないで対応する方法として、
サブプログラム内の連番ファイルのＤＢ設定をアクセスＷ、
共有Ｒでテーブルロックをかければ、A端末が実行中は、
B端末は必ずテーブルロックエラーとなり、バッチ処理の
完了待ちになると思います。
原因がわからず、緊急回避したい場合に有効です。
投票数:1
平均点:10.00
atushi
居住地: 長野県
投稿数: 30
居住地: 長野県
投稿数: 30
LIMS008様、こんにちは
(4)の回答ですが、たぶん私の方で勘違いしていたと思うので
以下のように訂正致します。
(4)訂正回答
連番ファイルとは別に、管理番号マスタを用意して、
そこに最終番号が入るようにすると処理しやすいと思います。
管理番号マスタは、管理番号をキーにして、常に[1]を
代入及び位置付とします。
管理番号[1]のレコードに対してレコードロックがかかります。
以下、そのときに最終番号を取得するサブプログラム例です。
タスクはバッチタスクを１つ作成し後置終了とします。
<レコードメイン>
セレクト パラメータ P_最終番号
リンク書込 管理番号マスタ 管理番号で[昇順]
セレクト 管理番号 [代入][位置付の小大]に[1]を設定
セレクト 最終番号
リンク終了
<レコード後>
項目更新 P_最終番号 式[最終番号+1] 代入
項目更新 最終番号 式[最終番号+1] 代入
<補足>
他の連番ファイルでも行いたいときは管理番号[2]から使用します。
その場合は、P_管理番号をパラメータとして追加して、
それを管理番号に、代入及び位置付小大設定をするようになります。
(4)の回答ですが、たぶん私の方で勘違いしていたと思うので
以下のように訂正致します。
(4)訂正回答
連番ファイルとは別に、管理番号マスタを用意して、
そこに最終番号が入るようにすると処理しやすいと思います。
管理番号マスタは、管理番号をキーにして、常に[1]を
代入及び位置付とします。
管理番号[1]のレコードに対してレコードロックがかかります。
以下、そのときに最終番号を取得するサブプログラム例です。
タスクはバッチタスクを１つ作成し後置終了とします。
<レコードメイン>
セレクト パラメータ P_最終番号
リンク書込 管理番号マスタ 管理番号で[昇順]
セレクト 管理番号 [代入][位置付の小大]に[1]を設定
セレクト 最終番号
リンク終了
<レコード後>
項目更新 P_最終番号 式[最終番号+1] 代入
項目更新 最終番号 式[最終番号+1] 代入
<補足>
他の連番ファイルでも行いたいときは管理番号[2]から使用します。
その場合は、P_管理番号をパラメータとして追加して、
それを管理番号に、代入及び位置付小大設定をするようになります。
投票数:1
平均点:10.00
LIMS008
投稿数: 3
投稿数: 3
前略、atushi様。
大変詳細な解説、ありがとうございました。
（対策＆緊急対処法まで）
やはり管理番号マスタを利用するのが、確実そうですねぇ。
参考になりました。
またatushi様からの確認内容は、概ね推測の通りですが、一応返答しておきます。
（１）[I=即時]にしております
（２）そのとおりです。
（３）１階層ではロックがかからないので２階層にと、セミナー等で聞いたような…昔のことなので
（４）連番の数だけレコードがあります
言葉足らずの投稿に、丁寧に回答いただきまして、感謝しております。
今後とも、よろしくお願いします。
大変詳細な解説、ありがとうございました。
（対策＆緊急対処法まで）
やはり管理番号マスタを利用するのが、確実そうですねぇ。
参考になりました。
またatushi様からの確認内容は、概ね推測の通りですが、一応返答しておきます。
（１）[I=即時]にしております
（２）そのとおりです。
（３）１階層ではロックがかからないので２階層にと、セミナー等で聞いたような…昔のことなので
（４）連番の数だけレコードがあります
言葉足らずの投稿に、丁寧に回答いただきまして、感謝しております。
今後とも、よろしくお願いします。
投票数:0
平均点:0.00
atushi
居住地: 長野県
投稿数: 30
居住地: 長野県
投稿数: 30
LIMS008様、こんにちは
>（３）１階層ではロックがかからないので２階層にと、セミナー等で聞いたような…昔のことなので
１階層でもＤＢ設定のアクセス[Ｗ]で、他端末に対して、
リンクレコードにてレコードロックがかかりますので大丈夫です。
※私はＶ６(一部Ｖ７)の頃、ＭＳＪのセミナーを受けましたが、
テキストにあったかな？
-----------------------------------------------------------
<(5)回答の補足>
当初、連番ファイルを管理番号マスタのような
最終連番を管理するテーブルと勘違いしてしまいました。
※(4)訂正回答より
上記より、(5)のテーブルロックの緊急回避は、管理番号マスタ
のようなテーブルに対して行わないと意味がありません。
連番ファイルに対して、テーブルロックすると、
他端末でオンラインで入力中のとき、最終番号を取得する
バッチ処理を実行するとロック待ちになってしまいます。
-----------------------------------------------------------
>（３）１階層ではロックがかからないので２階層にと、セミナー等で聞いたような…昔のことなので
１階層でもＤＢ設定のアクセス[Ｗ]で、他端末に対して、
リンクレコードにてレコードロックがかかりますので大丈夫です。
※私はＶ６(一部Ｖ７)の頃、ＭＳＪのセミナーを受けましたが、
テキストにあったかな？
-----------------------------------------------------------
<(5)回答の補足>
当初、連番ファイルを管理番号マスタのような
最終連番を管理するテーブルと勘違いしてしまいました。
※(4)訂正回答より
上記より、(5)のテーブルロックの緊急回避は、管理番号マスタ
のようなテーブルに対して行わないと意味がありません。
連番ファイルに対して、テーブルロックすると、
他端末でオンラインで入力中のとき、最終番号を取得する
バッチ処理を実行するとロック待ちになってしまいます。
-----------------------------------------------------------
投票数:0
平均点:0.00
LIMS008
投稿数: 3
投稿数: 3
atushi様。
本件、調査した結果を報告しておきます。
結論から申し上げますと、MAGICのバージョン9.3のバグのようです。
MSJに問合せた結果、そういう回答でしたので、
私のほうで、9.4の環境下でテストしました。
すると、バッチリ、レコードロックがかかり、
思惑通りの動作となることが確認できました。
色々とアドバイスいただきまして、ありがとうございました。
今後とも、何かありましたら、よろしくお願いします。
本件、調査した結果を報告しておきます。
結論から申し上げますと、MAGICのバージョン9.3のバグのようです。
MSJに問合せた結果、そういう回答でしたので、
私のほうで、9.4の環境下でテストしました。
すると、バッチリ、レコードロックがかかり、
思惑通りの動作となることが確認できました。
色々とアドバイスいただきまして、ありがとうございました。
今後とも、何かありましたら、よろしくお願いします。
投票数:0
平均点:0.00