×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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
midrange.com
