I second that notion. To me, the extremely fast nature of local VFP table/cursor access should really be pushed from a marketing standpoint. I did a project last year where a single MSSQL box was queried over the network, all day, by multiple clients, often for the same ~4 million rows. I setup some automated stuff to build a VFP7 DBC every morning from the remote MSSQL data, and the locally-running programs then used the local reference tables instead of going over the network; thruput went from ~2 seconds per query against MSSQL to something like ~0 seconds against a local DBC.

I think positioning VFP as an option for (large) sets of cache data, when SQL Server is the real backend, is a winning marketing tactic. With the new OLEDB provider, there should be 100% parity with VFP data stores from ADO.NET. That is a big win and a reason to not use Access.

>Hi Ken,
>
>I think that Microsoft should push VFP more as the best middle-tier engine to build components working "against SQL Server database", rather than pushing the database aspect of VFP.
>