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.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx

-----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

rob@xxxxxxxxx wrote:
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  
date('00010102000000')
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
WHERE clause.

--

JHHL

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].