Re: Another SQL newbie question

[James Lampert <jamesl@xxxxxxxxxxxxxxxxx>]

CRPence wrote:
>   Note that the CHAR scalar\cast function allows a second parameter to
> map a date to character in the ISO form [for example] similarly to allow
> the smaller or larger dates to avoid the date underflow and date
> overflow conditions.  So in the interface used to test the UDF, instead
> of finding the session attribute to set date formats to ISO, use instead
> the following UDF invocation:
>       CHAR( DISPLAYDAT( xxx ) , ISO )
>   instead of:
>       DISPLAYDAT( xxx )
>
>   Sometimes my preference would be to return CAST(NULL AS DATE) for an
> input of zero, or in response to an error for any bad inputs like
> 20010229 or 99999999.  In that case adding a HANDLER to the SQL function
> to directly RETURN that, or return the DATE variable when that can be
> set without an error.

No, that's not it at all: it's failing IN the UDF, which is being
called in the SELECT that defines a VIEW, NOT as a SELECT pouring data
into a TABLE. In every single case in which it doesn't blow up, the
date is displayed as an ISO date, whether the view is being opened as
a SELECT * on the STRSQL command line, or it's being opened through
native RLA (specifically, from QuestView).

--
JHHL