メインコンテンツへスキップ

日付型での範囲指定ができません

コメント

19件のコメント

  • TAKUYA.O

    だいず様

    見当違いであれば恐縮ですが、参考までに。

    XPA2.xではINIファイルの[MAGIC_ENV]セクション>”Century”のデフォルト値が1920の設定されています。

    たとえば、25/12/31の値は→内部的に1925/12/31と解釈されますので、結果として日付の範囲指定が効かなくなる可能性があります。

    私の場合はデータ更新の際に同様の現象が発生し、かなり焦った記憶がございます。

     

  • TAKUYA.O

    追記です。

    XPA4.xはデフォルト値=1930ですので、過去バージョンのINIファイルを流用している場合にのみ該当します。

     

     

  • だいず

    TAKUYA.O様

     

    ご返事ありがとうございました。

    Century = 1930となってました。

    IF文でデータの選別はできたので、いったんこれで進めようと思っています。

     

    ご協力ありがとうございました。

  • Tanda

    だいずさん、

    日付項目の範囲指定でしたら、dateリテラルを使えば簡単ですよ。
    関数を使うまでもないですよ。

    例:2026/01/01 〜 2026/03/31 を範囲指定したい場合

    範囲開始(式):’2026/01/01’date
    範囲終了(式):’2026/03/31’date

  • だいず

    Tanda様

     

    ご返信ありがとうございます。

    すいません。dateリテラルを使う方法が分かりません。

    Str(日付型変数,'########')Date

    としてみましたがエラーになります。

    恐らく基本的なことなのかと思いますが、もう一度アドバイスいただければ幸いです。

    宜しくお願いいたします。

     

  • nkmt

    こんにちは。

    そのデータの日付型項目の書式が
      ##/##/##との事ですが、
    差し支えなければ、書式を
    YYYY/MM/DDに変えておいた方がいろいろと勘違いや間違いが起きにくいような気はします。

    最初の御投稿で
    DVal 関数を書いていらっしゃいますが
    DVal 関数を使う場合、第1パラメータは文字型なので
    DVal('2000/01/01','YYYY/MM/DD') の記述は正解です。
    DVal('2000/01/01'Date,'YYYY/MM/DD') とすると第1パラメータが日付型になるのでNGです。

    データは日付型という事ですので範囲FROMに
    DVal('2000/01/01','YYYY/MM/DD') か
    '2000/01/01'Date を指定するのは正解です。

    AddDate(日付型変数,0,0,-1)とありますが
    日付型変数に もし1日ではなく4月3日とかが格納されていたら、結果は4月2日です。

    前月の最終日を指定したいなら自分なら、念の為BOMなども用いて
    AddDate( BOM(日付型変数),0,0,-1) とか
    EOM(AddDate(     日付型変数 ,0,-1,0)) か
    EOM(AddDate( BOM(日付型変数),0,-1,0)) にします。

     

  • nkmt

    TOの日付は可変にさせたいとの事ですので、TOに
    '2026/03/31'Dateを指定するのはNGです。
    関数を使うまでもない、何てことはありません。

  • nkmt

    Dateリテラルは
    DStr('2026/04/30'Date,'YYYY/MM/DD') などに使います。
    DStr(日付型変数,'YYYY/MM/DD')  日付型変数の場合には、Dateリテラルは使いません。

  • だいず

    nkmt様

     

    色々と情報ありがとうございました。

    とても勉強になります。

    確かにYYYY/MM/DDの方が間違いないですね。

  • Tanda

    だいずさん、

    dateリテラルというのは、文字列を日付型として扱ってくれるという機能です。たとえば、式テーブルに単に、

    ‘2026/03/31’

    と書くと、通常それは単なる文字列としての扱いになるのですが、そのうしろにdateリテラルを付けて、

    ‘2026/03/31’date

    と記述すると、それは単なる文字列ではなく、日付型のデータとして認識してくれるようになる、という機能です。

    したがって、まずは式テーブルにこのようなリテラルを使った固定値を直接記述してテストし、それでうまく動作するのが確認できたら、そのあとに、変数や式を用いて動作検証を行う、という流れが分かりやすいですよ。

    たとえば、「日付型変数」という変数があって、その変数の型が最初から「日付型」となっているのであれば、リテラルを使う必要はありませんし、関数で変換する必要もありません。

    「日付型変数」で範囲を指定したいのであれば、式テーブルに単に、

    日付型変数1(シンボル名)〜日付型変数2(シンボル名)

    のように書くだけでOKです。関数を使う必要はありません。

    ちなみに、日付型項目は内部的には西暦1年1月1日(西暦0年0月0日ではないところに要注意)からの経過日数を数値データとして保持していますので、日数の計算だけでしたらダイレクトな加減算が可能です。たとえば、10日後を指定したいのであれば、式テーブルに、

    ‘2026/03/31’date + 10
    または、
    日付型変数(シンボル名) + 10

    と記述することができます。逆に、減算して10日前を指定したいのであれば、式テーブルに、

    ‘2026/03/31’date - 10
    または、
    日付型変数(シンボル名) - 10

    と書いてやるだけでいいです。画面表示の書式はMagicが自動でやってくれますので、関数でわざわざ変換したりする必要もありません。このような仕組みがあることを知っていると、プログラムがとても簡潔になります。

    ちなみに、dateリテラルに限らず、リテラル全般に関しての解説が下記のヘルプにありますので、参考にされるといいですよ。

    dsourceリテラル、errリテラル、eventリテラル、expリテラル、formリテラル、indexリテラル、kbdリテラル、logリテラル、menuリテラル、progリテラル、rightリテラル、timeリテラル、varリテラル、等

  • だいず

    Tanda様

    大変わかりやすい返信ありがとうございます。日数計算できるとは知りませんでした。とても便利な機能ですね。ありがとうございます。

    ところで、現状下記のようにしています。「終了」の条件を「'2026/01/01'DATE」とすると動きますが、

    下記画像のように日付型変数にすると動きません。

    これが動かない理由がいまだに分かりません。

  • nkmt

    V.今月月初日に 2026/1/1が格納されるタイミングは、どの時点ですか?
    上位タスク
    このタスクのタスク前
    レコード前など

  • Tanda

    だいずさん、

    範囲指定を行うための変数への値の代入は、そのタスクのタスク前処理より前の段階(通常は1つ上位のタスク、またはメインプログラム)で事前に行っておく必要がありますが、ひょっとして同じタスク内でやってしまっているということはありませんか?

    ちなみに、固定値をダイレクトで記述した場合は、タスク前処理より前の判定になりますので、範囲が有効となります。

  • だいず

    Tanda様

     

    なるほど!!ビンゴです!!タスク前処理で変数に値をセットしてました。

    レコード前の段階で変数に値が入っているので、これで動くかと思ってました。

    ありがとうございました。ようやく納得しました。

    ご協力ありがとうございました!!!

     

     

  • Tanda

    だいずさん、

    動作確認のテストをするだけでしたら、メインプログラムに日付型の変数を定義して、同時にそこで値を代入しておくという設定だけでもチェックできますよ。個々のタスクからはメインプログラムの変数も参照できますので。動きが確認できたら、そのあとにゆっくり上位タスクの作成に取り掛かればいいと思います。

  • Tanda

    だいずさん、

    あ、投稿が行き違いになってしまいましたね。

    納得できてよかったですね。

    それでは頑張ってください。

  • だいず

    Tanda様

    しかしタスク前でデータビューの条件で使用する変数をセットできないのは若干納得いってません(笑)

    仕様ということなんだと思いますし、それならそれで今後前タスクで準備すれば良いだけなので、今後この問題でハマルことは無くなるので、とても感謝しております。

    ありがとうございました。

  • Tanda

    だいずさん、

    この問題はですね、議論しだすと話がとても長くなるので止めておきますが、簡単にいうと「柔軟性」を優先するか、「スピード」を優先するかの選択なんですよね。

    イスラエルMagic社の天才エンジニアグループも、議論しつくして、こうなったんだと思います。でも、将来的にはバックエンドのDBの動き(世の中のSQLの動き)が改良されれば、Magicの仕様も変わるかもしれませんね。

  • だいず

    Tanda様

     

    なるほど、深い理由があるのですね。

     

サインインしてコメントを残してください。