>
Not in my opinion, no. You've still got the problem of binding to controls. Remote views and SPT work just fine,
<

Remote views don't scale. They present and introduce all sorts of maint. problems. Binding controls with ADO is very easy. 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. SPT may work find, but RV's don't. And as far as the problem of binding you bring up with ADO, that problem does not exist.


<
Unless you've got to use something like RDS, the extra work involved outweighs any advantage ADO might have.
>

There is little or no extra work. And, if you are trying to build n-tier apps, RV's again don't work..


>
Since VB and VC++ have no easy, native way to access data, technologies such as ADO are necessary to make data access possible and easy. VFP developers already have an easy, native way to access data. Why switch just because something else is the hot new technology to use?
<

Define native data. In VFP, you mean DBF's. They don't scale to the levels of SQL Server. DBF's are not substitutes for SQL Server data - period. The statement about VFP developers already having an easy/native way to access and work with data would have merit if native VFP data were a perfect, or close to perfect substitute for SQL Server. In fact, it isn't even close.