>>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).