<HOME　　<お願い事項 　　<Access2002 TOP　　　<Access97 TOP　　　<サイト内検索
MS-Access2000超入門部屋--2001年問題？　２

で、これがどういうところで影響するか、ということなんですが、mm/dd/yyとなるのはVBAのコードの中のみ、です。
クエリとかフォームのプロパティとかでは、コントロールパネルの「地域のプロパティ」で設定した標準書式がそのまま採用されるはずです。だから普段は気にする必要ないと思います。

たとえば、こんな感じのテーブルがあって、［日付］は日付時刻型ですが特に何も書式の設定とかしてないので、短い形式（yy/mm/dd）になってます。

コントロールパネルの「地域のプロパティ」の「短い形式」がyyyy/mm/ddになってる人は、yyyy/mm/ddって表示されますよね。
私のマシンは「短い形式」がyy/mm/ddなので、上のように表示されます。

で、テーブルは閉じて・・・。

クエリをひとつ作ります。↓

［日付］に対する抽出条件を入力します。01/01/22と入力してデータシートビューに切り替えると

でますよね。↑

デザインビューに戻ってくると、あ、↑イゲタで囲まれてました。
ああ、日付ですもんね。でも、VBAと違って、クエリのデザイングリッドだとこういうとこ配慮してくれるんですね。

クエリなら、別にどういうふうに日付の入力しようが、何の支障もないじゃないですか。ねえ。

テーブルの中から特定のレコードを抽出するやり方って、クエリの他に、フィルタっていうのもありますよね。
詳しくは別コーナーにて解説してますのでそちらもご覧いただくとうれしい。

こんな感じの↑フォームを作り、ヘッダー部分に非連結のテキストボックスを作ります。
わたしのは、テキスト4って名前のテキストボックスになりました。非連結ですよ。非連結のテキストボックスです。

で、このテキストボックスの「更新後処理」にこんな感じのイベントを作ります。

で、テキストボックスに、抽出したい日付を入力して（半角ですよあたりまえですけど）Enterすると

なーんもでません。クエリのときは01/01/22でオッケーだったのに・・・。

あ、イゲタがいるのか！ウエーめんどくさいなぁ。でもしょうがない。

ちょっと複雑ですが↓、テキストボックスに入力した値の両側に半角のイゲタがつくようにして

りべーんじ。

・・・でも、おんなじか。わたしのＰＣだと、1件も出ませんでしたわ。みなさんどうですか？

最後の手段だ！
西暦を4桁全部入力して・・・。
あ、これなら出る・・・。あるいは、1/22なんて、西暦を略した状態で入力しても抽出できるかもしれません。
うーん、なんか、どうも、日付の書式に振り回されちゃいそうですねぇ。

ここから先は、可能な方だけ試してください。

再びコントロールパネルの「地域のプロパティ」を見ます。

短い形式を「yyyy/mm/dd」にしてみます。

で、さっきのmdbを開いて、さっきのフォームでもう一度実験！

西暦が、4桁になってますよね。今度は多分、01/01/22でも抽出できるんじゃないかと思いますが・・・。どうでしょう。

でも実際、「コントロールパネルの日付の設定を変える」なんてこと、あんまりしたくないですよね・・・。だって、今まで見てきたこを考えると、Access以外のソフトウェアに影響があるかもしれないじゃないですか。それに、会社の中で「PCの設定」等々定められていて勝手に変えられないお立場の方もいらっしゃると思いますしね。

じゃどうすればいいのか、というお話の前に、どうして上のようなことが起きるのか、どうして起きるPCと起きないPCがあるのか、その辺、オッケーですか？

今度は、さっきのモジュールの方を試してみましょうか。
ええと、01/09/22　と入力して・・・1/9/22になっちゃいますよね。やっぱり。

結果は・・・げーやっぱし2022/01/09だ・・・でも、今度は「西暦」を4桁にしてるんで、さっきより現象がわかりやすいですね。ってわかりやすきゃいいってもんじゃないだろーとひとりぼけつっこみ。
みなさんのＰＣではいかがでしょう。

いろいろ見てみましたけど、「日付が狂う」とか「間違った日付が入力されてしまう」のではなくて、「日付の表示書式の年/月/日が入れ替わる」ということが、いろいろなところに影響を及ぼしそうだ、ということですね。これを「バグ」「マイクロソフトの責任」と考えるかどうかは、意見の分かれるところだと思います。

わたしは・・・・個人的には、この現象は、作り手側で注意すべき部分として受け止めてます。
まあ、内心いろいろ思うことはありますけどね。

マイクロソフトのサイトに、以下のような情報が掲載されていますので、ぜひ一読なさってください。

[ACC2000]yy/mm/dd 日付を#で囲むと"mm/dd/yy"に変換される

ややこしいですけれど、問題点を整頓して考えてくださいね。
mm/dd/yyと解釈されるのは、VBAもしくはSQLビューを利用して日付時刻型の値を扱っている場合で、西暦を2桁で入力している場合のみです。それは、今までいろいろ試していただきましたよね。
クエリをデザイングリッドでふつうに作ってる分には特に問題にはならないし、西暦を4桁で入力していれば問題にはならないのです。
VBAを使って日付を扱う検索プログラムとか作ってて、クセでついうっかり01/01/22とか入力しちゃったときに2022年のデータを検索しに行ってしまい「該当件数なし」になってしまう・・・なんてことがありえる、というわけです。
決して、「日付が狂う」のではありません。この点をしっかり理解しないといけませんですよ。

で、上記サイトでの見解では、これは仕様なので、
下のように↓必ず4桁で入力するか

Format関数を活用して、↓VBAの中ではmm/dd/yyと解釈していることを記してやるか、

どちらかの方法を取ってください、ってことですね・・・。
つまり、もしかしたら、現状のデータベースにひと手間加えないと（それもかなり細かい変更）ならないって場合も、無きにしも非ずです。
みなさんのお手持ちのデータベース、こんな現象出てませんですか？
思い当たることがあるようでしたら、データベース全体で書式が整うよう、いろいろ工夫してみてください。

Excelでも似たような現象があります。ただし、Accessと同一理由による現象ではありませんので、誤解なさらないようにしてくださいよ。

[XL2000] 英語の月名と数値を入力した場合の日付認識について

マイクロソフトの技術情報です。
文書番号が変わっている可能性があるので、見つからない場合はマイクロソフトの技術情報検索で探してください。

（でも、うちはAccessのことしか載せてないので、詳しいことはExcel関連の情報を発信なさってるサイトで確認してくださいね）

まあ・・・VBAで日付データを扱うときは、できるだけ細かくテストを繰り返して、できるだけ「Format関数」を使って書式を統一するように作りこんで、んでも最終的には「西暦は4桁入力する癖をつけよう」っていうことです。

日付や時刻の表示形式は、国によっても用い方が異なります。
こればかりは・・・コンピュータの内部の設定に頼らず、できるだけ意識して書式の設定をしていくように心がけていきましょう。

（オシマイ）