Gerald,

In your experience of developing and comparing VFP and Dot Net, if you take the 'Fastest ' pssible way of doing things in Dot Net, what is the likely speed comparison for doing normal mundane things like:

1. Displaying a screen , with say no Grid
2. Displaying a screen with 2 tabs, Details and Grid, with say 30 transactions out of a table of 30,000 being selected into the grid
3. Running a query (for reporting purposes) which takes say 30 transactions out of a 30,000 record table


Example: in the last year, I rewrote a VFP job-costing system for a construction company in .NET. It's a medium-size app with 8 forms (customer, job, timesheets, labor&materials, invoicing, couple of reports).

Not a small app, but certainly not a big complicated one. Most forms have either tabs and/or master/detail grids. The users were satisfied with the performance of the new system, and found no differences. The back-end database is now MSDE.

(And as I mentioned in my earlier post, I don't see much speed difference between binding a grid to a table with 100 rows or 10,000 rows...though the latter number is something that isn't often necessary).

If your queries are optimized (and I prefer stored procedures where possible) and your database set up correctly in terms of keys, your data access should be as good as VFP. Even though you *can* use the VFP OLE-DB Provider for data access with .NET, I would recommend MSDE/SQL-Server.

Going from a VFP app to .NET may mean a total re-think of your data access, depending on how you were doing it - if your apps were binding grids and other controls directly to the back-end VFP data, then you have some re-architecting to do.

Now, in fairness, some have reported that forms with a number of bound controls will display a little slower than VFP. I honestly cannot say I've observed that. My user base has at least 256 MB of memory and some have 512 MB. As I said, I've done several .NET apps, and performance has never been a complaint.

No, I don't think you're being picky, these are important factors. I've dealt with users who were highly sensitive to even small delays.

My advice to you? Take some time, crack open the VS.NET box, create a sample form and retrieve some data from a back-end data source, and see for yourself. You'll never be convinced until you do so. Again, I or others on the .NET forum will be happy to help with any specifics.

Kevin