Since that date function was built as a SQL stored procedure when you had your session defaults set to the 2 digit year format, it could be that the compiled routine is still expecting the two digit year format. Try recreating the stored procedure.
STAR BASE Consulting, Inc.
-----midrange-l-bounces@xxxxxxxxxxxx wrote: -----
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
From: James Lampert
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Date: 06/01/2011 11:47AM
Subject: Re: Still more SQL date weirdness
Good ideas Chuck, although I suspect James will modify the condition
handler to do something like
declare continue handler for SQLEXCEPTION return date('00010101000000')
since he didn't use null for that zero date. Then again, if he picked
it might make it easier to find dates that are invalid.
The problem is apparently *not* one of dates being invalid in the
DISPLAYDAT UDF (and therefore in the view), or it would have been
throwing exceptions without the WHERE clause. Rather, somehow, the DATE
function, when called in the WHERE clause, appears to be expecting a
2-digit year, even though the session has been set to *ISO, and
complaining when it doesn't get one.
Otherwise, it would still be failing when given 2-digit years in the