>1. Native code compile since VB 5.0. VFP code is interpreted which may result in slower execution. The word from Microsoft Consulting is that VFP will always be interpreted.

In database centric apps, reponse time is usally dictate by database access speed. For database access speed VFP wins hands down vs all other stand-alone languages. When using SQL Server as a backend there should be no different in speed since all the languages will communicate through the same mechanism (ADO, ODBC...).

>2. Our user group was told by Microsoft Consulting that we should migrate our front-ends to lightweight interfaces, like HTML/ASP. They said that we should use VFP for strictly building COM components. SQL Server or MSDE should be our database. Microsoft says so, so I do it. Monkey-see, monkey-do.

This certainly leaves VB out of the picture since n-tier apps data centric.

>3. Rumoured loss of support for VFP. I was told by the IT depart of the 3rd largest telecomm company, that they were told by Microsoft that VFP support would be dropped in 2-3 years. This telecomm was hiring VB/VFP people to convert their VFP apps to VB. It's just hearsay, but sounds real to me. In any case, we've all been hearing rumours of VFP being dropped, but when's the last time anyone heard that VB would be dropped? <g>

Hmmm... second hand information. This is completely opposite to what the management on the VFP team have said.

>Well, these are some of my reasons for switching. I'm doing a few VFP apps now, but I've already told my customers that this will be the last year that I support VFP. After 2K, I'm only doing VB. I'm already migrating some apps from VFP to a Browser/VB/SQLServer model.

I think you owe it to yourself to build an app using browser/VB/SQL and then one using browser/VFP/sql and see which you are happiest with. No sense guessing which is better.

Surf over to www.west-wind.com and see what Rick Strahl is doing with web connect. He has set up servers with 100's of thousands of hits per day. Amazing.