Update after digging around in the rather bloated DBF files, read if you want a laugh:
I found that the years /are/ stored as two digits, but the enterprise software tries to avoid confusion by having *an entire column* just to specify which century the year is in. So you'll have columns BIRTHDATE = 01/01/50, and BIRTHDATE_CENTURY = 19, and so on for /all/ the rows. It would seem that every single Date column functions this way. Not joking. So I guess this software is Y2K-noncompliant? And here I thought it was all hype... On Jan 11, 3:22 am, chuck <[email protected]> wrote: > Hey everyone, > > I'm working on a C# application at work that establishes an > OleDbConnection to a few DBF files via the Jet driver and executes > some basic queries. The problem is that with any Date column, years > before 1950 are interpreted as 20xx. The obvious conclusion is that > this is a result of the years being stored as two-digits. However, > the enterprise software that we use which is responsible for > maintaining these DBF files has no problem parsing these dates > properly; and some of them are /really/ in the 2000s. I cannot verify > whether the dates are actually stored as four-digit or two-digit years > because every program I use to open the DBF files is making the same > error, so I'm going to call the vendor tomorrow for clarification. > > I was trying to figure out how to change the "cutoff year" and see > what results that produces, but I'm having trouble following the docs > on MSDN. Even then, how would my program be able to recognize a > legitimate 2000+ year without error? > > Just wondering if anyone could tell me how to change the "cutoff year" > or has any ideas on why these years might be erroneously parsed as two- > digit years when they're actually stored as four-digits -- at least, > that is my assumption for now; if they really are two-digits, I'll > have to think of something else. > > Thanks.
