A few comments....

>I have been recently playing with VB and the new MSDE (a cut down version of SQLS) and was quite surprised by the results.
>

MSDE is *not* a cut down version of SQL-Server. In fact, MSDE IS NOT SQL-Server. Rather, it is a data engine that is 100% compatible with SQL-Server. Althogh it may be just semantics, it is an important distinction to make.

>I create a VFP database with a single table with a single field (a text field 32 characters long).
>
>I then promptly populated it with 87,000-odd records.
>
>The VFP data files took around 1.3mb of disk space.
>
>I then used the VFP Upsizing Wizard to upsize the VFP database to SQLS (MSDE in this case).
>
>The SQLS data files took around 8.5mb of disk space.
>
>I then tested the relative speed of database access VFP v VB by using the form wizards in the repsective development environment.
>
>VFP responded as usual and there was no noticable delay in accessing data.
>
>VB build a data form using ADO. While the performance of the form once data was loaded was comparable to VFP there was a considerable delay when the form was run as the query was executed.
>

You are doing two comparisons here. One is VFP and VB as a dev platform. The other is MSDE vs VFP Data. You comparision basis here is not valid. Essentially, you are taking a C/S platform - VB/MSDE, and imposing a File Server metaphor VFP/DBF data on it. It is apples and oranges. Tell me, did you try and download all 87,000 records in the VB/MSDE environment???? If so, then your tests don't have merit since in a C/S environment, you would never do that. That is not to say that at times you would not do some server-side processing. The deal is that the processing occurs on the server.

OK, onto your questions...


>My questions for discussion are these:
>
>1. Does SQLS use much more disk space than VFP when storing data?

Sure.. There is a lot of schema info and other meta-data stored in MSDE. MSDE is more of a full-fledged database than VFP. Then again, disk is dirt cheap, so I don't see where there is a big issue...

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

Using wizards pretty much blows any any credibility of the test. You have not specified what the query was. My guess is that you took something that VFP does well, because it was pegged toward what VFP does well, and applied it to the VB/MSDE scenario, without optimizing for that platform. That is not a credible comparision of tools....


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


As far as desktop and traditional LAN-based applications are concerned, VFP is usually a better choice. In that scenario, we are talking about a file-server based environment. However, MS could care less about desktop and traditional LAN-based file server applications. The future is web-based and WinDNA apps, which VB/SQL Server is well suited. I have made this point before in that what VFP does best is focused in an area that MS does not see as a significant part fo the future. Otherwise, you would see VFP being promoted more aggressively.

That said, using good practices, I am sure an app that is based on VB/Access/SQL/MSDE could provide as good or better performance than its VFP counterpart. The notion that you cannot write well performing/robust desktop applications with VB/Access/MSDE/SQL is simply not true. What is true is that VFP is the tool you know. It is a tool that has considerable bias in your view. The way you conducted your test bears this point out.

If you want more detail on my views in regard to this subject, go look at the VB vs. VFP thread from a few weeks ago....