>1. Does SQLS use much more disk space than VFP when storing data?

It's going to use the same amount if you use similar data types. In VFP, tables are clearly stored in their own files. In SQL Server, the entire database is stored in one file (by default, this can be changed). Since you used the Upsizing wizard, you may not be using the most efficient data types for your table, and they may have created some defaults, user-defined data types, etc. that take additional space. Indexes and system meta-data tables are also stored in this file.

Also, there is a minimum size for the database file (the MDF) which I'm not sure what MSDE's default DB size is. So regardless of how much data is really in the table(s), etc., the DB file size won't go below a certain size, even if there's a bunch of empty space.

>2. Is the delay in loading forms in VB normal - or was the delay due to the method used in the form wizard code?

I'm not much of a VB programmer, but one possibility that comes to mind is that the first time you hit a SQL database, it gets cached, causing a delay. If you're the only one in the DB, when you quit, SQL or MSDE might be dropping its cache, then reloading when you start again. You can fix this if you can change the AutoClose property of the database.

Try using SQL data with VFP, and you might see the same delay.

>3. Where is the logic in MS promoting Access/VB/SQLS when VFP is clearly so superior in desktop and shared database applications?

There was a huge thread on this that I read fairly recently. Essentially, there's strengths and weaknesses in both platforms. VFP is good with data because it's clearly a database tool from the foundation up. VB is good with data more recently because of the improvements. VB is more integrated with the operating system. Access uses a subset of the VB language, so this is a perfect migration for people who have systems written in Access - move the code to VB, move the data to MSDE or SQL Server.

I prefer VFP (like you apparently do) for doing database applications, both file-server and client/server. However, if this app is going to go multi-tier or internet, there are issues that can't be solved easily with VFP, but VB deals with them handily. Future versions of VFP will hopefully close this gap (as has already been demonstrated - VFP is seemingly a 1/2 version behind the cool stuff VB gets).

Also remember that VB is Microsoft's flagship development tool, which means it gets all the attention (read: marketing dollars). Us VFP developers have to understand that and just continue to write great VFP applications in spite of what Microsoft tries to shove down our throats.