クライアントとしてのLinux

Redhat9.0をサーバーとして使用しています。年に１回電源を落とすかどうかですが、安定して動いています。全くすばらしい。

サーバーとしては非常に優れているLinuxも、クライアントとしてWindowsの後継になれるか、というと以前も書いた通りその可能性は現状では零だと思います。
何と言ってもLinuxのクライアントとしての問題点は下位互換性だと思います。頻繁にバージョンアップが行われますが、現在、XWindowで使用しているプログラムが新しいバージョンのLinuxで使用できる可能性は非常に低いです。
サーバーとしてXWindowを使用しないプログラム（PostgreSQLなど）はLinuxのバージョンが異なっても大抵動作するので、互換性について問題がないように一見、考えてしまいますが、XWindow上で動作するGnome、KDEを使用したプログラムの下位互換性となるとバイナリレベルではまず、保証されないと考えた方が無難です。（AtokXが動かないよ．．．Kylixが動かない．．．．）
「オープンソースなんだから、ソースに手を加えて動作するように自分で修正すればいいじゃないか！」と言われれば、それまでですが、サーバーならともかく万人が使用するクライアントにそうしたスキルを求めるのは無理です。

その点Windowsは下位互換性は非常に重要視しています。Windows95で動作するプログラムはWindowsXPでもまあ、動作します。

実際、現在のLinuxの開発体制で下位互換性を求めるのは無理というものでしょう。有志のプログラマーがボランティアで作成したプログラム群を基礎としたLinuxで、下位互換性という足かせを付けた開発を求めるのは、プログラマーの興味を半減させてしまうでしょう。それでも、Linuxに一定の規格を持たせようという試みが行われています（Linux Standard Base ）。この試みが成功して下位互換性を意識した開発が行われるようになればLinuxのクライアントとしての将来は明るいのですが。また、同時にそうしたことが行われて、開発者にチャンとしたメリットがあるシステムができれば良いと思います。

Accessでよく使った関数等

テキストに書いて無くて良く使用する関数等々をいくつか上げてみます。

１．NZ()
関数NZは非常に良く使用します。レコードセットを開いてみて、nullの場合バリアント型以外の変数型にはフィールド値を格納することができません。そのため、例えば下記のようにします。
Long型の場合は lngD = NZ(Var,0)
String型の場合は　strD = NZ(Var,"")
ヘルプには0や""は自動で判断して格納するように書いてありますが、0、""　はハッキリ明示した方が良いです。

２．Trim()
データベースに格納されたデータが文字列の場合、例えばvarchar(100)なら、100バイト分の文字列が返ってきます。実際には全角１０文字なら残り80バイトは空白が格納されています。文字列を接続して加工する場合など、空白が入っていると期待した文字列が得られないので、下記のようにします。
strD = Trim(rst!Str)

３．１の場合、２の場合の複合として、Trim()はnullが入っている場合はエラーになってしまうので、
strD = Trim(NZ(rst!Str,""))
なんてします。

４．Docmd.Open のOpenArg
フォームを開く際、OpenArgは良く使用します。例えば商品選択フォームから商品CDを選択する場合、商品CDを格納するフォームごとに処理が異なることがあります。同じ商品選択フォームを使用して異なるフォームに商品CDを格納して、異なる処理をする場合、開いたフォームを識別するためにOpenArgを使用します。
最初これを知らなくて、Public変数を使用してオープンフォームの識別をしていましたが、選択フォームからさらに別フォームを開いた場合（商品修正フォームを開いた場合など）、オープンフォームを識別していた変数の値が失われてしまい、非常に処理が煩雑になってしまいます。呼び出しフォームをOpenArgを使用して識別していれば、OpenArgの値は失われることがないので非常に便利です。

プログラム作成におけるAccessのポジション

Accessで販売管理プログラム、給与計算プログラムの作成があらかた済んでしまったので、ひまになってしまいました。また、同時に給与計算プログラムは給与計算、課税計算、社会保険料計算といったことを良く知らないでプログラムを作成し始めてしまったので、基本的な部分でまずいところがあり、修正するよりいっそ書き直した方が良いか、と思うようになりました。Accessで同じように書くのは芸が無いのでこの際、シャアウェアとして書き直そうかと思ったりして、今まで読んだことも無いプログラムのライセンスを読んでみました。

給与計算プログラムはクライアント・サーバー型でなく全くローカルで使用するので、ローカルで使用するデータベースが何らか必要です。最近、PostgreSQL8.0がでてWindowsでも簡単にPostgreSQLが動作するようになりました。しかし、20人程度の給与計算にはさすがにプログラムが大きすぎます。Firebirdが軽そうなので、データベースについては、Firebirdが良いかなと考えています。どちらもフリーなので再配布については問題なさそうです。

さて、シェアウェアプログラムを何で作るかとなると、Accessはさすがに不向きです。Accessではコンパイルして、mdeファイルはできますが、exeファイルはできません。動作させるにはAccessそのものが必要なので、シャアウェアとしては向かないと思います。となるとVisualBasicしか、使える（自分が使用できるスキルのある）言語がないので、VisualBasicのライセンスを読んでみました。VisualBasicはexeファイルの作成が可能ですし、動作に必要なdllも自由に再配布できます。シャアウェアの作成が可能なライセンスです。VisualBasicを使うのならデータベースはMDEが一番向いているかと思いライセンスを調べてみると、再配布はできないことになっています。

給与計算プログラムをシェアウェアとして作るならVisualBasic+ODBC+Firebirdかな、と思っています。（FirebirdのODBCドライバーの日本語処理が問題ないかはこれから確認してみます。）

話は変わりますが、VisualBasicのライセンスを読んでみて驚いたのは、「Accessと同じものを開発してはいけない。」という項目があったことです。販売管理プログラムを作成する際、Accessで作るかVisualBasicで作るか悩んでいた時期がありましたが、実際、使ってみるとAccessで作成する方がはるかに簡単です。VisualBasicのライセンスを読んでみてAccessはVisualBasicのデータベース関連の機能を特化したものという位置付けがハッキリしました。
そういう目でAccessを見てみると、今回シェアウェアを作成しようとして、問題になりそうな部分が完全に解決されています。

１．ローカルなデータベース機能
２．簡易な印刷機能

もし、クラアント・サーバー型の販売管理プログラムの作成をVisualBasicで行った場合、データ集計中にテンポリーテーブルを作成しようとすると、VisualBasicそのものにはデータベース機能はないので、何らかローカルにデータベースを用意しなければなりません。Accessは堅牢とは言えないにしても、クライアントがローカルでデータベースを使用したい場合には手間いらずです。
印刷に際して、テンポラリーテーブルを用意しなければならないことは多いですが、ローカルなデータベース機能が無ければ、サーバーにテンポラリーテーブルを作ることになります。印刷終了後、テンポラリーテーブルは削除しますが、その領域はPostgreSQLではvacuumで開放されません、reindexして始めて使用可能になりますが、実際、運用時にreindexするケースはあまりありません。reindexを行おうとすると、シングルユーザーpostgresから行わなければならないので、その間、他のユーザーから使用不能になってしまいます。私自身、運用開始時は「毎日、vacuumして週末にreindexかな。」と思っていましたが、実際に使ってみると、週一回のvacuumで十分なんです。それで速度は特に落ちることはありません。新規レコード3000／月程度です。また、レコードを削除するということはほとんど無いのです。
また、帳票の作成はVisualBasicならクリスタルレポートを使用することになりますが、Accessの印刷機能は優れものと定評があります。クリスタルレポートは少し使用したことがある程度ですが、Accessで帳票を作成した方が簡単と思います。（クリスタルレポートで作成したプログラムは再配布可能だったと思います。）
VisualBasicで開発したプログラムは配布可能だが、こういった機能をそなえたAccessが配布できないというのはまあ、納得できることです。VisualBasicにはない機能が、Accessにはあるのです。
また、デバック時にしてもインタープリターなので、プログラムが止まれば止まった部分のコードをハイライトしてくれます。直ぐ、デバッグに入れます。自分で作って自分で使用するならこれは非常に便利です。コンパイルされたものではこうはいきません。

また、データベースプログラムをPostgreSQLからFireBirdに変更しようとした場合、AccessでODBC経由でリンクテーブルを使用してデータの書き換えを行っているなら、プログラム修正は全く必要ありません。リンクを取り直すだけです。ODBC経由は速度的が遅いのでプロは使用しないでしょうが、ネイティブドライバーを使用すると、ドライバーの仕様でコードの書き方が変わってくるので、データベースの変更を行おうとするとコードを書き換えなければなりません。その点、リンクテーブルを使用していれば、コードの変更は必要ありません。ODBC経由でリンクテーブルを使用してデータを書き換えることは、速度を犠牲にしてコードの汎用性を高めていると言えます。（バカにしたもんじゃないよ！でも、稼動しているデータベースを変えることってある？）