0

I have a client who uses a FoxPro database that I need to read/write. I know that most suggestions will be to 'Replace FoxPro', but that is not an option here.

I have tried using JStels DBF JDBC Driver, and JavaDBF Framework to write to the DBF Files. Both of these work, but it encounters an error on the other end requiring a re-index of the FoxPro table. It seems that neither of these existing frameworks allow re-indexing a CDX File. I have also looked into XBaseJ but it explicitly states that it does not support FoxPro Indexes so I didn't pursue it any further. Does anyone know of a way that I can accomplish writing into a FoxPro DBF file, then forcing the table to rebuild the Index (CDX)?

Nathan24
  • 1,372
  • 1
  • 11
  • 20
  • Do you know what version of FoxPro the database is from? There were changes after VFP 6 that mean you must have a driver aimed at the later version. – Tamar E. Granor Sep 08 '14 at 20:26
  • The FoxPro database is version 9.0 or later. I'm not sure which specific version, but I do know that it is later than 9.0. The database belongs to a third party system which I have no control over. – Nathan24 Sep 08 '14 at 21:01
  • 1
    In that case, you need to find a driver that specifically says it supports VFP 9 databases. – Tamar E. Granor Sep 09 '14 at 20:13
  • You might try to replace the stale FoxPro cdx index with a dBase index; FoxPro might be able to convert that index. Slow chance, but FoxPro as a dBase clone might just be able. – Joop Eggen Sep 24 '14 at 21:10
  • A few years back a company I worked for used IDS Server (a type 3 JDBC driver) to bridge to the FoxPro ODBC driver; IDS Server is not free though and requires a license per deployment iirc. – Mark Rotteveel Oct 19 '14 at 07:21

1 Answers1

0

Both of the 'drivers' you mentioned are horribly broken - they use low-level file writes for punching data into DBFs, without any regard for things like indexes, triggers, record/file locking and so on.

Under Windows you can use Microsoft's free ODBC or OLEDB drivers for VFP; on other platforms things get a lot more complicated.

If it is absolutely necessary to write data from platforms that cannot use either the VFP runtime or a compatible driver then it is best to write updates to a separate table that can be merged into the main table on a compatible platform. Whether that is possible depends on the nature of the updates, of course.

Poor man's file locking - create file under a temporary name, rename to 'active' name only when done - is available without access to low-level, system-dependent file locking APIs. This can be extended to create a safe processing pipeline with the file system as the only inter-process communication medium. I.e. write updates from Java using any old driver that can write DBF, rename the table from its temporary name to an active name (magic prefix, whatever); updater process on a Windows box sees active filename, renames to temporary, merges updates into the main table, and then renames to passive name signifying 'done and dusted'.

That way you get to use whatever driver you want under Java but the main table only gets touched by compatible engines (driver/runtime) that do not destroy table integrity.

P.S.: rebuilding the index after b0rkening the table with incompatible updates can be as simple as sending a "REINDEX" command to the Fox runtime (in a Fox app or in one of the Fox drivers) but it creates a logistic nightmare where record/file locking has to be accomplished by administrative measures. E.g. "Has everyone closed the $FOO program? I want to run an update.", "Don't touch that program until I'm done updating and have rebuilt the index!", etc. pp.

DarthGizka
  • 4,347
  • 1
  • 24
  • 36