>>If the aim is to switch backends, drivers or datasources
>>this approach (OLEDB to parse SQL and fire off backend
>>instance code) is not THAT bad.
>>
>>It sidesteps the vfp ODBC driver problems and perf is not bad...
>>Other option is Advantage ODBC, if Cursoradapter does not fit.
>>
>>Raw vfp SQL possible and least amount of work,
>>but I often work through CA just to be certain
>>I am not handling the base table.
>
>I've seen CA written to work with dbfs and be just as flexible at that, and IMO better than relying on ODBC for dbf.

Definately - you still have DBC functions to do "dirty tricks".
>
>>But if workin.g from Dotnet or through COM
>>(Python or other) this cuts down Marshalling.
>
>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.