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>.
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement