『JV-Data登録クラス』の更新処理について

過去ログ
1
タイトル ： 『JV-Data登録クラス』の更新処理について
— —
記事No ： 5238
投稿日 ： 2023/09/26(Tue) 17:04
投稿者 ： まさ

『JV-Data登録クラス』についての質問となります。

「要数1」の更新処理を見ていましたところ、
INSERT処理には、「発売フラグ単勝」や「発売フラグ複勝」を見て、
「HYOSU_TANPUKU」や「HYOSU_WAKU」に、挿入するか否かを決めておりますが、
UPDATE処理には、上記のフラグを全く見ずにUPDATE処理を行っておりました。

私的には、UPDATE処理にも、「発売フラグ単勝」や「発売フラグ複勝」を見て
、
UPDATE処理を行うか否かを決めるのかと思っておりますが、
何か意図があって、フラグを見ていないのでしょうか？
UPDATE時のフラグを判断をすべきかどうかで迷っております。

フラグがない場合、INSERTの条件に合致していない為、データがないという前
提で、
0件のUPDATE処理を行っているかもしれませんが、ご回答を頂けたらと思います
。|

タイトル ： Re: 『JV-Data登録クラス』の更新処理について
— —
記事No ： 5244
投稿日 ： 2023/10/03(Tue) 14:10
投稿者 ： JRA-VANソフトサポート

JRA-VANソフトサポート 三木です。
DataLab.サービスをご利用頂きまして誠にありがとうございます。

UPDATE処理にも、「発売フラグ単勝」や「発売フラグ複勝」を見て、
UPDATE処理を行うか否かを決めるのかと思っておりますが、
何か意図があって、フラグを見ていないのでしょうか？
UPDATE時のフラグを判断をすべきかどうかで迷っております。

フラグがない場合、INSERTの条件に合致していない為、
データがないという前提で、
0件のUPDATE処理を行っているかもしれませんが、
ご回答を頂けたらと思います。

「発売フラグ単勝」や「発売フラグ複勝」は、データ提供元が設定した値を
そのままご提供しております。

データの使用用途によるかと思いますが、
UPDATE処理時、「0：発売なし」以外のデータ
（「1：発売前取消」「3：発売後取消」「7：発売あり」）が
「0：発売なし」に変更されることを考慮しますと、
フラグを判断条件にしないほうがよいかと存じます。

どうぞよろしくお願いいたします。|

タイトル ： Re^2: 『JV-Data登録クラス』の更新処理について
— —
記事No ： 5245
投稿日 ： 2023/10/04(Wed) 09:17
投稿者 ： まさ

JRA-VANソフトサポート 三木様

ご回答頂きまして、ありがとうございました。
回答を見て、色々考えたのですが、
『JV-Data登録クラス』の新たな問題に気付きました。

UPDATE処理時、「0：発売なし」以外のデータ
（「1：発売前取消」「3：発売後取消」「7：発売あり」）が
「0：発売なし」に変更されることを考慮しますと、
フラグを判断条件にしないほうがよいかと存じます。

おっしゃる通り、「7：発売あり」→「0：発売なし」のケースですと、
フラグを判断条件にいれると、確かに更新されなくなります。

なお、「0：発売なし」→「7：発売あり」のケースですと、
フラグを判断条件にいれなくても、挿入されない問題を見つけました。

これは、「票数」や「オッズ」に関するテーブルにおける考えですが、
1つのテキストファイルが、2つ以上のテーブル（ヘッダー部、ヘッダー部以外
）に格納されるようなケース（フラグで判断）では、
ヘッダー部には必ずINSERTされますが、
ヘッダー部以外には、「0：発売なし」はINSERTされません。

よって、以下の事が発生します。
① フラグがある事により、
『HEADのテーブル』にデータ有り、『HEAD以外のテーブル』にデータ無しとい
うケースがある。

② 『HEAD以外のテーブル』がINSERT、UPDATEされるかは、
『HEADのテーブル』のレコードの有無で、判断される。

この2点により、
①のようなデータに対し、『HEAD以外のテーブル』にデータ有りといった変更
（「0：発売なし」→「7：発売あり」）があった場合、
②の条件で、『HEAD以外のテーブル』にはUPDATE文が走ることにより、
INSERTできないといった状態になっております。

これは、現在の『JV-Data登録クラス』で発生致します。

『HEAD以外のテーブル』に挿入する・しないの判断を設けると、
『HEADのテーブル』のレコードの有無だけで、
INSERT、UPDATEを判断するのはダメということになります。

判断が色々面倒になってくるため、
現在の『JV-Data登録クラス』にもいえることですが、
フラグを判断条件にしないほうがよいというご指摘通り、
INSERTにおいても、フラグの条件を省くべきではないかと思います。

そうすれば、「0：発売なし」→「7：発売あり」、
「7：発売あり」→「0：発売なし」のどちらでも
『HEAD以外のテーブル』のデータは必ず作成・更新されると思われますが、い
かがでしょうか？|

タイトル ： Re^3: 『JV-Data登録クラス』の更新処理について
— —
記事No ： 5248
投稿日 ： 2023/10/10(Tue) 14:13
投稿者 ： JRA-VANソフトサポート

JRA-VANソフトサポート 三木です。
DataLab.サービスをご利用頂きまして誠にありがとうございます。

『HEAD以外のテーブル』に挿入する・しないの判断を設けると、
『HEADのテーブル』のレコードの有無だけで、
INSERT、UPDATEを判断するのはダメということになります。

判断が色々面倒になってくるため、
現在の『JV-Data登録クラス』にもいえることですが、
フラグを判断条件にしないほうがよいというご指摘通り、
INSERTにおいても、フラグの条件を省くべきではないかと思います。

ご指摘通り、フラグを判定条件にしないほうが
上位データ提供元の値に左右されないかと存じます。

ご指摘の報告が正しいと判断し、
今後、サンプルプログラムについて、再考させていただきます。

どうぞよろしくお願いいたします。|

タイトル ： Re^4: 『JV-Data登録クラス』の更新処理について
— —
記事No ： 5249
投稿日 ： 2023/10/10(Tue) 16:37
投稿者 ： まさ

JRA-VANソフトサポート 三木様

ご回答頂きまして、ありがとうございます。

ご指摘通り、フラグを判定条件にしないほうが
上位データ提供元の値に左右されないかと存じます。

よくよくみると、「発売フラグ単勝」だけではなく、
「馬番」が空白かどうかという条件でINSERTしておりました。

ありえるかどうかわかりませんが、データ提供ミスで、
後で馬番が追加されたら、やはりINSERTされなくなるので、

UPDATEではなく、DELETE-INSERTで対応しようと思います。
そうすれば、フラグ判定や馬番空白判定があっても、
追加されないといった事象はなくなるでしょうから・・

どうもありがとうございました。|

タイトル ： Re^5: 『JV-Data登録クラス』の更新処理について
— —
記事No ： 5300
投稿日 ： 2024/08/07(Wed) 15:47
投稿者 ： JRA-VANソフトサポート

JRA-VANソフトサポート 高川です。
DataLab.サービスをご利用頂きまして誠にありがとうございます。

大変お待たせいたしました。
本件につきまして、本日サンプルプログラムを修正版に変更しております。
なお、本件つきましては横展開にて同等の誤りが発見されたため、そちらも併
せて修正しております。

対象プログラム
clsImportH1.vb
clsImportH6.vb
clsImportH1.cpp
clsImportH6.cpp

ご不便おかけし、申し訳ございません。

どうぞよろしくお願いいたします。|