Thanks again Steffen! > Hmm, the problem is the 19|20 stuff.
Yes I thought it might be! > Date patterns in general may be > given to commands in 2 ways (this is true for time and timestamp, too): > 1. Predefined patterns can be used like USA (MM/DD/YYYY) or ISO (YYYY-MM-DD). > Those can either be specified using the 'SET DATE <pattern name>' command > (for instance SET DATE ISO) and are valid for the whole command file until > reset. > Or they can be specified for a certain LOAD/EXTRACT command where they > overwrite the global setting like this > > DATALOAD TABLE <table name> > <col name> <pos> > ... > INFILE '<infile name>' > DATE ISO > > 2. Date patterns different from predefined may only be specified in commands > directly. So you would use this command to load MM/DD/YY dates: > > DATALOAD TABLE <table name> > <col name> <pos> > ... > INFILE '<infile name>' > DATE 'MM/DD/YY' > > Ok, now the problem. Using a 2-digit year representation will always be transformed > into 20YY by the Loader server (only partially true - if you're using 7.3 > version there is still a bug and Loader server will transform it into 19YY). It would be nice if SAPDB could be asked to extend 2 digit years variously e.g. CLOSEST, PAST, FUTURE, CURRENT, ... > > So is there any possibility to 'convince the Informix tools' to store the dates > as 4-digit representation? How did they handle the Y2K bug? Yes. There is no problem. The Informix SQL UNLOAD command writes the dates according to an environment variable format DBDATE. So a user can create load files with 4 digits in DMY4/ or MDY4/ format (which produce DD/MM/YYYY and MM/DD/YYYY respectively. It is the stores database files deklivered 'out of the box' in MM/DD/YY that I am trying to deal with. Even that could be solved by loading the the database, then exporting it again (having set DBDATE to DMY4/). Regards John O'Gorman > > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
