Hey Jim, thanks for the reply.

>1) DBF's only get speed by using Rushmore which is not a feasible technology over HTTP connections

This is only relevant if the client is using the data directly. While I have seen this done, I have not yet seen it done successfully with any backend. Have you? First of all this would require that the client have a propietary app installed on the machine as opposed to a browser.

Most web apps (that I am involved with or have seen profiled) use a backend server to do the querying and another mechanism (usually HTML, but XML is fast on the rise here) for transport.


>2) On the net speed is related to moving the data over telephone lines which are slower than any data access technology rendering the faster prformance of DBF's a moot point.

The speed of a website is related to at least 2 factors: the load on the server, and the bandwidth available to deliver content (and obviously the weight of that content). The only thing that I can do as a developer to help the bandwidth issue is to make sure my website isn't trying to send you a dumptruck load of content. The other factor, server load, is directly related to VFP's speed. Using a faster datastore combined with hardware designed for the task is the formula for a fast site. Again, I am assuming that we are talking about a typical website that uses HTML or XML as the transport mechanism.

>3) other data technologies have built in security features beyond what VFP can give us with the native database

Agreed, but I am not sure I see where this is relevant. In a typical data driven/e-commerce site, the backend is separated from the client by the web server and the server application. Security as far as the actual data files go becomes a moot point (again, speaking from my personal knowledge only, I am sure that for any website, there is somebody that can break in).

I am sure you are not learning anything from me, I just wanted to make sure I knew the things you do about dbfs and websites.

Erik Moore
Clientelligence