大分長いこと使用してきたＭｙＳＱＬによるＨＡＭ ＬＯＧも移動運用などで
使用した時、使い勝手が悪いので変更することにした。
使い勝手が悪いのはＭｙＳＱＬのせいではないのですが、
通常、ＱＳＯ結果の処理は、ホームにあるデスクトップで行い、
移動運用時はノートＰＣで行っています。移動運用に出かける前に
デスクトップのＤＢの中身をＣＳＶに落とし、ノートＰＣのＤＢに
ＣＳＶから書き込み、移動運用から帰ってきたら逆のことを行い整合性を
保つようにしています。
ＭｙＳＱＬはサーバー型のＤＢＭなのでどちらのＰＣからもアクセスで
きるようにすればこのような面倒なことは必要ないのですが、
移動運用場所によってはアクセスできないことも考えられるので、
このような方法で行っていました。
（ＭｙＳＱＬがいくら無償とはいえ私のような使い方ではもったいない
ということです）
このようなＤＢＭでなくもっと簡便なＤＢはないものかと探してみると
ＳＱＬｉｔｅというＤＢＭがありこれは便利ということで、別のＤＢＭの
勉強も兼ねて使用してみることにしました。
このＳＱＬｉｔｅというのはクライアント内だけのＤＢということで
ポータビリティーが良い。というよりＤＢを自分で認識でき、
ＤＢ（単なるファイル）を別ＰＣにコピーするだけでよいので楽である。
もっともＤＢＭというよりＳＱＬが使用出来るデータシステム
といったような物のようである。
しかし、以前にも書いたがこのようなデータシステムを自分で作るとなると
結構な労力が必要になるので無償で簡単にＳＱＬが使用できるのは
ありがたいことです。
ただし、ＭｙＳＱＬのようなセキュリティーについては期待は出来ないが
もともとオープンなＱＳＯデータで自分のＰＣ内だけ使用するので、
必要性を感じていないのでよしとしました。。
ということで、ＨＡＭ ＬＯＧのＳＱＬｉｔｅ化に着手するわけですが、
まったくプログラムの書き直し（ロジック）は予定していないので、
出来ればちょこっと手を入れるだけで良ければ助かると思い、
テスト プログラムを作成し実行してみると
思っていた以上に互換性があるので早速取り掛かりました。
（ＳＱＬが標準化されているのでＳＱＬの文法あたりは変更しなくてすみそう）
実際に変更を始めてみるとＳＱＬの文法は互換性が高いが、
機能上の互換性がないものがあり、情報も少なく意外と時間が
掛かってしまった。
主な相違は：
１．起動などはＰＣ ＤＯＳの世界と同じでコマンドプロンプトで実行
ＭｙＳＱＬはタスクとして実行させておく必要があったが、
ＳＱＬｉｔｅは必要がない。
このあたりも大分違いを感じるがなんとなく軽さを感じる
２．ＣＳＶデータの取り込み、吐き出しのＳＱＬコマンドが無い
ＭｙＳＱＬではＳｅｌｅｃｔ文で簡単にＣＳＶデータを取り込んだり、
吐き出したりすることが出来るがＳＱＬＩｔｅにはこのような
ＳＱＬ文が存在しないのでちょっと工夫が必要となる。
コマンドラインではＩｍｐｏｒｔコマンドが使用できるのですが、
今までと同じようにプログラムから実行したかったので
機能の追加をしました。
３．マニュアル（Ｗｅｂ上の初心者よう説明など）では、大文字小文字
の扱いが違うようでこの点も変更したが、使い方なのかバグなのか
いまいち思ったようにならずロジックで対応した部分もあった。
４．実行結果をコマンドラインで確認するとＳｊｉｓ（全角）が化けてしまう
たぶんコマンドがあるのだろうが見当たらないので今はあきらめて
使用している。
５その他ちまちまとあったような気がするが何とか移植は完了し
しばらく使用してみることにした。
移植に当たり、折角なので使用していない機能の削除やロジックを
見直し冗長性の高いロジックなどを変更などして大分スリムになった。
移動運用で使用してみるとＭｙＳＱＬとほぼ同じ感覚で使用できた。が、
なぜか（？）少し入力が途絶えた後入力するとＤＢが接続できなくなる
トラブルが発生した。再度起動するとＯＫなのだが、調査してみても
原因が不明、しばらく使用してみて同じトラブルがでるようであれば
元に戻す必要があるかもしれない。
また、入力したデータが一部消滅していたのでこちも原因が不明で
不安がある。
ＱＳＯが途切れ、ＰＣを使用しないとき、スタンバイ状態にしたりしているので
そのせいかもしれないがいずれにしても困るので調査をしてみる。
