Re: SQL*Forms and the 21st Century

From: Jonathan Lewis <Jonathan_at_jlcomp.demon.co.uk>
Date: 1995/07/03
Message-ID: <804805272snz_at_jlcomp.demon.co.uk>#1/1


In article <804788565.17688_at_imp.demon.co.uk>

           John_at_toronto.demon.co.uk "John Thomas" writes:

: mcallister_at_grad.missouri.edu (Andrew McAllister) wrote:

: > Oracle 7 supports the new date format DD-MON-RR. This will automagically
: > change any date < 49 to the next century and >= 50 to this century. So
: > 31-Dec-35 is Dec 31, 2035 and 31-Dec-99 is Dec 31, 1999.
: >
: > Don't know if forms 3 or whatever supports this format, but it is worth a try.: > Andy
:
: It doesn't, sadly.

I don;t know if this will satisfy the original query, but on a very simple test, I achieved the following:

        init.ora NLS_DATE_FORMAT=DD-MON-YY

        sqlplus: create table temp1 (d1 date);

        sqlforms30: default form, but change type of D1 to CHAR.

The net effect was as required: dates for years 0 and 49 go to 20nn, years 50 through to 99 go to 19nn.

Note however, for safe treatment you will need an on-validate-field trigger which checks that the field is a date and raises your own exception if it is not.

There is also an oddity that I have not addressed that immediately after being created, the record cannot be edited without a requery, as it gives the 'FRM-40654 record changed by another user' error.

The reason why the trick does not work when D1 is left as a Forms date is that forms passes the date back as an internal type 12, i.e. 7 byte date, with the 19th century already filled in.

-- 
Jonathan Lewis
Received on Mon Jul 03 1995 - 00:00:00 CEST

Original text of this message