>>But then again why not write a VFP COM object to do that? You can't rely on existence of any kind of driver for dbfs from M$. Advantage is probably okay, but now that VFP is already at hand, why not?
>
>Because then the you introduce or increase
>coded dependancy on vfp.
>Even if your solution is solid and works for years,
>chances are they have not spelled out all needs at first
>or will realize them 5 months later.
>
>They probably wish to leave DBC/DBF/VFP or
>are just using a vfp process without vfp foundation.

Yup, leaving VFP while keeping a VFP app which creates those records. Trying to squeeze hard and let go in the same move.
For as long as there's a VFP app as a source of records, VFP is there, so why not use it in some simple manner. Even exporting as CSV or perhaps json is better than relying on an ODBC driver for dbcs, which is hard to find nowadays.