>Remote views don't scale.

Not if they are defined in a common dbc.

>Binding controls with ADO is very easy.

Singular controls. But VFP grids don't bind to recordsets. This is a real factor. In many cases, an ActiveX grid is not a viable alternative.

>I will grant you that SPT is fine. But RV's are incomplete wrappers around SPT. At least with SPT, you can reference stored procs. You cannot do that with RV's.

Who says that you can't use SPT in conjunction with RVs?

>SPT may work fine, but RV's don't.

RVs work fine for what they were designed for: quick and dirty updatable access to back-end data. They have their place, IMO, as does SPT.

> And, if you are trying to build n-tier apps, RV's again don't work..

Touché.

>Define native data. In VFP, you mean DBF's. They don't scale to the levels of SQL Server.

In many (most?) cases, they don't need to. Conversely, SQL Server doesn't scale down cost-wise to the level of use that dbfs fit the need for.

>DBF's are not substitutes for SQL Server data - period.

Agreed. They serve two different needs with some common ground.