And my perspective is that the problems you know about, whether yours or others, were solvable. And that the same level of expertise is needed in developing SQL apps that perform well at those numbers.

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