Accessで日付変換する方法をお探しですね。

広告

Accessで8桁の数字を日付に変換する方法を徹底解説！

Accessでデータベースを管理していると、外部システムから取り込んだCSVデータの日付が「20231015」のような8桁の数字（文字列）になっていて、そのままでは期間を指定した抽出やソートがうまく動かない…という経験、ありませんか？この記事では、Accessの関数を使って8桁の文字列を正しい日付型に変換する方法や、逆に日付型を好きなフォーマットの文字列に変換する手順を、わかりやすく解説していきます。

エラーを防ぐ実践的なコツも紹介しますので、ぜひ参考にしてください！

まずは基礎知識：なぜ8桁の数字はそのままだと日付として使えないの？

Accessでは、日付データは内部的に「シリアル値」という数値で管理されています。

だから、「20231015」という8桁の数字をただの文字列（テキスト型）としてテーブルに取り込んでしまうと、Accessはそれを日付として認識してくれないんです。

テキスト型のままでも並び替えはある程度できますが、日付の計算をしたり「この期間内のデータだけ抽出したい」といった条件を指定すると、うまく動かなくなってしまいます。

「CDate関数を使えば一発で変換できるんじゃないの？」と思う方も多いかもしれませんが、実はCDate関数は「20231015」というスラッシュのない8桁の数字を、そのままでは日付として認識してくれません。

実行すると「データ型が一致しません」というエラーが出てしまうんです。

正しく変換するには、まず文字列の中に年・月・日を区切る「/（スラッシュ）」を入れて「2023/10/15」という形の文字列を作り、それから日付型に変換する、という二段階の手順が必要になります。

この仕組みを理解していないと、クエリで演算フィールドを作ったときや更新クエリを実行したときに、原因不明のエラーに悩まされることになるので、まずは「8桁の数字にはスラッシュを入れてから日付型に変換する」という基本をしっかり覚えておきましょう。

Format関数とCDate関数で文字列を日付に変換しよう

それでは、実際にクエリの演算フィールドを使って、8桁の文字列を日付型に変換する方法を見ていきましょう。

一番シンプルでよく使われるのは、Format関数とCDate関数を組み合わせる方法です。

Format関数は本来、値の表示形式を指定するためのものですが、文字列を特定のフォーマットに整える際にもとても便利なんです。

例えば、「受付日_文字」というフィールドに「20231015」というデータが入っているとします。

これを日付型にするには、クエリのフィールド欄に次のように入力します。

**変換後日付: CDate(Format([受付日_文字],”@@@@/@@/@@”))**

ここで使っている「@」は、文字列の1文字を表す記号です。

この書き方で、最初の4桁、次の2桁、最後の2桁の間に自動的にスラッシュが入って、「2023/10/15」という文字列が作られます。

それをCDate関数で囲むことで、Accessが正式な日付型データとして認識してくれるようになります。

別の方法として、「Left」「Mid」「Right」といった文字列操作関数を使って、スラッシュを手動で結合する書き方もあります。

具体的には次のようになります。

**CDate(Left([受付日_文字],4) & “/” & Mid([受付日_文字],5,2) & “/” & Right([受付日_文字],2))**

Format関数を使う方がコードが短くてスッキリしますが、Accessのバージョンやデータの状態によってはFormat関数が思い通りに動かないこともあるので、この文字列結合の方法も知っておくと安心ですよ。

逆パターン：日付型を8桁の数字（文字列）に変換する方法

ここまでは文字列を日付型にする方法を説明してきましたが、逆の処理が必要になることもよくあります。

例えば、Accessで管理している正しい日付型データ（2023/10/15など）を、他のシステムに連携するために「20231015」というスラッシュなしの8桁のテキストデータとして出力したい、といったケースです。

こんなときも、Format関数を使えば簡単に実現できます。

日付型データを特定の文字列フォーマットに変換する場合、クエリのフィールドには次のように記述します。

**出力用日付: Format([本来の日付フィールド],”yyyymmdd”)**

「yyyy」は西暦4桁の年、「mm」は2桁の月、「dd」は2桁の日を表します。

この指定をするだけで、Accessが内部で持っているシリアル値を、指定した通りの文字列に自動的に変換してくれます。

もし「231015」のように西暦の下2桁だけでいい場合は、「yymmdd」と指定すればOKです。

このように、日付を文字列に変換する処理は、文字列を日付にする処理に比べてエラーが起きにくく、とてもシンプルです。

ただし、変換後のデータはあくまで「テキスト型」になるので、これ以降のクエリで日付の足し算や引き算（DateAdd関数など）は使えなくなります。

データを出力・連携する直前の最終段階のクエリでこの変換処理を行うようにするのが、データベース管理のコツです。

エラーを防ぐ！空白や変な日付が混ざっているときの対処法

実際の業務で文字列データを変換するとき、一番困るのが「不完全なデータ」の存在です。

外部から取り込んだ8桁の数字データには、空欄（Null）が混ざっていたり、「20230230」（2月30日なんて存在しない！）や「99999999」のようなおかしな日付データが含まれていることがよくあります。

こういうデータに対して、さっき説明したCDate関数をそのまま使ってしまうと、クエリを実行した瞬間に「抽出条件でデータ型が一致しません」というエラーが出て、処理が止まってしまいます。

これを防ぐには、「IsDate関数」と「IIf関数」を組み合わせて、「データが正しい日付に変換できる場合だけ処理する」という条件分岐の仕組みを作ることが大切です。

IsDate関数は、対象のデータが日付として有効かどうかを判定して、True（正しい）かFalse（間違い）を返してくれる関数です。

これを使って、まずはFormat関数でスラッシュを入れた文字列が、本当にカレンダー上に存在する日付になるかをチェックさせます。

具体的なクエリの書き方は次のようになります。

**IIf(IsDate(Format([受付日_文字],”@@@@/@@/@@”)), CDate(Format([受付日_文字],”@@@@/@@/@@”)), Null)**

この書き方なら、「正しい日付に変換できる文字列のときだけCDate関数を実行して、空白や変な日付データのときはNull（空欄）として扱う」という安全な処理ができます。

大量のデータを一括で更新するときや、マクロ・VBAに組み込んで自動化するときには、必ずこのエラー対策を入れて、システムが途中で止まらない丈夫なデータベースを作ってくださいね。

まとめ

この記事を参考に、Accessでの日付変換をマスターして、日々のデータ管理業務をもっとスムーズにしていきましょう！

広告