SQLite.CodeFirst

諦めがつかず、別のラッパーのテストもしてみたり^^; 現状に不満が残るまま開発進めるのは少し気が引けるので、以前にも目にしていた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分で回避するコーディングを全てに行う事に。これが相当な作業なのでまた遅れが出ます。