To construct dbf imports programatically, I have a routine using OSOpen and OSBRead with field name and length data loaded from a static table. That's ok so long as the dbf field lengths aren't changed.

In Arev's dbf bond, header data would automatically query and correct for field length changes before the import. Is there a chance we could get this back in OI?

Alternatively, how can I programatically extract field length from the dbf header. In notepad it's not clear how that information's embedded.

Thanks,

Allen

I'd use a hex editor to inspect the files. Notepad is not the right tool.

Perhaps review the dbf specification online, eg.

http://www.e-bachmann.dk/docs/xbase.htm

http://www.geocities.com/geoff_wass/dBASE/GaryWhite/dBASE/FAQ/qformt.htm

To convert 32 bit integers, seq(buffern,1) is your friend

Steve

steve@state-of-the-art.com.au

Allen,

There is probably no one better than Steve to answer your questions as written. However, have you considered using OI's ODBC connectivity to import your DBF files?

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don, I've used ODBC in other apps (not OI) but don't prefer since it requires workstation specific Windows configuring (simple but nonetheless an added step at deployment). Doing it programatically's not foolproof however if dbf header details aren't automatically queried in advance of import requests (Arev's dbf bond did this). Fortunately our dbf specs rarely change so we've not broken anything yet.

Mike's banner at the top of this page "Get connected with ODBC and save…." leaves me less certain I'm thinking this through ok. Is ODBC the better way to do these imports?

Steve - thanks for your advice and leads. I was at an impasse.

Regards,

Allen

Allen -

For a one-time conversion, another way is to use MS Access to import the dbf files, then use an Access macro to load OI and use XREV.DLL to convert the data into OI.

Steve

steve@state-of-the-art.com.au

Allen,

The "better" way is the way that works best for you. Since I don't have any dbf format specs on hand then I would resort to ODBC myself. But you have both options available so it is kind of a push.

FWIW, the ODBC that you see advertised in the banner is for a driver that allows external applications (VB, Crystal Reports, etc.) to read LH data. You would be using the ODBC connectivity features that are built into the C/S Workspace tool of OI. Hence, it comes free with OI and I'm pretty sure you won't have to do any workstation configuration since the dBASE ODBC driver comes standard on most Windows workstations.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Ironically, we had to add ODBC drivers to all our newer xp (Dell) workstations - not a big deal. Except for query to update field lengths, doing the import programatically works ok.

Nonetheless, I'll go with ODBC on this.

Thanks again, Don

View this thread on the Works forum...