Re: SQL*Forms and the 21st Century

A good way I have seen to handle dates is to keep the date in a hidden item and have a non-table item for the data which is of type char, not date.

You then have a when-validate-item trigger on this item which sorts everything out. This is a long winded way as you have to code all the triggers for new values, values returned from queries and values entered in enter query mode.

However this is worth doing if you do what we did.

All the users seemed to have different preferences as to how they entered the date, eg
'7/10/95','07/10/95','7.10.95','7/JUL/95','7-JUL-95','7-JUL-1995' etc.

We wrote a library procedure that checked what format had been entered and re-formatted it to '07-JUL-1995'. Depending on the application it may also be possible to guess which century they wanted, eg if 95 was entered it is 1995, if 10 was entered it is 2010.  

Pete Kolton
ORACLE Systems Consultant
Beverley, England.
All reasonable offers considered. Received on Mon Jul 10 1995 - 00:00:00 CEST