中央競馬の予想や購入したもののメモなどを書いて行こうかと。まあ、個人的なメモ的なブログです。
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
[0回]
SQLiteの接続文字列でのdatabase is lockedな問題だけど、なぜ起きているのか不明な感じではあるが、疑わしいのはMicrosoft(笑) そもそも、この会社何? YESかNOかで言えば、確実にNOなんだが、今のPCではってか、今でもlinuxへの逃げやChromeなんかがあるにしてもMS必須なんだよね～orz で、疑ったのは
Microsoft.EntityFrameworkCore.Sqlite
Microsoft.EntityFrameworkCore.Tools
の謎w 中途半端なこれらのおかげで随分と苦労している気がして、今回、新たに別プロジェクトを作成してMicrosoftの妨害を阻止してみました。
System.Data.SQLite.Core
これ1本のみでの開発に挑戦してみようかと作業を進めています。つまり、Migration無しで自力でデータベース構築する訳ですが、まあ、CREATE文を全てのテーブル分用意すれば良い訳ですが、これもまた、かなりの作業です。一番気になっている出走別着度数テーブルの1,700項目超えなんですが、ここは既に済ませ接続文字列で色々テストすると、これまでのdatabase is lockedは消えました^^ でもね、処理スピードは不変orz
それでも、database is lockedの犯人はMicrosoftなのは確定です。
[0回]
昨年の11月9日にラウンチイベントとかがあり、リアルタイムでそのイベント見たりしてたんですが、それ以前にインストールしていたPreviewが悪かったのか、インストーラーが悪かったのか...数日前に確かPreview 2.0とかのアップデートがあり、もれなくしてたんですが、その後、なんかToolなんだかがうまくロード出来ません的なエラーが出る様になり、いっその事、2019も含め、アンインストールして、更にインストーラーが２つあったんですがそれも削除。インストーラーから再度最新のダウンロードをした所、Version 17.0.4っというPreviewが付かないバージョンがインストールされました。
これはなかなかの想定外w これ、昨年のラウンチ以降にアンインストールしてからの再度インストーラーからの更新していれば、なっていたのかと思うと、ここまで何してたんだろって思うorz
まあ、何が変わっているかは未体験で、今後分かってる来るとは思いますが、悪くなってなければ良いですけどね(*^^)v
で、先日の２度目のフルセットアップは14時間程度で終わり、まあ、大体問題無い感じで、出来たDBファイルが65GB。これに更新掛ける処理のデバックに入ったんですが、テスト毎に元のファイルに戻すのに65GBのコピーはなかなか時間が掛かるorz これが作業進める気力を削ぎます。本業に復帰してるので、先日までの様に時間取れないのもあるんですが、それでも出来る限りここまで来たので進めたいです^^
[0回]
開発中のDBアプリのデータ登録部がほぼ完成したので昨日初のフルセットアップに挑みました。なんと!プロセス開始から12時間51分52秒とかorz いや、実際には数日覚悟してたから逆にめっちゃ早かったんですが、これ、テストで何度もするって訳にはいかないので十分に修正箇所チェックしてやる必要がある。で、出来上がったSQLiteファイルは54GBです! ただこれ、実行中にログ見てて1年分毎に取得する様にしてたんですが、何故か期間を20200101000000-20201231235959としても毎年12月分が取得出来ないで35年分程度のデータ登録された。こちらが何処かが悪いのか提供元の問題なのか切り分けなきゃならないので、そのテストを。
今回の初施行ログがワードパットデータセーブしたんですが、124KBと別に大きいとは思えないのですが、ワードパットが悪いのかOSが悪いのか開いてサクサク動くまでに数十分掛かる。まあ、Visual Studio自体も動きが怪しい感じで...現在使っているPCは16GBしか積んでない。2年前に組む時に16GBDIMMの在庫が無いと言われ、渋々8GBで妥協したのが今になって仇になるとはorz 資金余裕があれば今なら32GB×2が3万円しないから一気に行きたいかな。
何にしても、悪い所が多いので再チェック!
[0回]
諦めがつかず、別のラッパーのテストもしてみたり^^; 現状に不満が残るまま開発進めるのは少し気が引けるので、以前にも目にしていたSQLite.CodeFirstを試してみる。が、思う様に動いてはくれなかった。自分の理解不足なのかもだが、SQL Server ExpressをVS2019でコードファーストから利用すると別にミグレーションとかしなくても、普通にデータベースが出来てテーブルも作成される感じで滅茶苦茶気に入っていたので、そんな感覚でSQLiteも利用したいってのが心のどこかに引っ掛かりを残してる理由かも。まあ、SQLite.CodeFirstのグーグル先生が見つけてくれた記事では簡単にって事の様でしたが自分には無理。
で、諦めムードで元のSystem.Data.SQLite.Coreでデバッグ。ああ、流石にここまででほぼ必要なソースのコンバートは終わってる感じです。まあ、若干お手軽なコンテキストのAdd()なんか使うコーディングは使わないかもなのでコンバートしてません。
今はテーブルに1,723個の項目があるInsertで"unknown error Insufficient parameters supplied to the command"と言われ、途方に暮れながら何が悪いのか確認中です。Visual Studioでのデバッグは色々と楽に出来る感じなのに、これってどのパラメータでエラーになっているか手作業で確認するしかないのかな? まあ、単に自分が使い方理解してないのかもですが、大変です。
これとは別に今回のコンバート作業から起きた問題がVBでは単にVal()関数でお手軽に文字列から数値に変換してたのが、まあ、C言語由来なのか型にうるさいC#なので、数値といっても型が何かとかで分けたり^^; で、提供元からのデータが"0000"として、これが"#0.0"のデータたとしてVBでは
Val(strIn)/10
ってな感じだったかな。単純なコンバートでは
float.Parse(strIn)/10.0F
になるとは思ったんですが、デバッグしてる時にテーブル覗いてみて本来1.2であるはずのデータが1.199999989みたいな。その昔まだNECで汎用機のFORTRANコンパイラ担当だった頃、東北大学の学生が0.1を10回足しても1にならず、0.9999989的な結果なのはおかしくない?って質問があり、パッチ出してた記憶があるけど、バイナリな世界を理解してると別に不思議な話ではなく、2進数で10進数の0.1が正確に表現しきれない、つまり近似値が使われるんですが、この近似値の誤差が結果に表れるのが原因なんですが、これをふと思い出し、割り算せずに直にデータが変換される様に
float.Pars(Strings.Left(strIn,3) + "." + Strings.Right(strIn,1))
としてみたんです。結論から言えば、どこでどんな処理が内部的に行われているかまでは把握してないし、そもそもMS社が悪いのか、ラッパーの方でなにかしてるのかまでは判断出来ません。MS社の前科から疑うのもどうかとは思うけど、いや、学生時代、NEC PC-8001搭載のN-BASICで宿題してて、大学の端末からやった様に見せかけてプログラム書いて提出したら、見た目のプログラムは間違ってないのに、結果がなんでこんな数字になっているか理解出来ないと教授に言われ、却下されたw これ、単にビル君のお粗末なBASIC精度が原因だったんですけど。ま、それから宿題は当時のTurbo Pascalでやる様になりました。$29.98とかで購入して爆速なコンパイルで精度問題も回避出来ました。MS-DOS以前のCP/M時代の話ですけどね。
で、話それましたが元に戻すと、このコーディングしても誤差は出ました。どこがなんで出しているのか不明なままorz で、これ、提供元のデータが" "だとVBでは問題ないけどってか、数値化後の割り算なら問題ないけど、フォーマット的に小数点打つと" . "的な文字列になりエラーなるんですよ。提供元の初期値的なミスはクレーム上げたいけど、直ぐに対処されるか不明なので自己防衛としてif分で回避するコーディングを全てに行う事に。これが相当な作業なのでまた遅れが出ます。
[0回]
