Access+PostgreSQLで販売管理プログラムを作成し始めて６年になります。
最初はあまりの量の多さに呆然としたものでしたが、最近は一応作るべきものは作ってしまい、あとは工夫次第という段階にきています。昨年は仕訳機能を追加し、今、最初の決算を迎えています。まあ、順調と言っていいと思います。
今年は、リース管理、保険管理の機能を追加しいこうと思っていますが、これは入力する明細行そのものも少ないですし、たいした処理でもなさそうなので、多少もの足りない感じです。それが終わってしまうと、チョットやることが思いつきません。後、やるとすると借入金管理ですが、これは社長がやっているので手をつけられません。必要な時期がくればやることにしましょう。
Accessを６年使ってみて、良いと思うところもあれば、ここが問題だったのかといったことが見えてきました。そういったことを書いてみます。
１．Accessの選択は正しかったか
Accessでプログラムを作成し始める時は、VisualBasicとどちらを選んだものかの迷ったものでした。今、考えるとやはりAccessで良かったのではないかと思います。
事務処理プログラムはやはり印刷機能が大事です。専用伝票から請求書、各種帳票、Accessのレポート機能は相当優れものです。同じことがCrystalReportでもできるのでしょうが、やはりAccessが簡単だと思います。
また、職場で仕事の合間を縫ってデバッグするとなると、コンパイル言語は不向きです。バグがあるなら、そこで停止、修正、直ぐ使用できなければ片手間のデバックなどできません。やはり自作プログラムはインタプリタ言語でなければならないと思います。
２．セキュリティー
そんなAccessを使用する前、調べていると、「リンクテーブルは危険なので、パススルークエリーを使用すると安全」とか「Accessは自動でクエリーを発行してしまうので危険」とか言ったホームページを読んだものでした。当時は、リンクテーブルでアクションクエリーを実行するとデータベースが壊れてしまう、という意味か受っていて、そんなこともなく、いったいなんだったんだろうと思っていましたが、最近やっとその意味がわかりました。データベースが壊れてしまうという意味で危険とか安全とか言っていたのではなかったのです。セキュリティー上、危険、安全という意味だったんです。
Accessの基本はリンクテーブル、リンクフォームです。ODBC経由でリンクテーブルにしてしまうと、簡単にデータベースのテーブルとリンクできてしまいます。そのリンクテーブルを開いて、全レコードを削除してしまうのなんて、お茶の子さいさいです。
Accessでリンクテーブルを使わないでプログラム組むこともできます。その際にはクエリー名を使用せず全てSQLでレコードセットを定義することになります。フォームのレコードソース、レポートのレコードソース、同様です。Accessがお手軽なのはクエリーデザイナーで簡単にクエリーが定義でき、それをクエリー名でフォーム、レポートのソースとして指定できるところです。リンクテーブルが使用できないとなると、その簡便さが全く失われてしまいます。
そうなるとAccessを使用する理由はほとんどありません。VisualBasicで作っても同じことだと思います。
Accessの簡便さはセキュリティーを犠牲にしてなりたっているものだと思います。
３．ロック
Accessを使用する前にさんざん聞いたのは、テーブルをそのままフォームとリンクして編集可能な状態で開いてしまうと、他の端末とロックしてしまうので、そういった使い方は不可、ということでした。それは確かに本当で、テーブルとリンクする時は必ず、編集不可能な状態で開くようにしています。例えば商品マスターを開いて商品CDを選択する時でも、そのフォームでは編集はできないようにして開きます。
それでもロックしてしまう場合があります。大抵の場合、自分自身とロックしてしまいます。特定の行をレコードソースにしたフォームでレコードを編集中、何らかの理由でそのフォーム閉じてしまい、再度、開いたらロックしてしまい編集できなくなる、といったことがよく？たまに？あります。そうなっってしまうと、他の端末からそのレコードを編集しようとしてもロックがかかってしまいます。しかし、その日はそのままにして、翌日会社に行くと、ロックが解除されていて、編集できます。サーバー側のKeepAlive機能のおかげです。
こういったことを防ぐためには、やはりデータベースとの直リンクは避けるべきです。一端、サーバからAccess内のテーブルにデータを落としてそのデータを編集してから、サーバのデータを更新すべきです。
このやり方でまずいところがあるとすると、編集途中でフォームが落ちてしまった場合、編集中のデータが失われてしまうということです。直リンクなら途中でフォームが落ちても編集途中のデータは既に登録されています。
このリスクを考えてもやはり直リンクはすべきでないと思います。
（この症状がでてしまうというのは、直リンクを使用しているからなのですが、そういうテーブルに限って非常にカラム数が多く、ローカルにデータを落としてくるのが面倒なんです。アーアー最初からローカルに落としておけばな～。まあ、次ロックしたら直すことにしよう。）
４．条件付き書式
あらかた終わってしまった、販売管理システムですが、それでもチョコチョコ直しています。特に運用期間が長くなると、不要なデータが増えてきます。商品選択するにしても、しばらく注文が無いようなデータが明細に上がってきて結構煩
わしいものです。
そんな時は条件付き書式でデータを色分けしてやります。直近１年の出荷回数で色分けしてやると、非常に見やすくなります。もっと言うと、あっさり過去１年実績がない商品は非表示にしてやります。こうするともっと見やすいですが、やはり少しやり過ぎの感があります。
Access2007は条件付き書式で画面のちらつきがありません。Access2003でチラチラしていた画面がハッキリ安定した画面になります。その分、画面のRepaintの周期を落としているのでしょう。バッチ処理でデータを更新しながら、レコード番号をテキストボックスに表示させるような処理では、どうかすると数字が停まってしまいます。実際には数字が止まっていても処理は進行しています。
それでも条件付き書式が安定している方がやはり使い易いです。バッチ処理の表示は慣れてしまえば、あきらめもつきますが、商品選択などでの色分けはデータ作成時には必須機能です。
最初はあまりの量の多さに呆然としたものでしたが、最近は一応作るべきものは作ってしまい、あとは工夫次第という段階にきています。昨年は仕訳機能を追加し、今、最初の決算を迎えています。まあ、順調と言っていいと思います。
今年は、リース管理、保険管理の機能を追加しいこうと思っていますが、これは入力する明細行そのものも少ないですし、たいした処理でもなさそうなので、多少もの足りない感じです。それが終わってしまうと、チョットやることが思いつきません。後、やるとすると借入金管理ですが、これは社長がやっているので手をつけられません。必要な時期がくればやることにしましょう。
Accessを６年使ってみて、良いと思うところもあれば、ここが問題だったのかといったことが見えてきました。そういったことを書いてみます。
１．Accessの選択は正しかったか
Accessでプログラムを作成し始める時は、VisualBasicとどちらを選んだものかの迷ったものでした。今、考えるとやはりAccessで良かったのではないかと思います。
事務処理プログラムはやはり印刷機能が大事です。専用伝票から請求書、各種帳票、Accessのレポート機能は相当優れものです。同じことがCrystalReportでもできるのでしょうが、やはりAccessが簡単だと思います。
また、職場で仕事の合間を縫ってデバッグするとなると、コンパイル言語は不向きです。バグがあるなら、そこで停止、修正、直ぐ使用できなければ片手間のデバックなどできません。やはり自作プログラムはインタプリタ言語でなければならないと思います。
２．セキュリティー
そんなAccessを使用する前、調べていると、「リンクテーブルは危険なので、パススルークエリーを使用すると安全」とか「Accessは自動でクエリーを発行してしまうので危険」とか言ったホームページを読んだものでした。当時は、リンクテーブルでアクションクエリーを実行するとデータベースが壊れてしまう、という意味か受っていて、そんなこともなく、いったいなんだったんだろうと思っていましたが、最近やっとその意味がわかりました。データベースが壊れてしまうという意味で危険とか安全とか言っていたのではなかったのです。セキュリティー上、危険、安全という意味だったんです。
Accessの基本はリンクテーブル、リンクフォームです。ODBC経由でリンクテーブルにしてしまうと、簡単にデータベースのテーブルとリンクできてしまいます。そのリンクテーブルを開いて、全レコードを削除してしまうのなんて、お茶の子さいさいです。
Accessでリンクテーブルを使わないでプログラム組むこともできます。その際にはクエリー名を使用せず全てSQLでレコードセットを定義することになります。フォームのレコードソース、レポートのレコードソース、同様です。Accessがお手軽なのはクエリーデザイナーで簡単にクエリーが定義でき、それをクエリー名でフォーム、レポートのソースとして指定できるところです。リンクテーブルが使用できないとなると、その簡便さが全く失われてしまいます。
そうなるとAccessを使用する理由はほとんどありません。VisualBasicで作っても同じことだと思います。
Accessの簡便さはセキュリティーを犠牲にしてなりたっているものだと思います。
３．ロック
Accessを使用する前にさんざん聞いたのは、テーブルをそのままフォームとリンクして編集可能な状態で開いてしまうと、他の端末とロックしてしまうので、そういった使い方は不可、ということでした。それは確かに本当で、テーブルとリンクする時は必ず、編集不可能な状態で開くようにしています。例えば商品マスターを開いて商品CDを選択する時でも、そのフォームでは編集はできないようにして開きます。
それでもロックしてしまう場合があります。大抵の場合、自分自身とロックしてしまいます。特定の行をレコードソースにしたフォームでレコードを編集中、何らかの理由でそのフォーム閉じてしまい、再度、開いたらロックしてしまい編集できなくなる、といったことがよく？たまに？あります。そうなっってしまうと、他の端末からそのレコードを編集しようとしてもロックがかかってしまいます。しかし、その日はそのままにして、翌日会社に行くと、ロックが解除されていて、編集できます。サーバー側のKeepAlive機能のおかげです。
こういったことを防ぐためには、やはりデータベースとの直リンクは避けるべきです。一端、サーバからAccess内のテーブルにデータを落としてそのデータを編集してから、サーバのデータを更新すべきです。
このやり方でまずいところがあるとすると、編集途中でフォームが落ちてしまった場合、編集中のデータが失われてしまうということです。直リンクなら途中でフォームが落ちても編集途中のデータは既に登録されています。
このリスクを考えてもやはり直リンクはすべきでないと思います。
（この症状がでてしまうというのは、直リンクを使用しているからなのですが、そういうテーブルに限って非常にカラム数が多く、ローカルにデータを落としてくるのが面倒なんです。アーアー最初からローカルに落としておけばな～。まあ、次ロックしたら直すことにしよう。）
４．条件付き書式
あらかた終わってしまった、販売管理システムですが、それでもチョコチョコ直しています。特に運用期間が長くなると、不要なデータが増えてきます。商品選択するにしても、しばらく注文が無いようなデータが明細に上がってきて結構煩
わしいものです。
そんな時は条件付き書式でデータを色分けしてやります。直近１年の出荷回数で色分けしてやると、非常に見やすくなります。もっと言うと、あっさり過去１年実績がない商品は非表示にしてやります。こうするともっと見やすいですが、やはり少しやり過ぎの感があります。
Access2007は条件付き書式で画面のちらつきがありません。Access2003でチラチラしていた画面がハッキリ安定した画面になります。その分、画面のRepaintの周期を落としているのでしょう。バッチ処理でデータを更新しながら、レコード番号をテキストボックスに表示させるような処理では、どうかすると数字が停まってしまいます。実際には数字が止まっていても処理は進行しています。
それでも条件付き書式が安定している方がやはり使い易いです。バッチ処理の表示は慣れてしまえば、あきらめもつきますが、商品選択などでの色分けはデータ作成時には必須機能です。
