- このトピックには8件の返信、1人の参加者があり、最後に
により6ヶ月前に更新されました。
8件の投稿を表示中 - 1 - 8件目 (全8件中)
-
投稿
-
お世話になります．返信遅れまして済みません．
当方の環境ではデータ区分がインクリメントされこの現象が再現されないので，更新順を単純に0B15→0B12と時系列順にしてみました．
https://keough.watson.jp/download/mykeibadb3.3(exe_only).zip
mykeibadb.exeをこのファイルと入れ替えて試していただけないでしょうか．
お手数ですがよろしくお願いいたします．丁寧なご対応をいただき、誠にありがとうございます。
（個別の相談にも関わらずexeファイルを作っていただき申し訳ございません🙇）0B15:0B1520241012.rtd
0B15:更新終了
0B12:0B1220241012.rtd
0B12:更新終了上記のようにログに出ておりますのでご想定通りの挙動かと思いますが、
現状開催日（10/12）で1~4レース終了後ですが以下のようなSQL状態になっており、
なぜか2024101204040301（新潟1R）だけが上記exeを起動した時刻にinsert_timestampが更新されており、
それ以外は当日最初に起動したときのinsert_timestamp時刻のままになっています。
どうもやはり想定ではない動きをしているように思われます。jravan=# SELECT insert_timestamp, data_kubun, race_code, race_bango jravan-# FROM umagoto_race_joho jravan-# WHERE kaisai_nen = '2024' AND kaisai_gappi = '1012' jravan-# ORDER BY race_bango ASC; insert_timestamp | data_kubun | race_code | race_bango ---------------------+------------+------------------+------------ 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 10:51:31 | 2 | 2024101208050301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 11:46:55 | 6 | 2024101204040301 | 01 2024-10-12 10:51:31 | 2 | 2024101204040302 | 02 2024-10-12 10:51:31 | 2 | 2024101204040302 | 02 2024-10-12 10:51:31 | 2 | 2024101204040302 | 02 2024-10-12 10:51:31 | 2 | 2024101204040302 | 02 2024-10-12 10:51:31 | 2 | 2024101204040302 | 02 2024-10-12 10:51:31 | 2 | 2024101204040302 | 02 2024-10-12 10:51:31 | 2 | 2024101204040302 | 02 2024-10-12 10:51:31 | 2 | 2024101204040302 | 02 2024-10-12 10:51:31 | 2 | 2024101204040302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02 2024-10-12 10:51:31 | 2 | 2024101208050302 | 02（以後省略）
※念の為確認したところ、データ検証ツール(速報系)で上表冒頭のデータ区分2になっている
2024101208050301（京都1R）のレース情報(成績確定後)を取得しにいくと
SE62024101220241012080503011012022106189…と続く情報がデータ区分6でダウンロードできています。ただ
当方の環境ではデータ区分がインクリメントされこの現象が再現されない
と頂いておりますので、私の環境に依存した問題
（exe側ではなく受け取るpostgreSQL側で上書きができていない等）
を考慮すべきかと思いますので、継続して原因を調査してみます。ご相談にのってくださり、大変ありがとうございます。
引き続き何卒よろしくお願い致します。nudaさん
ご連絡ありがとうございます．
nudaさんだけでなく同じ現象が起こっている方がいるかもしれませんので，こちらでも再現する条件等を見つけたいと思います．
今後ともよろしくお願いいたします．続報を記載しておきます。
取得する時間は関係なく、最もRACE_CODEの値が若い1レースだけが更新され、
それ以外は更新されないということが起きているようです。insert_timestamp | data_kubun | race_code | race_bango ---------------------+------------+------------------+------------ 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-13 22:14:05 | 6 | 2024101305040301 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01 2024-10-12 11:46:53 | 2 | 2024101308050401 | 01さらに調査を進めます。経過方向まで、何卒宜しくお願い致します。
nudaさん
有難うございます．
今考えられる策が一つあり，コード変更を試そうと思いますので，週末まで待っていただきたく．
(速報データが更新されるタイミングでないと試せないため)
よろしくお願いいたします．nudaさん
0B12と0B15のデータを，開催日単位(同一開催日の全開催場の全レース)でなくレース毎に取ってくるように変更してみました．試してみていただけますか？よろしくお願いいたします．
https://keough.watson.jp/download/mykeibadb3.4(exe_only).zipKeoughさん
ご丁寧な対応を頂き、誠にありがとうございます！
現在２Ｒまで確定したタイミング（３Ｒ出走前）です。
早速リアルタイムで試してみました。jravan=# SELECT insert_timestamp, data_kubun, race_code, race_bango jravan-# FROM umagoto_race_joho jravan-# WHERE kaisai_nen = '2024' AND kaisai_gappi = '1020' jravan-# ORDER BY race_bango ASC; insert_timestamp | data_kubun | race_code | race_bango ---------------------+------------+------------------+------------ 2024-10-20 10:51:37 | 6 | 2024102008050601 | 01 2024-10-20 10:51:37 | 6 | 2024102008050601 | 01 2024-10-20 10:51:37 | 6 | 2024102008050601 | 01 2024-10-20 10:51:37 | 6 | 2024102008050601 | 01 2024-10-20 10:51:37 | 6 | 2024102008050601 | 01 2024-10-20 10:51:37 | 6 | 2024102008050601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040601 | 01 2024-10-20 10:51:37 | 6 | 2024102008050601 | 01 2024-10-20 10:51:36 | 6 | 2024102005040601 | 01 2024-10-20 10:51:36 | 6 | 2024102005040601 | 01 2024-10-20 10:51:36 | 6 | 2024102005040601 | 01 2024-10-20 10:51:36 | 6 | 2024102005040601 | 01 2024-10-20 10:51:36 | 6 | 2024102005040601 | 01 2024-10-20 10:51:36 | 6 | 2024102005040601 | 01 2024-10-20 10:51:36 | 6 | 2024102005040601 | 01 2024-10-20 10:51:36 | 6 | 2024102005040601 | 01 2024-10-20 10:51:36 | 6 | 2024102005040601 | 01 2024-10-20 10:51:36 | 6 | 2024102005040601 | 01 2024-10-20 10:51:37 | 6 | 2024102008050601 | 01 2024-10-20 10:51:36 | 6 | 2024102004040602 | 02 2024-10-20 10:51:36 | 6 | 2024102004040602 | 02 2024-10-20 10:51:36 | 6 | 2024102004040602 | 02 2024-10-20 10:51:36 | 6 | 2024102004040602 | 02 2024-10-20 10:51:36 | 6 | 2024102004040602 | 02 2024-10-20 10:51:36 | 6 | 2024102004040602 | 02 2024-10-20 10:51:36 | 6 | 2024102004040602 | 02 2024-10-20 10:51:37 | 6 | 2024102008050602 | 02 2024-10-20 10:51:37 | 6 | 2024102008050602 | 02 2024-10-20 10:51:37 | 6 | 2024102008050602 | 02 2024-10-20 10:51:37 | 6 | 2024102008050602 | 02 2024-10-20 10:51:37 | 6 | 2024102008050602 | 02 2024-10-20 10:51:37 | 6 | 2024102008050602 | 02 2024-10-20 10:51:37 | 6 | 2024102008050602 | 02 2024-10-20 10:51:37 | 6 | 2024102008050602 | 02 2024-10-20 10:51:37 | 6 | 2024102008050602 | 02 2024-10-20 10:51:37 | 6 | 2024102008050602 | 02 2024-10-20 10:51:36 | 6 | 2024102005040602 | 02 2024-10-20 10:51:36 | 6 | 2024102005040602 | 02 2024-10-20 10:51:36 | 6 | 2024102005040602 | 02 2024-10-20 10:51:36 | 6 | 2024102005040602 | 02 2024-10-20 10:51:36 | 6 | 2024102005040602 | 02 2024-10-20 10:51:36 | 6 | 2024102005040602 | 02 2024-10-20 10:51:36 | 6 | 2024102005040602 | 02 2024-10-20 10:51:36 | 6 | 2024102005040602 | 02 2024-10-20 10:51:36 | 6 | 2024102005040602 | 02 2024-10-20 10:51:36 | 6 | 2024102005040602 | 02 2024-10-20 10:51:36 | 6 | 2024102004040602 | 02 2024-10-20 10:51:36 | 6 | 2024102004040602 | 02 2024-10-19 14:21:21 | 2 | 2024102004040603 | 03 2024-10-19 14:21:21 | 2 | 2024102004040603 | 03 2024-10-19 14:21:21 | 2 | 2024102004040603 | 03 2024-10-19 14:21:21 | 2 | 2024102004040603 | 03 2024-10-19 14:21:21 | 2 | 2024102004040603 | 03このように、2Rの情報までデータ区分が6になっているので、最新情報が取れているようです！
内部を見たところでもumagoto_race_johoテーブルの着順やタイムが速報で取得できていました。これで当日情報を活かした分析ができるようになります！
リアルタイム検証が必要なため開催中しかテストできない関係上、
開発ご更新においてもお手数をおかけしたかと存じます。
そのような手間のかかるご相談であったにも関わらず、
快くご対応をくださり、大変ありがとうございました。これからもmykeibadbを活用して分析と予想を楽しみます！
今後ともどうぞ宜しくお願いいたします。
8件の投稿を表示中 - 1 - 8件目 (全8件中)
- トピック「速報データの更新挙動について」には新しい返信をつけることはできません。