育休から復帰後、64bit版のWindows Server　2003のインストール作業をすることになりました。インストール自体は、32bit版とさほど変わらず、すんなり終了。OSのアーキテクチャなんぞにとても疎い私は、単純に「32bitより早くてパワフルな環境になるんだろうな～」とウキウキしつつ、その後、SQL Serverその他のプログラムをインストールしました。

必要な環境が出来上がったところで、部署のみなさんに「64bit版OKになりましたので、使って下さいね～」と宣言。使い勝手はどうか、反応を楽しみにしていたんですが、何やら落とし穴が。

当たり前だと言われると、そうなんですが、64bit版だと動かないプログラムもあるんですね。

32bit環境下で、他部署のPostgreSQLのデータをODBCドライバを使って取り込む処理をしていたのですが、それを64bit環境下で実行するようにしようとしたところ、ODBCが64bit対応していないそうで、「移行できないよ～！」との声が。（ソースからコンパイルすれば良いらしいのですが、皆そこまでの気力は無し.....）

ただ、私の担当していた処理では無かったので、「そうですか、それは残念ですね」と軽く流しておりました。

その後、私もこの64bit環境下のSQL ServerのSQL Agentを使って、とあるジョブを仕込むことになりました。ジョブはPerlで書いたプログラムで、OSコマンドを実行するもの。
この時、せっかくだから、Windows Script Host化してみようという話になりました。Perlのコマンドから、イベントログにエラーメッセージなどを書き出せるからです。

一応コードが出来上がり、自分用の開発機でのテストも上手くいったので、「じゃあ、64bit下で動かしてみよう！」と言うところまでたどり着きました。（この時は、32bit版のWindows Server2003 & ActivePerlという組み合わせ。）

ところが、これが動かない....。

ActivePerlのインストールは問題ありませんでしたし、WSH化する前のPerlに関しても、普通に実行できました。ですが、WSH化すると64bit下ではエラーになって動かないのでした。

VBScriptで書いたものは、何事も無く実行できるので、どうもPerlScriptのエンジンが問題のようです。もう一台あった64bitのサーバで試してみても、同じ状況に。まさか自分も同じ罠にはまるとは思っていませんでした....。

解決方法はあるのかもしれませんが、探す気力が無くて、結局WSH下は諦めました。（※いろいろ検索したりしてみたのですが、同じようなトラブルにはまっているという情報が見つからなかったこともあり、断念。そもそもPerlで無くVBで書けば良いんじゃないの、と言われると、Windowsのプログラミングに疎い私にはこれまた辛いのです。他に64bit環境でPerlScriptを使っている方はいらっしゃるのでしょうか？）

上記の経緯を踏まえて、SQL Agentに登録したジョブで、64bit下で実行できないものに関しては、「他のサーバで実行させることにすれば良いのよね」という考えにたどり着いたのですが、これはこれで、設定するには私には敷居の高いものなのでした....。

＃久しぶりにポストさせていただきますが、情けない話題で申し訳ありません....。