>And one of the reasons for that, interestingly, is that VFP does not have "real" controls: they are painted on, not windows objects.
>
>In the data area, no SQL app will ever come close to matching the performance of a table-based VFP app. True, it may not scale more than say 250 users (although some do -- and working with SQL at larger than those numbers requires special approaches also). But SEEK will outperform SELECT each and very time within that constraint -- and that constraint covers an awful lot of business application scenarios.
>
>Hank

Now you are getting into areas where you apparently have not had enough experience.

If the VFP data is in local tables with a single local user, you are likely correct.


>
>...
>>>Remember that by moving from a VFP app to a SQL/.NET app. you will very likely achieve greater back-end performance and economies of scale. I won't say never, but it's going to be unusual for a VFP app to seem faster overall to end users than a converted app using SQL Server and .NET.
>>
>>Given the same backend and only the front-end changing (VFP or .Net), my experience has been quite different. I've seen dev shops spending a large portion of their time trying to find ways to make the .Net app 'appear' as fast as the VFP app.