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経由でリンクテーブルを使用してデータを書き換えることは、速度を犠牲にしてコードの汎用性を高めていると言えます。（バカにしたもんじゃないよ！でも、稼動しているデータベースを変えることってある？）
給与計算プログラムはクライアント・サーバー型でなく全くローカルで使用するので、ローカルで使用するデータベースが何らか必要です。最近、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経由でリンクテーブルを使用してデータを書き換えることは、速度を犠牲にしてコードの汎用性を高めていると言えます。（バカにしたもんじゃないよ！でも、稼動しているデータベースを変えることってある？）