－－SQLが苦手だ！－－
ODBC経由だとOpenRecordsetする時の引数にクエリー名が指定できないので、SQLを指定してやらなければならないのだけれど、素人には結構難しい。
そこで、奥の手。クエリーデザインでクエリーを作成後、「SQL表示」させてコピー、テキストエディッターにペースト。編集後、プログラムにペースト。この機能は良く使った。
しかし、クエリーの中にクエリー名が入ってしまう場合はこの手は使えないので、前に書いたようにフォームのレコードソースにクエリー名を指定してフォームとして開いて、そのフォームを元にしてOpenRecordsetすることになるのだが、結構重かったりする。
たまに参照するクエリーならそれでも良いのだが、頻繁に使う場合には支障が出てしまう。そういった場合には、Postgresql側でViewを設定する。Viewを使ったViewも作成できる。作ったViewはAccess側では編集できないテーブルとして見える。サーバー側に処理を任せてしまうと、相当速い。
－－Accessって危ない－－
ネットで調べると、「Accessは危ない」という記事が結構あるかもしれない。以前にも書いたことがあるが、この「危ない」ってどういう意味かよくわからなかった。
最初は「普通に使っていて、データベースが壊れ易い」という意味かと思っていたが、どうもセキュリティーが全くなってないということみたいだ。（前にも書いたことがある）
実際、リンクテーブルで使うと、悪意を持った人がナビゲーションウィンドウ(Access2007)からテーブルを表示し全レコードを削除してしまう、ということが簡単にできてしまう。リンクテーブルを使用しないで、その都度、ODBC接続文字列をプログラム中で指定すれば、その危険性は無くなるのだが、デザインフォームからプログラムを表示してODBC接続文字列がバレてしまうと、なんでもできてしまう。悪意があればなんでもできる。
リンクテーブルを使えば、プログラム作成も楽だし、効率が上がる。でも危険。今のところ、運用開始から１０年経つが、そういった事故は起きていない。Accessを使って販売管理プログラムを作成しようと思うような中小企業で、そういった危険があるのなら、そういう人は雇用すべきではないと思う。
こういった危険があるので、プロはAccessを使用しないのだろう。実際、重いし。
しかし、もし気になるならナビゲーションウィドウやメニューを非表示にしてプロテクトモードを作成するのも一つの方法だ。実はこの画面は作成したのだが、クライアントでエラーが発生した時、直ぐに原因を調査できるよう、未だに使用していない。
（プロテクト画面はネットで検索して、コードをコピーペーストして作った。）
（プロテクトモードではプログラムのエラー行が直ぐに表示できないので、バグ出し時には向いていない。）
下記は、どこかのホームページからコピーしたのだが、今日、検索しても出て来なかった。私が作ったものではないので、指摘があれば直ぐ削除します。
使用する時は、「プロテクト オフ」ボタンを必ず作成しておかなければなりません。そうしないと、二度とメニューが表示されません。
Private Sub t0A_cmd01_Click() 'プロテクト オン
Dim aa As Variant
MsgBox "再起動した時にデータベースウィンドウがなくなります！"
aa = SetStartupProperties(False)
End Sub
Private Sub t0A_cmd02_Click() 'プロテクト オフ
Dim aa As Variant
MsgBox "再起動した時にデータベースウィンドウが出てきます！"
aa = SetStartupProperties(True)
End Sub
Function SetStartupProperties(bb As Variant)
Dim aa As Variant
aa = ChangeProperty("StartupShowDBWindow", dbBoolean, bb)
aa = ChangeProperty("StartupShowStatusBar", dbBoolean, True)
aa = ChangeProperty("AllowBuiltinToolbars", dbBoolean, bb)
aa = ChangeProperty("AllowToolbarChanges", dbBoolean, bb)
aa = ChangeProperty("AllowFullMenus", dbBoolean, bb)
aa = ChangeProperty("AllowBreakIntoCode", dbBoolean, bb)
aa = ChangeProperty("AllowSpecialKeys", dbBoolean, bb)
aa = ChangeProperty("AllowBypassKey", dbBoolean, bb)
aa = ChangeProperty("AllowShortcutMenus", dbBoolean, bb)
End Function
－－最適化－－
これはネットでも全く見たことがないのだが、プログラム作成、修正している自分のパソコンでaccdbファイルが段々大きくなる。別にフォームを増やしたわけでもないのに、10Mバイトも大きくなってしまうこともある。しかも、直ぐに落ちてしまう。プログラム終了時に必ず、「最適化」しているのだが。（使用環境はWindowsXP SP2、Access2007）
こういった時に、全く別のパソコン（WindowsXPでもVistaでも7でも良いのだが）に大きくなった最新のaccdbファイルを上書きして、起動、終了してやると、プログラムサイズも小さくなり、「落ち易い」といった現象が改善する。
この現象の報告がネットにあまりないのが不思議なのだが、この方法は最近、常用している。原因はよくわからない。
－－同期、非同期－－
Currentdb.Execute は同期
DoCmd.RunSQL は非同期
ODBC接続でデータベースを操作する時、同期、非同期は意識しなければならないのだろうか。実際、当初、Docmd.RunSQLを使っていた。指摘を受けてある時期以降、Currentdb.Executeを使うようにしているのだが、同期の必要があるのかと思う。いずれを使ってもこれといったトラブルは発生していない。
Currentdb.Executeを使ってデータベースにSQLを発行後、PostgresqlからSQL完了信号が返ってくるとは到底思えない。結局、どちらを使っても良いのではないかと思うのだが。
－－ODBCドライバーかネイティブドライバーか－－
開発当初のことで忘れてしまっていたが、「本当にODBCドライバー接続でいいんだろうか？」と迷っていた時期があった。ネイティブドライバーの方が動作が速いからだ。結局、ODBCドライバーで問題なかったと思う。
当時(2000年頃）はパソコンの動作が遅く、販売管理プログラムを作るには作ったが、動作が遅くて使用に耐えない、なんてことを心配をしていた。確かに導入時(2003年頃）は使えなくもないが、動作が速いとは、お世辞にも言えなかった。結局、年を重ねるごとにパソコンが高速になり、現在に至って、まあ、普通かという動作速度だ。最近、５年くらい前に購入したパソコン２台ををついに更新して、シングルコアのパソコンが無くなったが、新規購入したパソコンは低価格でも随分速くなったものだと思う。
ODBC接続で良かったと思う理由はいくつかある。一つには、ODBC接続+リンクテーブルの場合、ドライバーを変更してもプログラムを修正する必要がない。ネイティブドライバーの場合、そういう訳には行かない。
例えば、もし、PostgresqlからSQL Server に変更したい場合、ODBCドライバー接続ならテーブルリンクを取り直すだけで、簡単に変更できる。
また、速度云々といったところで、速度の主な部分はSQLのGroup by句の実行速度でほぼ決まるので、ODBCドライバーだろうがネイティブドライバーだろうが大して変わらない。
ODBC経由だとOpenRecordsetする時の引数にクエリー名が指定できないので、SQLを指定してやらなければならないのだけれど、素人には結構難しい。
そこで、奥の手。クエリーデザインでクエリーを作成後、「SQL表示」させてコピー、テキストエディッターにペースト。編集後、プログラムにペースト。この機能は良く使った。
しかし、クエリーの中にクエリー名が入ってしまう場合はこの手は使えないので、前に書いたようにフォームのレコードソースにクエリー名を指定してフォームとして開いて、そのフォームを元にしてOpenRecordsetすることになるのだが、結構重かったりする。
たまに参照するクエリーならそれでも良いのだが、頻繁に使う場合には支障が出てしまう。そういった場合には、Postgresql側でViewを設定する。Viewを使ったViewも作成できる。作ったViewはAccess側では編集できないテーブルとして見える。サーバー側に処理を任せてしまうと、相当速い。
－－Accessって危ない－－
ネットで調べると、「Accessは危ない」という記事が結構あるかもしれない。以前にも書いたことがあるが、この「危ない」ってどういう意味かよくわからなかった。
最初は「普通に使っていて、データベースが壊れ易い」という意味かと思っていたが、どうもセキュリティーが全くなってないということみたいだ。（前にも書いたことがある）
実際、リンクテーブルで使うと、悪意を持った人がナビゲーションウィンドウ(Access2007)からテーブルを表示し全レコードを削除してしまう、ということが簡単にできてしまう。リンクテーブルを使用しないで、その都度、ODBC接続文字列をプログラム中で指定すれば、その危険性は無くなるのだが、デザインフォームからプログラムを表示してODBC接続文字列がバレてしまうと、なんでもできてしまう。悪意があればなんでもできる。
リンクテーブルを使えば、プログラム作成も楽だし、効率が上がる。でも危険。今のところ、運用開始から１０年経つが、そういった事故は起きていない。Accessを使って販売管理プログラムを作成しようと思うような中小企業で、そういった危険があるのなら、そういう人は雇用すべきではないと思う。
こういった危険があるので、プロはAccessを使用しないのだろう。実際、重いし。
しかし、もし気になるならナビゲーションウィドウやメニューを非表示にしてプロテクトモードを作成するのも一つの方法だ。実はこの画面は作成したのだが、クライアントでエラーが発生した時、直ぐに原因を調査できるよう、未だに使用していない。
（プロテクト画面はネットで検索して、コードをコピーペーストして作った。）
（プロテクトモードではプログラムのエラー行が直ぐに表示できないので、バグ出し時には向いていない。）
下記は、どこかのホームページからコピーしたのだが、今日、検索しても出て来なかった。私が作ったものではないので、指摘があれば直ぐ削除します。
使用する時は、「プロテクト オフ」ボタンを必ず作成しておかなければなりません。そうしないと、二度とメニューが表示されません。
Private Sub t0A_cmd01_Click() 'プロテクト オン
Dim aa As Variant
MsgBox "再起動した時にデータベースウィンドウがなくなります！"
aa = SetStartupProperties(False)
End Sub
Private Sub t0A_cmd02_Click() 'プロテクト オフ
Dim aa As Variant
MsgBox "再起動した時にデータベースウィンドウが出てきます！"
aa = SetStartupProperties(True)
End Sub
Function SetStartupProperties(bb As Variant)
Dim aa As Variant
aa = ChangeProperty("StartupShowDBWindow", dbBoolean, bb)
aa = ChangeProperty("StartupShowStatusBar", dbBoolean, True)
aa = ChangeProperty("AllowBuiltinToolbars", dbBoolean, bb)
aa = ChangeProperty("AllowToolbarChanges", dbBoolean, bb)
aa = ChangeProperty("AllowFullMenus", dbBoolean, bb)
aa = ChangeProperty("AllowBreakIntoCode", dbBoolean, bb)
aa = ChangeProperty("AllowSpecialKeys", dbBoolean, bb)
aa = ChangeProperty("AllowBypassKey", dbBoolean, bb)
aa = ChangeProperty("AllowShortcutMenus", dbBoolean, bb)
End Function
－－最適化－－
これはネットでも全く見たことがないのだが、プログラム作成、修正している自分のパソコンでaccdbファイルが段々大きくなる。別にフォームを増やしたわけでもないのに、10Mバイトも大きくなってしまうこともある。しかも、直ぐに落ちてしまう。プログラム終了時に必ず、「最適化」しているのだが。（使用環境はWindowsXP SP2、Access2007）
こういった時に、全く別のパソコン（WindowsXPでもVistaでも7でも良いのだが）に大きくなった最新のaccdbファイルを上書きして、起動、終了してやると、プログラムサイズも小さくなり、「落ち易い」といった現象が改善する。
この現象の報告がネットにあまりないのが不思議なのだが、この方法は最近、常用している。原因はよくわからない。
－－同期、非同期－－
Currentdb.Execute は同期
DoCmd.RunSQL は非同期
ODBC接続でデータベースを操作する時、同期、非同期は意識しなければならないのだろうか。実際、当初、Docmd.RunSQLを使っていた。指摘を受けてある時期以降、Currentdb.Executeを使うようにしているのだが、同期の必要があるのかと思う。いずれを使ってもこれといったトラブルは発生していない。
Currentdb.Executeを使ってデータベースにSQLを発行後、PostgresqlからSQL完了信号が返ってくるとは到底思えない。結局、どちらを使っても良いのではないかと思うのだが。
－－ODBCドライバーかネイティブドライバーか－－
開発当初のことで忘れてしまっていたが、「本当にODBCドライバー接続でいいんだろうか？」と迷っていた時期があった。ネイティブドライバーの方が動作が速いからだ。結局、ODBCドライバーで問題なかったと思う。
当時(2000年頃）はパソコンの動作が遅く、販売管理プログラムを作るには作ったが、動作が遅くて使用に耐えない、なんてことを心配をしていた。確かに導入時(2003年頃）は使えなくもないが、動作が速いとは、お世辞にも言えなかった。結局、年を重ねるごとにパソコンが高速になり、現在に至って、まあ、普通かという動作速度だ。最近、５年くらい前に購入したパソコン２台ををついに更新して、シングルコアのパソコンが無くなったが、新規購入したパソコンは低価格でも随分速くなったものだと思う。
ODBC接続で良かったと思う理由はいくつかある。一つには、ODBC接続+リンクテーブルの場合、ドライバーを変更してもプログラムを修正する必要がない。ネイティブドライバーの場合、そういう訳には行かない。
例えば、もし、PostgresqlからSQL Server に変更したい場合、ODBCドライバー接続ならテーブルリンクを取り直すだけで、簡単に変更できる。
また、速度云々といったところで、速度の主な部分はSQLのGroup by句の実行速度でほぼ決まるので、ODBCドライバーだろうがネイティブドライバーだろうが大して変わらない。