IMHO it is too late.
The dbf as remote storage/local data repository/cursor format/data exchange esperanto is dead.

SMB2/Oplocking settings changing with Windoze updates killed troublefree remote storage without server process.
Local data repository today is SQLite (see mobile market and many W/Lintel apps), which is fast and well tested now.
Esperanto is XML (slow, wordy), JSON, many CSV and some SDF for bulk loading (dbf still a great mix for speed and self-description)
Cursor format is decided by the technology used - should be SQLite with some tricks added instead of memory loaded XML (sigh...)

When I saw Etec vfp compiler going after the easy fruit of GUI compatibility in Dotnet my enthusiasm waned -
the real advantage vfp has over most other languages, the tight integration of local storage and Querybility of local/remote with SQL
was not pursued early enough - even in vfp8/vfp9 a few data engine errors were fixed. I know, because I found some ;-)

And while vfp is something I am immensly productive with and taylormade for SQL data mining,
other languages have nice benefits as well. You have to program to the strength of the language used,
not to the mindset learned with the previous tool. Driving a truck like a Ferrari is hazardous, using a Ferrari as a tractor...

regards

thomas

>So sad that VFP compiler seems to have died. I would have liked to see it bought by Google and placed in the public domain. Perhaps it's not too late.
>
>
>
>>>>Hi
>>>>
>>>>I am wondering whether I can use VFP's data handling capabilities in another language like "C". The idea would be to call functions in the VFP9R.dll to execute commands on VFP tables. I do not wish to write code in VFP that calls "C" functions. I want to write code in "C" or some other language that calls VFP functions.
>>>>
>>>>Does anyone know if such a thing is possible and where to find some information about how to accomplish this if it is possible?
>>>>
>>>>Thanks,
>>>>Simon
>>>
>>>Using VFP's table access functions directly from the vfpr.dll sounds cool. Wonder if .NET compiler used this approach.
>>
>>perhaps at start, but as they had their own table layer without 2GB limit, they had to have own implementation.
>>
>>regards
>>
>>thomas