＊ Amazon Access 関連書籍情報

＊ これはもはやコンピューターの歴史の教科書です。そういう歴史があったのか！という目線で読んでください

いやぁさすがだぜマ○クロソフト！
2000 年問題だけぢゃ飽き足らず、ご丁寧にも2001 年問題だってよ！知ってるお前？2001 年になるとさぁ、日付がおかしくなって、データ抽出できねぇんだよまいっちゃうねほんとに、ゲ○ツもここまで無能だとはなぁ！！！

…な～～～～～～んてことを恥ずかしげもなく言ってる人はまーーーーさーーーーーーーーかーーーーーーーーーーここの読者にはいないですよねぇ～～～～～～～～～～？？？？ いるんだけどねそして捨て台詞を投稿してくんだけどね
あ、今回の「ここの読者」ってのは、「Accessを使って開発してる人」がターゲットですので、ソフトウェア開発業務に携わってない人は、「あーこうゆう問題もあるのねきをつけよー」程度で読んでてください。(^_^;)

まー、世間の皆様が言うところの「2001年問題」ですか？年、月、日 のつもりで「01/01/02」とか入力すると、実際は月、日、年で入力したと Access に思われてしまい、「2002/01/01」になっちゃうんですよね。
つーかそもそも、年って４桁で入力するもんだろう(^_^;)２桁で入れるから悪いんで、４桁でちゃんと入力すれば問題ないんですけどね。たかが２桁どーしてそう横着するかなぁ。

ただこの問題、実際に手入力で発生することってあんまりなくって、VBA でプログラミングしたときによくやる、SQL 文に日付の値を埋め込む、こんなコーディングしたときに出るんですよね。

Dim MyRS as RecordSet
Dim SQLStr as String

SQLStr = “Select * From Table1 where “
SQLStr = Sqlstr & “[Date1] >= #” & Me![開始日] & “# and #”
SQLStr = Sqlstr & “[Date1] <= #” & Me![終了日] & “#”

Set MyRS = Currentdb.Openrecordset(SQLStr)

太字のとこ注目、[開始日] と [終了日] ってのは多分フォームのコントロールですね。日付が入力されるんでしょう。で、この値を文字列結合してるんですけど、当然文字列として結合するわけだから、日付型のまんま渡せるわけもなく、コントロールパネルの日付の「短い形式」で指定してある形式でくっつけられますね。
これはちゃんとデバッグしてりゃすぐ判ることですね。
[開始日] が 「2001/01/01」、[終了日] が「2001/01/15」だったりした場合、SQLStr の中身をちょっと見てみましょう。

Select * From Table1 where [Date1] >= #01/01/01# and [Date1] <= #01/01/15#

あれ～？年が２桁で表示されてる～？
フォーム上では年４桁で出てるのになぁ～おかしいなぁ～。

さてあなたはどう思いますか？

１：「…だから？」
２：「おいおい、これじゃどこが年だかわかんねーよ、年は４桁で表示しないとだめじゃん、修正しよう」

ソフトウェア技術者さんの中に、１：を選んだ人はいませんね？
ってゆーか、実行結果を見ればそうも言ってられないでしょうが。
興味のある方はご自分でサンプルを作成し、動作を確認してみるのもいいですよ。

えー。皆さんは昔っからご承知だと思いますが、いわゆる2001 年問題とか言われているこの動作、すべて仕様に基づいたものです。なんだかやけに騒がれちゃってさぞかし Access も心外でしょう。
マイクロソフトの KB も出てますよね。出たの遅かったけど…
ええもちろん、Access1.1 の頃からの仕様です。ず～～～っと変わってません。え？知らなかった？あなた個人ユーザーですか？なに？Access で開発やってる？

なぜ自分が開発で使う製品の仕様を調べようとしないんですか？たしかに調べにくいことだというキモチもわかるけど。

特に「年を４桁で表さない場合の日付の認識」なんて、これアプリケーション開発やる人にとっては基本の基本じゃないんですか？日付を扱う場合常に意識しなきゃいけない重要課題でしょ？
なに？「こんな動作するなんて知らなかった」？「どこにもそんなこと書いてない」？あんた自分が作ったプログラム、テストしないの？

個人ユースのエンドユーザーならいざ知らず、ソフトウェア開発業務に携わっている人なら、こんな問題にひっかかることを恥だと思ってください。
つまり、自分の作ったソフトなのにろくに動作確認もしていないってことでしょ？↑にコーディングサンプルあげたように、ちょーっとテストすりゃ判ることじゃないですか。
開発プラットフォームの仕様も動作もろくに理解せずに思い込みで作ったソフトを高い金で買わされるお客さまが不憫でなりませんわほんとうに。

「だーっておかしいじゃねーかよ、日付つったら年月日だろ？」ですと？

だからそれが思い込みだっつうんじゃあああああああああああああああっ！！！

…たしかに、日付の認識で優先される書式が「mm/dd/yy」（英語圏）形式だって仕様は日本人にとっては使いづらい！はっきり言ってヘンだ！納得できない！！それはそのとーりです。できれば 最初の Access1.1 の日本語化のときに意識してほしかった…それは認める。

だからって、ろくにテストもせずに作っておいて問題が出たからって Access の仕様に文句つけたってそら責任転嫁でしかないでしょう？
Access という製品を使っていて、しかも仕様による動作であるのだから、それを理解して使うのは当然でしょう。

まず、「mm/dd/yy」形式で日付に変換できるかどーか試し、できればそのまま。できなかったら今度は「yy/mm/dd」形式でもう一度確認してくれる。
柔軟性・汎用性の高いいい仕様だと思いませんか？（いや本当は思わないけどね…）

実は、この問題で本当にコワイのは、2001年問題 なんかじゃないと思うんですよねぇ。
だって、そんな単純なテストもしてないアプリケーション、他にどんな問題が潜んでるかと思うと、恐ろしくないですか？