RE: Date *HIVAL was Urgent!!! NULLS & ZEROS

 >> Nothing wrong with numeric dates.

Well there's one very obvious problem.  There's no way to ensure that you won't
get an invalid date stored in your database if you are using numerics.  For
instance 00/00/00 <grin>

 >> Why create a new data type?

Its hardly new - its been around for a long time.  The main reason for it of
course is that dates _are_ different.  They are not numbers and they are not
character strings - they are dates! In a price or quantity field, any
combination of digits is valid.  Not so in a date.  Lets turn the question round
- why on earth would you _want_ to assume responsibility for the integrity of
values in your "dates" ??

Personally I think the performance "issue" is horse hockey.  If your system
depends on dates then the added security of _knowing_ they are always valid can
save you far more than it costs.  Ask Doug Pence and Ron Hawkins, or read the
stuff they wrote for Midrange on dates.  It remains the _only_ common sense
information I have ever seen published on the use of date fields.


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---