General information
Category:
VFP Compiler for .NET
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
...
>>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.
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only