| 2024/05/22(Wed) 10:53:31 編集(投稿者) 2024/05/20(Mon) 22:40:11 編集(投稿者)
TSさん
>> 日付は、本質的に文字列型または日時型であるのが自然ですよ。 > > 勉強になります。 > TBLをバックアップコピーし、 > [起算開始]、[起算終了] のデータ型を日時型にしてみたいと思います。 > また、今回照会させてもらった既テーブルのデータ型変更 > (及びデータの再入力・チェック)に時間がかかってしまい、
当方は土日月とPCの前に居ませんでしたので、ご返事が遅れました。
当方の発言で、なんかマッチで火を付けてしまったような気がしています。
今まで、数値型でデータを蓄積してきたのですから、それ自体には問題は無いのですよ。 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
ただ、一般論で言うと
文字列型の日付文字列のデータか、日時型のデータが、日付の処理に適していますよと申し上げた次第です。
ややこしい事をしようとすると、
数値型 → 文字列型(日付文字列) → (必要に応じて)日時型
または
数値型 → 日時型
の変換が必要になるので、数値型よりも云々と申し上げたわけです。 ・・・・・・・・
それが・・・、まさか表の定義を変更してしまうとは思っていませんでしたので非常に驚いてしまいました。
日付が火付けになってしまったようで恐縮です。m(__)m
p.s.
確かに入力の際に0〜9の数字と正負記号しか受け付けないという特性は便利です。※指数表現も受け付けるでしょうけれども(^^ゞ
なので、数値型で入力を受け取るというのは実践的なテクニックと言えますよ。
だから、オペレータが入力する項目として数値型であっても何ら問題はないのです。※私は表の定義は自由だと申し上げていましたよ ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
しかし、それとは別に数値を日付として処理する場合にはちょっと面倒になるわけです。
そこで、入力と日付計算のどちらか一方を選ぶのではなく、入力は数値型、計算のタネは日時型というように考えることも出来ます。 ◎◎・・・・ ◎◎・・・・・・・ つまり、
[入力用の数値型項目]と[日時型の計算項目]をペアで運用するというのもアリだろうと思います。 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
[日時型の計算項目]の計算式は、毎回同じなのでいわずもがなですが・・・
#日時値( #sstr( #str( [数値型項目], 1, 4 ) + "-" + #sstr( #str( [数値型項目], 5, 2 ) + "-" + #sstr( #str( [数値型項目], 7, 2 ) ) ↑ ↑ 区切り文字はお好きなものを 区切り文字はお好きなものを
もしも、[文字列型の計算項目]がよろしければ
#sstr( #str( [数値型項目], 1, 4 ) + "-" + #sstr( #str( [数値型項目], 5, 2 ) + "-" + #sstr( #str( [数値型項目], 7, 2 ) ↑ ↑ 区切り文字はお好きなものを 区切り文字はお好きなものを
↑これは毎回の変換手順でワンパターンですから、もう何度もご覧になって目に焼き付いているかもしれませんね??? ・・・・・・・・・・・・・・・・・・・・・・・・・・・・
このように、日時型に変換するか、文字列型の日付文字列に変換すれば、日時に関する各種の関数が利用できるわけです。
でも、数値型の場合には何もできないのです、しかし、オペレータの入力する項目という見方からすれば実践的ですね。
オペレータさんの入力のやり易さを優先して、なおかつ日時の計算が簡単に出来るようにとハイブリッドな表定義にするのが望ましいかもしれませんね。
なお、今回は早合点して拙速に表の定義を変えたりしないでくださいね。
あくまでも、当方( ONnoji )は他人ですから、TSさんの状況を事細かに把握して強制・矯正しているわけではないのです。
だから「あ〜、また ONnoji が何か言ってるよ。」という程度に気楽に読んでください。
p.p.s.
ヘルプでキーワード: 日付文字列 を検索してください。
"日付文字列"は、日時型が存在しなかったDOS桐の時から日時の計算をする時の基本です。
"日付文字列"の知識は基本中の基本ですから、必ずヘルプを読んでくださいね。 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
[桐 - ヘルプ]→ データと式 → 計算式 → 日時の計算 → 日時文字列
日時型は、"日付文字列"に時刻(時分秒:hms)を追加したデータ型と思ってください。 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
|