2004/04/30
思い立って７年前に作ったまま全くメンテしてなかった所内イントラデータベースを弄り始めた。
当時はhttpdもApacheでなかった、データベースもDOS時代を引きずってDBASEだったが
JPerlは使えた、それでJPerlからODBC経由でDBASEにアクセスするCGIをこしらえた。
ODBCドライバ＝INTERSOLV[現DataDirect社？]製を(所長に)買って貰うのに「用途とその必
要性」についての説明で一悶着あったのを覚えている。
でサーバ機が何代か替りhttpdの更新があってもCGIはそのまま引継いでデータはそこそこに
膨らんでいるし多分ゴミも入ってる、おまけに下手にレコード削除とかされると悲惨な結果
になりそうであえて削除インターフェイスは作らなかった。
つまり手を付けたくない状態ではあるのだ。
長いこと放置(データもだけどむしろ自分の頭の方)したのでODBCとかSQLとかについてはほと
んど記憶喪失、ここから始めないといけない。
今メンテしてもまた無メンテ状態が長く続くと予想される、これを機にデータ形式の変更を
画策、当時は事務所で使えるAccessが2.0(16ビット版)しかなくてJetデータベースの選択肢
というのは無かったが、今ならコレが無難でしょうね。
MySQLというのも候補だがいざという時「ちょっとサーバ機ローカルで保守」する事を可能に
しておかないとそれこそまたメンテ不可。保守用のGUIお手軽クライアントがあれば第一候補
に上げても良い。
データコンバートはAccess上でやったので即終る、単一テーブルのDBASEで良く今まで保った
というのが感想。
それとCGIの書換え、もともとODBC経由だからDSNをJet用ODBCドライバのものにすれば終りの
はずだった。(DAOやらADOで操作するのも中味はこれか？）
本題。
CGI実行環境をJPerlからPerl5.8に変更しようなどと考えたのがまづかった。
Perl5.8ではJPerl同等の日本語処理環境がなどという宣伝文句に釣られ、またWIN32上の
ActivePerlも5.8系が出てから１年以上になるしそろそろと思っていたが。
use encoding ' ';
use Encode;
使い方がよくわからないのだ、一般的には
use encoding 'shift_jis', STDOUT => 'shift_jis';
などとすれば良いのだろうけど動作させると何か変、出力されたものはutf8になってる。
普通にファイル入出するのには不都合がないし期待した結果が得られるのに、ODBCモジュール
とかJetエンジンと連携させるとダメになるみたい。
いろいろ試してもうまくいかない、あきらめて最後に
# use encoding ' ';
行を無くしてしまったらうまくいった、何故だ？理解不能。