| 日付型ってなんですか？扱いにくいからやめたほうがいいって聞いたんですが… |
このコンテンツに関連したおすすめ書籍:
AccessVBA実践のツボ―VBAはココで使う
コメント： どこをVBAで、どこを関数で処理するの？使い慣れないと効率の悪いほうを選択しがちですよね。 |
|
もう過ぎ去った感もありますが２０００年問題。なんでこんな問題が起きたかというと、西暦の上２桁は１９だという間違った常識がいつのまにかできあがってしまっていたからです。なぼなんざ未だに書類書くとき「2001」と書かなければいけない日付欄に「19」と書いてしまいあわてて修正液を探すこともしばしばです。（間抜け） それはコンピュータ業界の話ではなく、一般的な生活の中にも数多くありますよね。 身の回りの品物で日付が刻印されているものは結構あるはずですが、その中で年を４桁で表示しているものがどれだけありますか？ 人間が見る分には、「きょうは１９９９年だから９９年は今年だよね」と頭の中に置き換えルーチンができていて、自分でも知らないうちに判断しているのですが、コンピューターはそうはいきません。 その品物が１００年たってもまだ現役で使われていたらどうしますか？いつの９９年だかもうわかりませんよね。 実際は１００年以上使うかもしれない品物には年を４桁で表示しますからそんなことはないんですが。 ここに、２０００年問題の原点があります。 つまり、昔のコンピュータ技術者は、みんな「こんなシステム２０００年まで使わねぇよ」と思っていたのです。（本当） だから年は２桁で十分だったのです。 これら一連の考え方を根本的に直さないと、２０００年問題の解決はできません。 これから作るシステムは、すべて「年は４桁で表示・入力する」で統一しましょう。昔のデータを貯えるデータベースである以上、この先ずっとついてくる問題です。 Accessのテーブルには「日付型」というデータ型がありますね。正しくは「日付・時刻型」。日付と時刻の情報を１つの領域にもつことができるデータ型です。 昔のCOBOL等で作られたシステムではこのようなデータ型は無かったので、「980518」といった６桁の数字文字で日付を表していました。年２桁、月２桁、日２桁ですね。そもそもこういうデータの持ち方が現在の2000年問題を引き起こしているんですが、それはとりあえずおいといて(^_^;) Access（及びSQLベースのデータベースエンジン）の日付・時刻型とは、こういったものとは根本的に違います。 内部では「シリアル値」と呼ばれる、一見すると数値にしか見えない値で扱われ、外に見せる時に日付のような表示形式で見せています。その表示形式は場合によって選ぶことができます。 つまり、西暦表示だろうが和暦表示だろうが年４桁だろうが年２桁だろうが思いのままということです。 日付表示形式は、なにも指定されない場合はWindowsのコントロールパネルの「地域」内での「日付」設定どおりに表示されます。ちょっと見てみてください。長い形式、短い形式が指定されていますね？ これを状況に応じて表示を変えたい場合は、Format関数、書式プロパティ等で設定します。 あるクエリーでは西暦２桁表示がしたい、というのであればFormat関数で編集した結果を表示すればいいし、（書式プロパティでもいいです）あるフォームでは和暦を年号指定して入力、表示したいというのであれば書式プロパティと定型入力を組み合わせて使うことになります。（定型入力は、必ず和暦で入力してもらう等といった規則付けに有効です） 日付・時刻型では日数の計算、月数の計算などの関数が豊富に用意されているので便利ですし、和暦・西暦変換のしくみをVBA、Accessに任せることができます。日付型が現せる範囲は 西暦100年1月1日〜西暦9999年12月31日 ですので、２０００年ぐらいでびくびくする必要もありません。 平成が終わって新しい年号が追加された場合、マイクロ●フトの対応を待つしかないのですが、逆に「マイク●ソフトが対応してくれないとダメなんですよーすみませんねー」ととりあえず逃げる、という姑息な手も使えます(^_^;;)（よいＳＥは真似しないように！） テーブル上に日付・時刻型でフィールドを作っておくと、SQL 文の中で日付の演算が高速に出来たりというメリットもあります。SQL 文中で型変換関数（cvDate とか？）を使うと処理が遅くなる心配がありますから。 日付・時刻型フィールドにはありえない日付・時刻は入力できませんし、うるう年を含めた日付の論理チェックをプログラム上でやる必要もありません。 では、日付・時刻型を使わないとどうなるでしょう。テキスト型に、19980101 と８桁の数字文字を格納するか、それとも1998/01/01 と入れるか、それとも 平成10年1月1日 と入力するか、月や日が１桁だった場合頭に０を加えるか・・・ あー規則をきめるだけでもうイヤになってしまいますよね。その規則どおりにデータを入力してもらうようにチェックするのもまた大変ですし、かりに和暦を使用するとなると、西暦←→和暦の変換なんてことも考えなければなりません。（まぁこれは型変換関数で日付型へ変換すればいいのですが） と、いうわけでなぼは、テーブルに日付データを格納する際には日付・時刻型のご使用をお勧めいたします。 ただし、デメリットはまったくない、って訳でもありません、注意する点はもちろんあります。 日付・時刻型では、日付と同時に時刻まで管理できます。なにも考えず日付だけを入力した場合、時刻は午前０時が設定されています。 が、定型入力等で制限を加えていない限り、時刻を入力しようと思えばできてしまうのです。データ入力中なんらかのミスで時刻が入ってしまった場合、画面上で書式を使って日付だけを表示させているとその事実に気づきません。 さらにテーブルのフィールドにある書式プロパティで日付を設定している場合、テーブルをデータシートで開いても入力されている時刻は見えません。コントロールパネルの設定も、通常は時刻が見えない設定になっています。 もし間違って時刻が入力されてしまった場合、1998/09/01 00:00:00 と、1998/09/01 12:31:05 では、比較結果はfalse（同じではない）になってしまいます。ところが見えているのは日付だけ、両方1998/09/01なのになぜ同じじゃないんだーっっといらんところで悩む羽目になりかねません。 これを防ぐため、フォームなどで日付・時刻型の項目に入力させる場合には定型入力を使うか、時刻が入らないようデータ登録前にチェックする等したほうがいいでしょう。さらに、テーブルの書式プロパティでは年４桁から時刻まですべて表示するよう設定しておいたほうが、テーブルをデータシートで開けば正確なデータ内容をみることができるようになります。 ちょっと追加。たとえ日付・時刻型を採用していたとしても、年の入力は４桁でしなければダメであることだけは忘れないでください。Accessは年が２桁で入力された場合、勝手に上２桁を補ってくれますが、その補い方がバージョンや OS や２０００年パッチが入っているかどうかで違ってくるので注意が必要です。 そんなわけで、なぼはいつも日付データの入力に関しては２桁で入れられようが４桁で入れられようが、入力直後（フォーカス喪失時とか）に必ず年４桁で再表示するようにしています。こうすれば、オペレータさんが間違った入力をする危険性を下げることができます。 さらに追加。モジュール内で日付・時刻型を扱うとき、日付・時刻型の変数どうしでの比較はまるで問題ないですが、日付の入った文字列と比較したり文字列と結合したりするときには、絶対にFormat関数を使い年４桁を明示的に表示するように心がけましょう。こーゆー問題もありますから。コンパネの設定なんかー信じてちゃいけません。頼れるものは己のみ。 さて、「じゃあ、いまテキスト型や数値型で日付データ持ってるんだけど、日付型に変更したい！」場合どうしたらいいか。 ＊作業前にMDBファイルのバックアップは必ず取りましょう！
Accessに限らず、ＳＱＬデータベースを扱う場合は日付・時刻型と無縁でいることはできませんので、これを上手に使いこなせるように頑張りましょう。特性さえ知ってしまえば、こんなに便利なものはありませんよ。 ただし、前述のとおり、いくら日付・時刻型を使ってもMicr○softから提供されるパッチをあてても（そもそもこれも信用ならん）、年を２桁入力する限り２０００年問題の解決はできませんのでご注意を。 |
この情報は、お客様の疑問・問題解決のお役に立ちましたか？ 満足度を左から右へ高い順へご選択ください。 |