RE: Invalid dates in data transfer

Of course those literals would both need to be '1940-01-01' to be
in the one hundred year window; oops :-)

However that CASE would not handle a date overflow and could
replace many valid dates. Thus actually ensuring the transfer
function uses a four-digit-year is still preferable.

No oops necessary, since the solution was presented only as a means of
getting around the limitations of Excel, which by the way were misstated.
The apparent lower limit for Excel dates is 1/1/1900.

Replacing only the value '0001-01-01' would ensure that any dates
outside of the valid window would still fail; i.e. continue to
diagnose as an error, anything other than the *LOWVAL, which is
probably better than possibly corrupting the dates by resetting
a valid date to a consistent yet wrong date.

Umm... I think you'll find that the system has already validated any date
field (I mean if the DB knows that it's a date), and that nothing will fall
"outside the valid window," whatever that is. I think you will also find
that there are no *LOWVAL dates in these fields. I believe that if you
debug an RPG program that attempts to set a date to *LOVAL, it will actually
be set to 0001-01-01.

Dennis