>As for using the dbf's directly, well that will always be possible, but I think you will see the desire for this approach diminishing in the future as mom and pop businesses want to create an internet presense. When they want to start getting orders over the net they will want their data visible over the net and dbf's aren't a very good way to provide this for a number of reasons.

I don't agree with this at all. The truth is that there will always be an intermediate between teh actual Web client and the data. A middleware tool like ASP, FoxISAPI or Web Connection or RDS is always in the middle (on the Web server typically) actually accessing the data. In fact this means *local* data access or at least local network access. This is where VFP actually excels because of its speed...

The key is to get things wrapped up in such a way that the server can do the work as fast as possible then send it back to the client which can unpack the data and do what it needs. It's all in the packaging mechanism... It's reasonably easy to do this yourself even with VFP code - wwIPStuff demonstrates this...

Technologies like ADO shouldn't be viewed as the new data access mechanism. DOnt forget that ADO is simply the wrapper that replaces plain ODBC connections - it still relies on a data engine to server the data. ADO is a smart choice because it's COM based and can travel anywhere where COM objects can go, which is getting more and more as we speak. NT 5 allows DCOM over HTTP, and you can already use DCOM over TCP/IP today. ADO can be used simply as the wrapper of the data to pass it back and forth including the ability to update...


The point is VFP is fine for this at least for systems that are designed with the network in mind. ADO's slowness and coversion to and from ADO will always be an issue because it's COM and COM imposes overhead you don't have with native data access. But if the application is smart about how data is used and deals with only the data it needs at a time, it'll do fine.