- このトピックには8件の返信、1人の参加者があり、最後に
により1ヶ月、 1週前に更新されました。
-
投稿
-
度々の質問となり誠に恐れ入ります。
（3.2バージョンアップデート、ありがとうございます。）無事、蓄積系データについては利用ができているのですが、
速報系データが更新されるタイミングについてご確認したく存じます。例えば速報系データとしてSE[馬毎レース情報]を設定してmykeibadbを起動した場合、
JRA-VAN公式仕様書の45ページ記載のように、速報レース情報(成績確定後）0B12と速報レース情報(出走馬名表～）0B15が関係するため、0B12[YYYYMMDD].rtdや0B15[20240929].rtdのダウンロード後にUMAGOTO_RACE_JOHOテーブルに登録されるものと思います。これをSQL側から見ると、UMAGOTO_RACE_JOHOテーブルにおいて開催日当日のレースを示す行においては、
速報に応じて情報が変化していく
（https://keough.watson.jp/wp/3-%e9%a6%ac%e6%af%8e%e3%83%ac%e3%83%bc%e3%82%b9%e6%83%85%e5%a0%b1/
のDATA_KUBUNで言えば当日は2→3→4→5→6と変化しながら各列が埋まっていき、月曜に7となり埋まりきる）
という理解をしておりますが、手元の環境では何度mykeibadbを起動しても（今日は開催日9/29でしたが）最初に取得した朝の1R確定後ぐらいのタイミングのデータからテーブルが更新されていません。
例えば、現在夜19時ですが、今mykeibadbを起動しても、2R以降はまだ出馬表(DATA_KUBUNが2で着位情報やタイムなどは空欄)の状態になっております。＜mykeibadb(v3.2)のログ＞
mykeibadb Ver.3.2 for PostgreSQL Copyright(c) Keough
－－－蓄積系データ(通常データ)－－－
TOKU:更新データ無し
RACE:更新データ無し
DIFN:更新データ無し
BLDN:更新データ無し
MING:スキップ
SNPN:スキップ
SLOP:更新データ無し
YSCH:更新データ無し
HOSN:更新データ無し
HOYU:更新データ無し
COMM:更新データ無し
WOOD:更新データ無し
－－－蓄積系データ(今週データ)－－－
TOKU:更新データ無し
RACE:更新データ無し
SNPN:スキップ
TCVN:更新データ無し
RCVN:更新データ無し
－－－速報系データ－－－
0B12:0B1220240929.rtd
0B12:更新終了
0B15:0B1520240929.rtd
0B15:更新終了
0B30:スキップ
0B20:スキップ
0B11:スキップ
0B14:スキップ
0B13:スキップ
0B17:スキップ
0B51:スキップ
終了です。何かキーを押してください。
＜SQL＞
SELECT * FROM public.umagoto_race_joho
ORDER BY race_code DESC LIMIT 100
→例えば出力されたもののrace_codeが2024092907030912（本日の中京12R)のものでもいまだdata_kubunが2のままです。JRA-VAN\Data Lab\data\cache内の0B1220240929.rtdや0B1520240929.rtdを削除して
mykeibadbを起動すると、再度同じrtdはダウンロードされるのですが、
postgreSQLの出力するログ等を見る限りおそらく朝の時点で一度更新した情報より後の情報が更新されておらず、
朝の時点で登録済の情報と同じ情報がinsertされており、
それ以降に更新された当日速報の情報（本日のレース結果など）がinsertされている様子が見当たりませんでした。※一応念の為公式のDataLab検証ツールで本日の速報データを確認してみると
最終行が冒頭SE6202409292024092907030912となっており、data_kubunが6のものが得られていますので、
mykeibadb側の挙動でこれがSQL側に転送されていないのかなと思い投稿した次第です。
私の手元の環境や理解のせいかもしれず大変恐縮なのですが、ご確認をさせていただけますと幸いです。※環境：Windows 10ローカル環境で検証 PostgreSQL 16
SQLコマンドはpgAdminおよびPowerShell環境からテスト検証蓄積系だけでも十分いろいろと自分の分析システムを作って楽しめているのですが、
将来的には、mykeibadbを開催日はレースごとに起動・起動して、SQLからリアルタイムで出走済レースの情報を得て、当日のトラックバイアスを計算して後ろのレースの予想に活かそうかと思い、ご相談させていただきました次第です！
ご相談が続き恐れ入りますが、もしよろしければご確認をいただけますと幸いです。お世話になります．返信遅れまして済みません．
当方の環境ではデータ区分がインクリメントされこの現象が再現されないので，更新順を単純に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を活用して分析と予想を楽しみます！
今後ともどうぞ宜しくお願いいたします。
- トピック「速報データの更新挙動について」には新しい返信をつけることはできません。