>>>I think it would be hard to get better performance than that.
>>
>>I'm sorry, but I don't share your performance raves...
>>
>>I'm in the process of switching an extremely high volume Web application from local data
>>to SQL Server and we're seeing a slowdown of at least twice the request times compared
>>to running against local data using the same network paths\setup.
>>
>>The need is definitely there unfortunately (stability and security), and SQL is really the
>>only answer to these problems, but performance is not amongst the reasons we're making the
>>move. The VFP engine runs circles around SQL in most situations in terms of speed.
>>
>>+++ Rick ---
>
>Hi Rick;
>
>I agree with your comment on a VFP database. It's speed is unquestioned. I find these days that most people are talking client/server (ie, Sql Server, Oracle, etc). They just roll their eyes at dbfs. I get lots of comments about how 'slow' ODBC is and if you want any kind of performance you need a product that can talk to native drivers (like Powerbuilder). The arguments are not based on facts but that is hardly ever a deterrent. Anyway, I just like pointing out that VFP and ODBC can provide as good an interface to a back end database as you could get from any other product.
>
>I find VFP a hard sell these days because people think of it as a dbf product (not that there is anything wrong with that!). I like to promote it as an excellent client/server tool (that is, it is now going to cost you a whole lot more).

I agree, and I'd also like to add an idea that I've mentioned before.

With any C/S app that uses VFP, the best way to optimize speed of performance is to periodically download control tables (lookups, etc.) as necessary (hourly, daily etc.) and then execute much of the work locally. (Unfortunately, this idea won't work for all applications, particularly for systems requiring real-time data.) This can be best accomplished by having two 'View' databases (DBC's). Your app uses the first DBC which is a *recent* copy of select tables from the server. Use a different app to update the tables in the second DBC. (this app should be running continually somewhere). Using flags, and some sort of timing mechanism in the first app, you can change the local 'View' database to the one most recently updated. Then the second app, updates the first database. Your main app is continually switching DBC's, using the most recenlt updated one. This should approximate real-time data and vastly improve local performance.

Also, keep in mind that VFP 'thinks' a lot harder than SQL Server. You can greatly improve performance on the server if you closely review the types of SQL's that are being executed and optimize the indexes necessary to perform the select. SQL Server will probably never be as fast as VFP, but when the result set is small, the overall search time difference shouldn't be hugely noticable in many cases and when the result set is large, it may be better to sacrifice some real-time data in order to improve efficiency by utilizing the periodic downloads that I mentioned above.

HTH