SOHOの散歩道

Access2007も2010も、デフォルトのファイル形式は同じ.accdbであり、かつ2010で作っても”2007のaccdb”みたいな表示が出る。つまりあくまでもファイル形式は2007形式ということなので、2010独自のプロパティなどは、2007から見たときに影響を受けないようなところに保存されているのではないかと思う。

とはいえ、何の変哲もない、凝った仕組みなど何もないデータベースなのだが、Access2010で新規作成して、それを2007で動かすと、”ファイルが破損していて開けない”、”データベースファイルが認識できない形式である”、”VBAのプロジェクトが破損している”などのメッセージが出て動かないことがある。

一方、Access2007で作ったデータベースについては、少なくてもこれまでのところ、Access2010で何ら問題なく開けるし、エラーなどの問題は発生していない。しかもそれはAccess2007の.accdbに限らず、2003以前の.mdbについても、基本的には（特殊なコントロールなどは除いて）問題は起きていない。

ということは、同じ.accdbであっても、下位互換はないと言えるかもしれない。

本格的にさまざまなバリエーションで調査したわけではなく、あくまでも経験則なのだが、

• Access2010のみで動作させる場合にはAccess2010で作ればよい（当たり前だが）
  
• Access2007で動作させる場合にはAccess2007で作っておけば、将来2010で動かすときにも大丈夫
  
• Access2007とAccess2010で動かす可能性がある場合には、最低限基本的な部分はAccess2007で作る（このとき2010独自のコントロールやプロパティがあるのでそれは使わないようにする）
  

といったようなことが言えると思う（印象として...）。

Windowsが世の中で一般的になる前、PC-9800シリーズとかのMS-DOSの時代からパソコンをやっている人にとっては、DOSのコマンドとかは馴染み深い、というより必須の知識だった。

当時はアプリケーションの使い方もさることながら、DOSの最低限のコマンドとか、AUTOEXEC.BATやCONFIG.SYSがいじれないと思った通りにパソコンを動かせなかったし、そういったことを知っている人が”パソコンに詳しい人”と特別扱いしてもらえた時代だった。

現在では「コマンドプロンプト」とか「DOSプロンプト」とか言って、ふつうは使うことのないかなり特別な存在になってしまったが、時には役立つことがある。

定期的に行う簡単なファイルのコピーでも、全然違う場所、たとえばネットワーク上のドライブだったり、階層の深いフォルダにあったりするファイルを所定のフォルダにコピーする場合、エクスプローラでドライブやフォルダを辿ったりしていくのはかなり面倒。もちろんそのファイルが見つかればWindowsではコピーや移動は非常に簡単なのだが（MS-DOSならコマンドを打ち込まなければならない）、何よりもそこへ行き着くのに手間取ることもある。

そんなとき、DOSのバッチファイル（.BAT）を作っておくと非常に楽。どんなに深い階層のフォルダであっても、いちいちエクスプローラでそこに移動することなく、そのバッチファイルをダブルクリックすれば簡単に定型的なコピー操作を実行できる。しかも一連の操作をまとめて設定できるので、さまざまな場所にある複数のファイルを一気に所定の同じフォルダにコピーしてくることもできるし、コピーに先立ち既存のファイルの名前を.BAKなどに変更しておくこともできる。

もちろんそういった定期的に行うタスクを設定できるWindows用のツールも存在するのだが、”古臭いMS-DOSの知識だってまだ使えるぞ！”という場面もあるのではないだろうか？。

Accessで一般的なデータベースを作るときにはまず必要とすることはないが、それなりのアプリケーションを作ろうとすると、その過程で、開発効率を上げるためにそれなりの解析テクニックが必要となることもある。

たとえば、テーブルの一覧を取得したり、コントロールのあるプロパティを一定のルールに基づいて一気に変更したいようなときには、通常のアプリケーションでは使わないような、Accessデータベースを解析するためのプログラムを書いたりすることがある。もちろんそれらは手作業でひとつずつ行えばできないことではないのだが、やはり大量のオブジェクトがあるような場合には有効な方法である。

ところで、そのようなとき、テーブルの情報を取得する際には「TableDef」というオブジェクトをVBAのコードで利用する。フォーム等に関しては「Document」というオブジェクト。いずれもDAOのオブジェクトになる。それらのオブジェクトには「DateCreated」と「LastUpdated」というプロパティがあり、それを調べることによってそのオブジェクトの作成日時や更新日時を取得することができる。

もちろん、ナビゲーションウィンドウからひとつずつテーブルのプロパティ画面を表示させれば確認できる内容なのだが、テーブルがたくさんあるような場合にはやはり相当な手間となってしまうので、プログラムで一気に取得した方が楽だし、イミディエイトウィンドウに出力することでそれをコピー＆ペーストして他の資料などに使うこともできる。

この「DateCreated」と「LastUpdated」のプロパティ、テーブルやクエリについては問題ないのだが、「Document」オブジェクトから取得するフォーム・レポート・マクロ・モジュールに関しては、Accessのいつのバージョンから厳密に確認していないが、少なくてもAccess2003の頃にはAccessのバグがあって、常に同じ値が返されていた（Access95とかかなり昔のバージョンではそのようなことはなかったのだが）。確かマイクロソフトのサポートのページにも既知の問題として掲載されていたような.....。

その点について、Access2007や2010では改善されていのかと思いきや、特に変わっていなかった。DAOのバージョンアップはささやかながら少しずつ行われているようではあるが、こんな小さなかつ通常は使われないような機能に関してはもはや対象外となっているようだ。

ちなみに、この情報はAccessのシステムテーブルである「MSysObjects」に書かれていて、そのプロパティ値はそこから持ってきているのだが、やはりオブジェクトを変更してもその情報は書き換えられない。もはやその機構自体が変更になっているということだと思う。

ちなみに、AllFormsとかのコレクションを使ってそれらのプロパティ値を取得すれば、正しい情報が得られる。オブジェクトの生成や更新の日時については、DAOではなく、別の方法による管理に完全に切り替わっている。

Access95とか97とかの頃の昔の話し。テーブルを空にするような削除クエリ、もしくはDELETE文を使ったSQL文の実行にはかなり時間が掛かった。

もちろんパソコンのスペックとか削除するレコード数にも相当影響されるのだが、ほんの数百件のレコード数のテーブルを空にするにも、Accessウィンドウの左下のインジケータが表示されるくらい待たされたものだ。

そのようなときの対処方法として、自分がよく使っていたのが、トランザクション処理をする方法とデータ定義クエリを使う方法。

前者の方法は、DELETE文の実行前後にトランザクションの命令を配置する方法。BeginTrans〜CommitTransで囲むことによって、メモリ上で削除されてから一気にディスクに書き込むという内部処理になるので、ディスクアクセスの面でパフォーマンスがよくなる。

一方、後者の方法は、テーブルを空にするというのではなく、オブジェクトとしてのテーブル自体を丸ごと削除したあと、データ定義クエリでテーブルを再生成するという方法。１件１件レコードを削除するよりオブジェクト丸ごとの方が相当速く処理された。データ定義クエリはすべてSQL文を直接記述しなければならないので、作成する手間はかかったが、処理の面ではかなりメリットがあった。またこの方法はレコード数に影響されない、つまりレコード数が少なくても逆に相当多くても同じくらいの時間で処理されるというのも一つの特徴だった。


ただ、いつからだろうか？、Access2000になってから2002からか、あるいはAccessには関係なくて単にパソコンの能力がアップしたせいだろうか？、DELETE文で削除するのがかなり速くなっていることに気が付いた。

DELETE文を使う場合、削除クエリを使うにしても、VBAのコードにSQL文を書くにしても、データ定義クエリを作るよりはかなり簡単に実装できる。そのような理由から、個人的には、いつの間にか何となくではあるが、現在ではデータ定義クエリは使うことはなく、単純に削除クエリ or VBAでDELETE文を発行するような作り方に完全に移行している。


でも、DELETE文の処理時間自体が速くなったのは間違いないと思うのだが、果たしてデータ定義クエリに比べてどうなのか？、データ定義クエリでテーブル丸ごと再生成の処理も同時に速くなっていて、両者を比べたらやはりデータ定義クエリの方が速いのではないか？、そういった疑問から、簡単なテストを行ってみた。

約30ケのテーブルを用意し、そこにそれぞれ100000件のレコードを追加し、両者の方法それぞれを実行してみる。

その結果、DELETE文の処理「0.04秒」、データ定義クエリの処理「0.16秒」。

いずれも一瞬、大差ないと言えなくもないが、DELETE文の方が速いのは間違いない。しかもデータ定義クエリを作る手間を考えれば、開発という面では確実にDELETE文の方がよい。

また、100件のレコード数の場合もテストしてみたのだが、処理時間は100000件のレコード数の場合とまったくと言っていいほど違いはない。つまり、いずれの方法でも、レコード数が増えたことによって処理時間は影響されないということが言える。ということは、さらに巨大なレコード数になったとしても、DELETE文の方が劣化してしまうということはないと想像できる。

テーブルを空にするような処理では、いつの間にか何となく、自分としてはDELETE文を使う方法のみになっていたが、それは定量的にも間違いではなかったようだ。

ただしいて言えば、全レコード削除の場合でもDELETE文ではオートナンバー型のフィールドは初期化されず、削除する前の最大値＋１が新規レコードの初期値となる。Accessでは「TRUNCATE TABLE」は使えないので、もしそのようなことが必要であれば、データ定義クエリもあながち不要なクエリとは言えない。『テーブルを空にする場合はDELETE * FROM 〜〜〜』と決めながらも、データ定義クエリのことを知っていても損はないと思う.....。

最近、IEでYahoo!のトップページを開くと、一瞬だけ画面左上に何かが表示されるようになった。

はじめは、ポップアップ広告か何かが表示されようとしてブロックされているのかなとも思ったが、何度か見ているうちに、それはページ右上に通常表示されるべき広告がチラッとだけ左上に表示されることが分かった。

おそらく、JavaScriptとかあるいはCSSなどを使って表示位置を決めているのではないかと（調べもせずに）想像するのだが、せっかく凝っても結果そのような変な動きをするのでは元も子もないように思う。・・・・ちなみにその辺の処理は高速なのだろうか？、Firefoxなどでは表示されない

そういえば、わりと有名なあるサイトのログイン画面、とにかくシンプル。まるで、携帯用のページのように、色も画像も飾り付けも何も凝っていない。ユーザーIDとパスワードを入力してボタンを押すというとにかく簡単なデザインになっている。メインのホームページの方は凝ったデザインになっているのに、なぜそこだけそんなに簡単なの？と疑問には思うが、操作上何のデメリットもない。ある意味機能としてはそれで十分なのだ。

最近、Webページに関しては、デザイン的なものからプログラムテクニックまで、どんどん進化している。ユーザーがより使いやすいという観点ではそういったテクニックも必要不可欠なのかもしれないが、でも基本的にはやはり送り手がどんなテクニックを使っているかより、中味（コンテンツ）勝負というところはかなりあると思う。サクサクと動いて必要なことができればいいのであって、意外と使う側にはせっかくのテクニックも届いていないことも多いのではないかと思う。

１月になって、いくつかのサービスで「今年の３月でポイントの一部が期限切れになりますよ」という連絡がくるようになった。ポイント自体はタダなので、捨ててはもったいないので、早速それらを商品と交換する手続きをした。

ところが、自分が入っている生命保険の会社では、昨年の春にポイント加算が終了していることが分かった。ポイント自体はあと何年か残って商品と交換できるが、加算されることはもうないということ。それを過ぎればポイント制度自体も完全に終了。

昨日もコスト削減とサービス低下について書いたが、こんなところにも不況の波は影響しているのか？。何とも世知がない世の中と言わざるを得ないですね.....。