Bob,

How much have you really gotten into ADO/OLE-DB???????

I would recommend learning a thing or two about something before bashing it<s>.
I know that sounds a bit harsh, but it is clear to me, based on your comments below, that you have not looked at ADO all that much.

Please note my comments after yours....

>What is ADO to me? Take a shotgun and blow a hole in VFP's head and you have >ADO. Actually, ADO is a great idea if you spend your days accessing data in >spreadsheets and text files etc. I prefer to use a database. I use VFP with >SQL Server. ADO does that too. It uses ODBC. VFP also uses ODBC. So now if we >could just get VFP to use ADO (so it could do the ODBC instead of VFP doing it >directly) we would get to:

ADO uses an OLE-DB provider for ODBC. This was necessary for the huge installed base of ODBC. Except for one thing, ADO does not have the over-head of the ODBC connection manager. Yes, ADO makes use of the ODBC Driver for a particular DB - if you use the ODBC OLE-DB provider. There are specfic OLE-DB provider for Jet (JOLT), SQL-Server, etc. These providers are not ODBC.

Further, there will be OLE-DB providers for Word, Exchange, Excel, etc. The ability to access non-relational data via a recordset should be pretty appealing. This goes way beyond what ODBC holds right now.

Further, all of the OLAP (Plato) technology - is accessible through ADO - specfically, ADO MD (ADO Multi-Dimensional) Objects.

Further, ADO is based on VFP. ADO can have client side cursors that can have indexed fields - which can take advantage of Rushmore Optimization.

Further, unlike a VFP cursor, an ADO RecordSet can be passed accross different processes. So, if you ever wanted the ability to pass a cursor as a parameter to something - you can now do that.

Further, ADO has a remote provider that can access data via HTTP. This is more commonly known as RDS (Remote Data Services).

I could go on....<s>

>1. retrieve strings of data that we could then parse into a cursor we would >have to define.

Wrong...

In ADO, there is a method called GetString() that allows you to retrieve data into a string with a delimter you specify.

>2. not have indexes available on the ado data.

Wrong...

ADO Client Side Cursor Fields support indexes and Rushmore

>3. not be able to use the tableupdate or tablerevert command on the ado object.

Wrong...

ADO's buffering is almost identical to VFP's

>4. Finally be reduced to the level of VB programmers trying to work with database files.

If you mean because you cannot use VFP's DML language and constructs like SCAN...ENDSCAN. Yes, I suppose that can be an issue. Then again, ADO is not meant to be a replacement for the ways in which we currently access data. Rather, ADO provides functionality that is not possible right now. However, in many - if not most C/S apps, you typically don't do things like Scan...EndScan and the like.

As a UI for ADO, VFP is marginal. Better choices are VB or IE - talking to a VB or VFP COM DLL - mainly because of the ActiveX Data Binding issues.

>So we should be excited about ADO because we can let it use ODBC instead of us >using it directly via remote views? This is progress? Of course, I know that >most of us need to read excel databases and word databases all the time and >we've just being dying for ADO to save us.

I chock this last comment up to not being informed<s>.