>The main reason for the question is b/c VB is the company standard here, even though I do alot of work in VFP. However, if I want to more widely distribute some apps it might cause a problem if they're in VFP.
>
>Also, what do you mean by using MSDE for a database?

MSDE - the Microsoft Data Engine - is the MS replacement for Jet; a small-scale (limited # simultaneous users, maximum data size of 1GB), file-server oriented subset of SQL Server; it provides an OLEDB provider, making it a capable, freely-redistributable data engine usable with any programming environment supporting ODBC or ADO, including VB and VFP (using remote views, SPT or ADO). Any work done implementing the database under MSDE ports directly to SQL Server; it supports the same data types, and the DDL/DML used with MSDE ports directly to SQL Server, so your SPs, triggers, schemas and the like remain the same when upsizing from the MSDE engine to SQL Server, and queries, aside from the connection string, will run without change. It's Microsoft's stepping stone to the C/S SQL Server platform, which while not as capable if an app will remain file-server oriented than VFP's data engine, does leverage whatever experience gained with MSDE directly into SQL Server.

Since it does offer an OLEDB provider, it takes better advantage of ADO than VFP native data files (VFP data is connected via ODBC when accessed through ADO, VFP offers fewer ADO features because of the ODBC driver (VFP 7 has an OLEDB provider in the beta) and VFP native data access is not thread-safe when connected using ODBC), and for single-user or low-end multiuser use; it makes good sense, particularly where you plan to use SQL Server if the app is deployed live; you do not need to buy a copy of SQL Server for testing (it's still advisable) or deploy SQL Server for initial testing. ADO recordsets can also cross COM boundaries - you can return a recordset to a client directly as an object, or pass it as an argument to a COM method.

MSDE does not offer larger size data sets supported via VFP (2GB/file in VFP vs 1GB total database size in MSDE), supports fewer database connections simultaneously than a VFP native database, and isn't as fast as native VFP data using VFP to manipulate it. MSDE via ADO degrades much worse under traffic than VFP native data under VFP. ADO recordsets do not bind directly to native VFP controls, so either conversion to VFP cursors using a tool like VFPCOM, or using ActiveX controls which do bind to ADO data is necessary in VFP.

FWIW, I found it useful to put up a SQL Server 7 setup from my MSDN Universal subscription for testing purposes; both SQL Server 7 and SQL Server 2000 are bundled with the MSDN Universal subscription, and I believe that SQL Server 7 is bundled with Small Business Server 4.5 as well as MS BackOffice. MSDE is redistributable; the licenses with the MSDN subscription are not. It's bundled with the current MDAC, and is used by Access 2K for it's new databases.