Other clients than FoxPro can access FoxPro data via the VFP ODBC driver up to version 6 DBFs and OLEDB Provider for any newer DBFs.
The connection strings vary for a DBC or a directory of free DBFs, for that matter, you don't need to go back to dbase or fox2x dbfs, you just limit yourself to field data types, that only have the field types VFP6 already supported to enable using the DBFs from other clients. That includes the most typical ones, it's not a big restriction, You can use character, integer, float, date, datetime, memo, currency and some more, but likely that already is sufficient. No varchar, varbinary, blob, but for binary data you have memo with nocptran option.
If you don't already have the ODBC driver download, MS has stopped providing the download. The OLEDB provider is the better option anyway, but often, eg in the Office products, OLEDB usage aka ADO has not the same options. Eg you can have linked tables in Access only via ODBC, you need VBA code using ADO to make use of an OLEDB Provider, but it's totally possible and VFP OLEDB Provider comes with sample data and sample code. It's not much of your concern, but sadly most usage is not even by developers but Excel users dipping into the data world with sheets having a data source and that's all ODBC based.
There is a better way, the "royal" way to provide data for others, that is export it to a database any client can connect to and that's MySQL Server or MS SQL Server and some others, that can also become your basis for shared data your FoxPro application also uses instead of DBFs, Yes, that needs some more changes to existing code, but that opens up much more possibilities eg putting the data into the web or even a cloud - GCP, Azure, AWS, IBM or others.
And then, last not least, you keep control on the data access not only via limiting file visibility or granting database connections and read permissions but put up another layer, a web service or REST API that provides data in form of XML and JSON. That is the norms also for web clients and besides control over access at all, you can also limit the number of requests, and data volume fetches etc. by providing that level of API access.
OK, that was getting a bit off topic, I don't know whether you just want to enable someone internal non-developer to get at some data or if you plan to sell your data to customers or provide an devleoper interface or whatever is the overall goal.
But I can end up at a round trip with XML and JSON, you can't just send these formats as HTTP response bodies, you can of course also save XML or JSON files and also the most simplest and oldest format for data exchange, CSV files, if you just ask for data export formats other developers and applications can process most easily.
If you really want shared data acces without the need to move data back and forth between your own application VFP9 DBFs and another database (server) fox2x or dbase II might look tempting, as you can also bind VFP controls to it, reccylce code, but you put restrictions on yourself and you only get a partial acccess to your data from others, eg only within your LAN. Opening up your network to the public is not a good solution once that needs more public access. Growing your business today means going online and that means putting your data into an online database server with an APi put in front for controlled access. It all works more complicated than DBF files, but it also has more options and control.
Bye, Olaf.
Olaf Doschke Software Engineering
