VPN越しでデータベースに接続した時、accessの速度が遅かったので色々やってみた。
まず、インターネットの契約を1Gから10Gに変更した。ファイル転送速度は上がったものの、accessの速度は上がらなかった。
プログラムの書き方が悪いのだと思い、売上伝票入力フォームをADOで書き直してみたが、2明細の時、10秒が6秒になったくらいで、解決にならなかった。ローカルでは1秒もかからないので、焼け石に水。
結局、Chromeリモートディスクトップを使うことにした。
今回、ADOを初めて使ってみて感想。
１．バッチ処理でなら使えそう
売上伝票入力画面は非連結フォームで、データベースへの書き込み、問い合わせはその都度、行っている。このパターンならADOで処理できそう。
２．連結フォームには不向き
「ADOのレコードセットを連結フォームのレコードソースにできる」と書いてあり、実際できるのだが、DAOのようにはいかない。
例えば、レコードソースにするレコードセットをフォームモジュールで定義していて、あるプロシージャーでopenする。フィルターがうまく動作しない。一応、recordset.Filterを使うことになってはいるのだが、、、
うまくいかないので、同一レコードセット名で開き直すと、別プロシージャーで操作できなかったりする。
どうも開き直した時点でインスタントが失われてしまい、同じレコードセット名でもレコードセットが使えなくなってしまう。
３．レポートのレコードソースにならない
これはやってみたわけではないのだが、Copilotで調べると、「ADOのレコードセットはレポートのレコードソースとしては使えない」、とのことだった。
これは致命的で、一度、accessのテーブルに取り込んで、そのテーブルをソースにするとかしなければならないらしい。
レポートの項目は、安定稼働するまで、増減するので、それをaccessのテーブルに読み込むとなると、取り込み部分のコードも変更しなければならないし、テーブルの列も変更しなければならなかったりして、かなりDAOの場合より手数が増える。
DAOならソースにしているクエリーを修正するだけ。
４．SQLはかなり使えるようになってないと難しそう
accessのクエリービルダーでとりあえずリンクしたテーブル名を使ってSQLを作ることはできる。よく使っているのだが、せっかくADOでプログラムを書くのなら、PostgreSQLの高機能なSQLを使いたい。
case whenやOLAPはaccessでは利用不可でADOでやるなら使いたいが、クエリービルダーでは利用できない。
使おうと思ったら、直接SQLを書くしかない。
まあ、ExcelやC#でPostgreSQLのデータを読み込んだり、書き込んだりするなら、ADOでやらなければならないだろうが、accessの連結フォームでフィルターかけたり、並べ替えたりゴチャゴチャやるのには向いてないと思う。実際、今回、勉強不足と思って、Kindle版のaccessのADOの書籍を捜してみたが、見当たらなかった。やはり、accessで全部ADOでっていうのは無理なんだと思う。
バッチ処理しているフォームでもDAOで書いたブログラムを全部、ADOに修正しようと思うと、ものすごく手間がかかる。
accessで販売管理ソフトを自作しようとすると、膨大な量のコードを書かなければならない、ADOで悩むより、DAOでサクッと作って、問題になるところだけ、ADOなり、パススルークエリーなりで手直しする方が現実的。
－－－－－－－－－－－－－－－－－－－－－－－－
それにしても今回、色々調べるのにCopilotを使った。
ネットが使えない時は書籍だけが頼りで、結構お金がかかった。
ネットが使えるようになって、だいぶ良くなったけど、「こんな機能はないだろるか？」と思ってもいろんなホームを調べ歩かなければならないので、面倒だったりして。「取り合えず動けばいいんだろう」と、わかっている範囲でなんとかしていた。新しいことを覚えるのが難しかった。
ところが、今はCopilotがある。
わからないことは何でも回答してもらえるし、SQLやaccessのコードを見せて悪いところを指摘してくれる。昔と比べると雲泥の差。今から勉強する人がうらやましい。
その分、専門家に求めるスキルも上昇するので、業界の人は大変だろう。