AREV 2.03 EXPORT TO DB3 (AREV Specific)
At 02 FEB 2000 02:05:29PM Penny Broyles wrote:
I am exporting AREV 2.03 data using the DBaseIII export function and all year 2000 dates are coming through as 1900? Any ideas?
Thanks
At 02 FEB 2000 06:33PM [url=http://www.sprezzatura.com" onMouseOver=window.status=Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
This is interesting - we had a client explicitly move to OI from an earlier version of Access to avoid the Y2K bug in Access. Our guess would be that DB3 interprets the year 00 as 1900 rather than 2000.
World Leaders in all things RevSoft
At 02 FEB 2000 08:01PM Warren wrote:
DBase III and later XBase files store dates internally as YYYYMMDD. How are you accessing the DBase files that ARev export creates? FoxPro has a SET CENTURY ON toggle to activate for digit years in display and entry masks. I don't know about DBase IV+.
Get a file viewer like LIST.COM and look at the dates in the DBF file. If they are stored as 1900mmdd then the problem is in ARev.
At 02 FEB 2000 08:08PM Warren wrote:
At 03 FEB 2000 11:13AM Warren wrote:
Okay, I played around with this - the problem is in the ARev EXPORT utility.
OCONV set to D4/: 01/01/2000 stored as 19200101, 01/01/2001=19200101, 01/01/1920=19190101, 01/01/1999=19190101
OCONV set to D2/: 01/01/2000 stored as 19000101, 01/01/2001=19010101, 01/01/1920=19200101, 01/01/1999=19990101
OCONV set to D: really screws up 01/01/2000 will store as 19 101JA and so on.
It looks like EXPORT OCONVs the DATE field as per dictionary item, tries to pars the year, month, day, takes only the first 2 digits of the year cats '19' in front of it and builds the internal format DBase date YYYYMMDD from the above parsed information.
A pretty serious Y2K bug considering RTI recommends changing all date OCONVs to D4 for Y2K Compliance.
My suggestion is to set the OCONV in the dictionary to D4/ (or whatever delimiter you want), define the DBase field as Character 10 and use the CTOD()(Character to Date) function of the Xbase language provided you are using FoxPro or DBase to manipulate the exported data.
This is a RPITA as I have a client that exports piles of data for statistical analysis and the stats program works best on DBase3 files for imports.
I'd be willing to patch the code (and add a couple of enhancements such as the option to suppress the "clear" and "overwrite" messages) if RTI is willing. How about it Kurt?
At 03 FEB 2000 11:32AM [url=http://www.sprezzatura.com" onMouseOver=window.status=Click here to visit our web site?';return(true)]The Sprezzatura Group[/url] wrote:
Nice work Warren!
World Leaders in all things RevSoft
At 03 FEB 2000 07:14PM [url=http://www.sprezzatura.com]The Sprezzatura Group[/url] wrote:
ARev 2.12 shipped with the source to export, so most likely we should be able to fix this ourselves.
[/i]World leaders in all things RevSoft[/i]
At 07 MAR 2000 09:56PM Chris Leenhouts wrote:
There is a new utility called xPort at http://exorsys.com/revelation.htm which resolves all the technical and conceptual problems asssociated with Revelation database exports.