ADO und VFP

Einleitung

ADO (ActiveX Data Objects) ist das neue Kürzel von Microsoft für ‚Universal Data Access' also im Prinzip jede Art von Datenzugriff. Mit ADO ist es möglich auf die unterschiedlichsten Arten von Datenquellen zuzugreifen, auch nicht relationale Daten stehen mit ADO.

Kürzel, Kürzel, Kürzel

ADO und die ‚Anderen'

ADO ist ein ‚neues' Kürzel von Microsoft. Wie ist nun ADO mit DAO, RDO, ODBC, OLE DB usw. zu vergleichen oder verwandt?

ADO ist eine Schicht oberhalb von anderen ‚Data Providern'.

Was weitere Zugriffsarten wie DAO und RDO angeht: Die sind veraltet und können ad acta gelegt werden. DAO war eine Möglichkeit auf Jet (MS Access Datenbanken) zuzugreifen und hauptsächlich für VB gedacht. RDO arbeitet auf einer Ebene mit OLE DB zusammen. OLE DB ist der low level Zugriff auf Daten und wird auch von C++ Programmierern weiter genutzt werden. Der Zugriff auf Daten via ADO ist aber die erklärte Methode von Microsoft für die Zukunft.

MDAC, RDS

MDAC (Microsoft Data Access Components) ist einfach nur ein Toolkit das alle möglichen Treiber für die neuen Technologien enthält (ADO, OLE DB, ODBC). Das Toolkit kann von der MS Web Site geladen werden und mit allen Tools des Visual Studios verwendet werden. RDS bedeutet Remote Data Sercvice und ist eine Erweiterung von ADO, um einen Datenzugriff via Internet zu ermöglichen.

Infos

Informationen zu all diesen Techniken und Kürzeln findet man unter:

http://www.microsoft.com/data

Das ADO Objekt Modell

Da es sich bei ADO um eine ActiveX Architektur handelt, benötigt man als Dokumentation das ADO Objekt Modell um sinnvoll arbeiten zu können.

So stellt sich die Hierarchie der ADO Objekte dar.

Die Objekte, die in der Mehrzahl vorhanden sind (Errors, Parameters und Fields stellen ‚Collections' dar. Diese Collections können mit VFP Array Properties verglichen werden. Allerdings besteht normalerweise nicht nur ein Zugriff über den Index, sondern auch per Name (z.B. orsCustomers.Fields("CompanyName").Value ).

Man hat es also bei ADO mit relativ wenigen Objekten zu tun. Deshalb sollte es auch nicht allzu schwer fallen damit umzugehen. Dokumentation zu den Objekten, Methoden und Attributen gibt es entweder auf der Web Seite bei Microsoft oder beim MDASDK (Microsoft Data Access SDK).

Wenn man sich das Zusammenspiel der verschiedenen Objekte verdeutlichen möchte, so ist folgende Grafik besser geeignet:

An diesem Modell ist zu erkennen, daß ein Recordset (das Objekt, das die eigentlichen Daten verwaltet) auf verschiedene Weise erzeugt werden kann. Die Wege werden später noch erläutert.

Entscheidend ist, daß diese ADO Objekte alle entweder durch Andere erzeugt werden (z.B. Recordset durch Command.Execute) oder durch einen CreateObject Befehl in VFP erzeugt werden können und dann wie andere Automations Objekte manipuliert werden können.

Connection

Das ‚Connection' Objekt stellt die Verbindung zur Datenquelle her. Dieses Objekt dient dazu die Verbindungsparameter zu verwalten, ähnlich wie die ‚Remote Connection' im DBC von VFP. Auch hier kann man Verbindungen über die definierten DSNs aufbauen. Das heißt die Verbindung kann über die ODBC Datenquellen laufen. Dies ist die Art, die am bekanntesten sein dürfte. Auch die Transaktionsverwaltung wird über das Connection Objekt geregelt.

Verbindungen können auch ohne DSNs erstellt werden allerdings muß dazu der ‚Provider' der Datenquelle bekannt sein. Am einfachsten findet man den Connection String heraus wenn beispielhaft eine solche Quelle als DSN definiert und dann bei aufgebauter Verbindung den ConnectionString der Verbindung sich anzeigen läßt.

Errors

Die Errors Collection dient der Fehlerbehandlung. Sie besteht aus Error Objekten. In diesen Objekten stehen Informationen (Klartext, originale Fehlernummer, usw. zu den aufgetretenen Fehlern). Auf diese Objekt wird hier nicht weiter eingegangen.

Command

Das Command Objekt bietet die Möglichkeit über eine (aktive) Connection Befehle an die verbundene Datenquelle abzusetzen. Welche Befehle möglich und sinnvoll sind hängt von der Art der Datenquelle und dem verwendeten Treiber ab. Diesem Command Objekt können über die Parameters Collection Parameter mitgegeben werden. Das Ergebnis der Execute Methode dieses Command Objektes kann dann ein RecordSet sein.

RecordSet

Das RecordSet Objekt enthält die eigentlichen Daten. Die Daten sind in der Fields Collection dieses RecordSet Objektes enthalten. Das RecordSet Objekt steht jeweils auf einem Record (Datenasatz), der bearbeitet werden kann. Je nach Art dieses Recordsets kann mit diesem Datensatz gearbeitet werden. Auf dem RecordSet finden die eigentlichen Datenoperationen statt (Udate, Delete, Insert). Aber auch das ‚Bewegen' über die Daten (First, Next, Last, Previous) findet über Methoden des RecordSets statt. Das RecordSet Objekt mit der Fields Collection wird noch genauer betrachtet. Übrigens steckt hinter dem RecordSet Objekt ein FoxPro Cursor! Dies sei hier aber nur als Tatsache vorgestellt direkt nutzen kann man diese Information nicht.

Die Nutzung des Command Objektes

Das Command Objekt kann zum einen dazu benutzt werden um parametrisierte Abfragen abzusetzen:

#Define adChar  129
#Define adparamInput    1
parameter = "U%"
oConnection.Open("tastrade")
oCommand.activeconnection = oConnection
oCommand.commandtext = "Select * From customer Where country Like ?"
oParameter = oCommand.CreateParameter("country",adChar,;
  adParamInput,Len(parameter),parameter)
ocommand.Parameters.Append(oParameter)
oRecordSet = ocommand.execute()

Zum anderen können über das Command Objekt auch DDL (Data Definition Language) Befehle abgesetzt werden die kein RecordSet als Ergebnis haben. Beispielsweise können so Tabellen angelegt und verändert werden. Es können auch stored procedures ausgeführt werden.

Dies gilt allerdings nicht für VFP DBCs!

RecordSet

Zum Arbeiten mit Record Sets:

Ein Recordset hat als eine der wichtigsten Methoden die open Methode. Damit kann ein Record Set erstellt werden. Die open Methode hat fünf Parameter:

• Source: Die Datenquelle: z.B. ein SQL Statement, oder eine Tabelle
• Connection: Die Verbindung muß angegeben werden.
• CursorType: Die Art des Cursors s.u.
• Locking: Das Sperrverhalten (read only, optimistisch, pessimistisch)

Ein RecordSet repräsentiert einen Cursor.

Es gibt vier verschiedene Arten von Cursor in ADO:

• Forward only: Nur vorwärts ‚Bewegungen' sind möglich ideal wenn nur ein Durchgang durch den Cursorr benötigt wird. Veränderungen an Datensätzen durch Andere werden nicht berücksichtigt.

• Keyset: Änderungen von Anderen sind sichtbar, Hinzugefügte Sätze nicht.

• Dynamic: Alle Änderungen von Anderen sind sichtbar.

• Static: Es sind keine Änderungen von Anderen sichtbar, aber vorwärts und rückwärts ‚Bewegungen sind möglich.

Der Cursor kann sowohl als Client-Side Cursor als auch als Server-Side Cursor geführt werden. Der Server Cursor ist der Default. Dies kann verändert werden durch das Setzen des CursorLocation Properties auf 3.

Das RecordSet Objekt hat eine Filter Eigenschaft. Damit ist es möglich die Daten des Cursors selektiv zu betrachten.

Es gibt eine Find Methode um Daten im Cursor zu finden.

Ein Client-Side Cursor kann indiziert werden, indem ein Feld als optimized gesetzt wird:

oRecordSet.Fields('company_name').Properties('optimize') = .T.

Das Rücksetzen auf .F. beseitigt den Index wieder.

Recordsets können auch in lokalen Dateien zwischengespeichert werden. Es handelt sich dann um ‚disconnected Recordsets' mit diesem Feature kann eine ähnliche Funktionalität erreicht werden wie durch VFP offline Views. Die Probleme, die dann beim Update entstehen können müssen durch den Programmierer, oder indirekt durch den Anwender behandelt werden.

oRecordSet.Save("c:\rs\foo.rs")

Sie können dann wieder geöffnet werden. Die Änderungen können auch dann an eine Datenquelle weitergegeben werden:

oRecordSet.Open("c:\temp\foo.rs",,3,3)
oConnection.open("tastrade","","")
oRecordset.activeconnection = oConnection
orecordset.updatebatch()

Vorteile von ADO

Nachfolgende Vorteile sind mit dem Einsatz von ADO verbunden:

• Der Einsatz von ADO mit VFP hat vor allem Vorteile beim Bau von Komponenten und bei der Zusammenarbeit mit Komponenten. ADO Recordsets können als Parameter zwischen Komponenten übergeben werden. Das gilt sowohl für VFP Komponenten, als auch für andere (z.B. VB).
• Man hat mit VFP den Vorteil, daß man interaktiv Datenzugriffsobjekte erzeugen und ‚ausprobieren' kann. Wenn man die Eigenschaften der Objekte kennt kann man sie im ansprechen und sie sind dann auch im Debugger sichtbar.
• Man kann mit VFP Komponenten erstellen, die auch Daten an andere Umgebungen übergeben, ohne daß man ein komplexes Interface bauen muß, oder eine ASCII Schnittstellen Datei.
• Es ist möglich (neu!) VFP Controls an ADO Felder zu binden (Controlsource). Auch das Grid OCX kann nun in VFP an ADO Daten gebunden werden.

Nachteile von ADO

Nachfolgende Nachteile sind mit dem Einsatz von ADO verbunden:

• Man muß das Objekt Modell kennenlernen und die Methoden anzuwenden lernen. Manches ist auch nur über Versuch und Irrtum heraus zu bekommen (wie bei vielen COM Objekt Modellen).
• Manche Dinge funktionieren anders, als man es von VFP ‚gewohnt' ist (Filter, Find, Reccount).
• Die Zusammenarbeit mit VFP funktioniert noch nicht reibungslos und nicht mit allen Conztrols (VFP Grid!).
• Die unterschiedlichen Datenquellen für ADO liefern möglicherweise Daten in unterschiedlichen Formaten zurück, so daß möglicherweise eine Nachbearbeitung vor der Verwendung notwendig ist.
• Die Datentypen selbst können je nach Datenquelle unterschiedlich sein.
• Die VFP Datenumgebung kann nicht mit ADO verwendet werden.
• Ohne das VFPCOM Tool kann nicht auf Events reagiert werden.

RDS

Auf die Funktionalität von RDS für den Remote Data Access soll hier nicht im Detail eingegangen werden. Die Aufgabe von RDS ist es Daten über das HTTP Protokol (d.h. über das Internet) einem Client zur Verfügung zu stellen und zwar in Form eines ADO Recordsets.

Zu diesem Zweck existieren drei weitere Objektdefinitionen:

• DataSpace: Bietet die Möglichkeit Eine Verbindung vom Client zum COM Objekt auf dem Server zu verwalten (ähnlich dem Connection Objekt)
• DataFactory: Ein COM Objket auf dem Server, das dazu dient die Daten für den Client bereit zu stellen. Die Aufgabe diese Objektes ist es Recordsets zwischen Server und Client zu übertragen.
• DataControl: Das COM Objekt, das die Daten auf dem Client eigentlich verwaltet. Es enthält dann ein Recordset Objekt, welches ein (von oben) bekanntes ADO Recordset Objekt ist.

Eine Verbindung zu Remote Daten kann auch über das ADO Connection Objekt erreicht werden, wenn als Provider ‚MS Remote.1' angegeben wird und die URL des Servers als ‚Remote Server' im Connection String übergeben wird.

RDS ist also deshalb interessant weil mit dieser Möglichkeit alle ADO Features auch über das Internet hinweg verfügbar sind. Man sollte dabei allerdings auf Datensicherheit achten, und möglichst nicht gerade mit Server Side Cursoren arbeiten, oder einen Full Table Scan als Client Side Cursor erstellen. Diese Problematik ist allerdings von Client/Server Lösungen her schon bekannt!

Zusammenfassung

ADO ist die Methode um auf alle möglichen Datenquellen zuzugreifen. Es wird in Zukunft mehr und mehr direkte Treiber für ADO (OLE DB) geben.

ADO sollte mit VFP verwendet werden, wenn man COM Komponenten baut, da die Verbindung über ADO Recordsets über alle möglichen Entwicklungstools verwendet werden kann. ADO bietet sich also als Datenzugriffsmethode besonders an wenn mit VFP middle Tier Module gebaut werden sollen.

ADO ist also für VFP Programmierer interessant wenn nicht nur VFP als Frontend eingesetzt wird, sondern mit VFP COM Komponenten erstellt werden.

ADO bietet die Möglichkeit einen universellen Datenzugriff über das Internet zu ermöglichen (RDS).

Was weitere Zugriffsarten wie DAO und RDO angeht: Die sind veraltet und können ad acta gelegt werden. DAO war eine Möglichkeit auf Jet (MS Access Datenbanken) zuzugreifen und hauptsächlich für VB gedacht. RDO arbeitet auf einer Ebene mit OLE DB zusammen. OLE DB ist der low level Zugriff auf Daten und wird auch von C++ Programmierern weiter genutzt werden. Der Zugriff auf Daten via ADO ist aber die erklärte Methode von Microsoft für die Zukunft.

MDAC, RDS

MDAC (Microsoft Data Access Components) ist einfach nur ein Toolkit das alle möglichen Treiber für die neuen Technologien enthält (ADO, OLE DB, ODBC). Das Toolkit kann von der MS Web Site geladen werden und mit allen Tools des Visual Studios verwendet werden. RDS bedeutet Remote Data Sercvice und ist eine Erweiterung von ADO, um einen Datenzugriff via Internet zu ermöglichen.

Infos

Informationen zu all diesen Techniken und Kürzeln findet man unter:

http://www.microsoft.com/data

Das ADO Objekt Modell

Da es sich bei ADO um eine ActiveX Architektur handelt, benötigt man als Dokumentation das ADO Objekt Modell um sinnvoll arbeiten zu können.

So stellt sich die Hierarchie der ADO Objekte dar.

Die Objekte, die in der Mehrzahl vorhanden sind (Errors, Parameters und Fields stellen ‚Collections' dar. Diese Collections können mit VFP Array Properties verglichen werden. Allerdings besteht normalerweise nicht nur ein Zugriff über den Index, sondern auch per Name (z.B. orsCustomers.Fields("CompanyName").Value ).

Man hat es also bei ADO mit relativ wenigen Objekten zu tun. Deshalb sollte es auch nicht allzu schwer fallen damit umzugehen. Dokumentation zu den Objekten, Methoden und Attributen gibt es entweder auf der Web Seite bei Microsoft oder beim MDASDK (Microsoft Data Access SDK).

Wenn man sich das Zusammenspiel der verschiedenen Objekte verdeutlichen möchte, so ist folgende Grafik besser geeignet:

An diesem Modell ist zu erkennen, daß ein Recordset (das Objekt, das die eigentlichen Daten verwaltet) auf verschiedene Weise erzeugt werden kann. Die Wege werden später noch erläutert.

Entscheidend ist, daß diese ADO Objekte alle entweder durch Andere erzeugt werden (z.B. Recordset durch Command.Execute) oder durch einen CreateObject Befehl in VFP erzeugt werden können und dann wie andere Automations Objekte manipuliert werden können.

Connection

Das ‚Connection' Objekt stellt die Verbindung zur Datenquelle her. Dieses Objekt dient dazu die Verbindungsparameter zu verwalten, ähnlich wie die ‚Remote Connection' im DBC von VFP. Auch hier kann man Verbindungen über die definierten DSNs aufbauen. Das heißt die Verbindung kann über die ODBC Datenquellen laufen. Dies ist die Art, die am bekanntesten sein dürfte. Auch die Transaktionsverwaltung wird über das Connection Objekt geregelt.

Verbindungen können auch ohne DSNs erstellt werden allerdings muß dazu der ‚Provider' der Datenquelle bekannt sein. Am einfachsten findet man den Connection String heraus wenn beispielhaft eine solche Quelle als DSN definiert und dann bei aufgebauter Verbindung den ConnectionString der Verbindung sich anzeigen läßt.

Errors

Die Errors Collection dient der Fehlerbehandlung. Sie besteht aus Error Objekten. In diesen Objekten stehen Informationen (Klartext, originale Fehlernummer, usw. zu den aufgetretenen Fehlern). Auf diese Objekt wird hier nicht weiter eingegangen.

Command

Das Command Objekt bietet die Möglichkeit über eine (aktive) Connection Befehle an die verbundene Datenquelle abzusetzen. Welche Befehle möglich und sinnvoll sind hängt von der Art der Datenquelle und dem verwendeten Treiber ab. Diesem Command Objekt können über die Parameters Collection Parameter mitgegeben werden. Das Ergebnis der Execute Methode dieses Command Objektes kann dann ein RecordSet sein.

RecordSet

Das RecordSet Objekt enthält die eigentlichen Daten. Die Daten sind in der Fields Collection dieses RecordSet Objektes enthalten. Das RecordSet Objekt steht jeweils auf einem Record (Datenasatz), der bearbeitet werden kann. Je nach Art dieses Recordsets kann mit diesem Datensatz gearbeitet werden. Auf dem RecordSet finden die eigentlichen Datenoperationen statt (Udate, Delete, Insert). Aber auch das ‚Bewegen' über die Daten (First, Next, Last, Previous) findet über Methoden des RecordSets statt. Das RecordSet Objekt mit der Fields Collection wird noch genauer betrachtet. Übrigens steckt hinter dem RecordSet Objekt ein FoxPro Cursor! Dies sei hier aber nur als Tatsache vorgestellt direkt nutzen kann man diese Information nicht.

Die Nutzung des Command Objektes

Das Command Objekt kann zum einen dazu benutzt werden um parametrisierte Abfragen abzusetzen:

#Define adChar  129
#Define adparamInput    1
parameter = "U%"
oConnection.Open("tastrade")
oCommand.activeconnection = oConnection
oCommand.commandtext = "Select * From customer Where country Like ?"
oParameter = oCommand.CreateParameter("country",adChar,;
  adParamInput,Len(parameter),parameter)
ocommand.Parameters.Append(oParameter)
oRecordSet = ocommand.execute()

Zum anderen können über das Command Objekt auch DDL (Data Definition Language) Befehle abgesetzt werden die kein RecordSet als Ergebnis haben. Beispielsweise können so Tabellen angelegt und verändert werden. Es können auch stored procedures ausgeführt werden.

Dies gilt allerdings nicht für VFP DBCs!

RecordSet

Zum Arbeiten mit Record Sets:

Ein Recordset hat als eine der wichtigsten Methoden die open Methode. Damit kann ein Record Set erstellt werden. Die open Methode hat fünf Parameter:

• Source: Die Datenquelle: z.B. ein SQL Statement, oder eine Tabelle
• Connection: Die Verbindung muß angegeben werden.
• CursorType: Die Art des Cursors s.u.
• Locking: Das Sperrverhalten (read only, optimistisch, pessimistisch)

Ein RecordSet repräsentiert einen Cursor.

Es gibt vier verschiedene Arten von Cursor in ADO:

• Forward only: Nur vorwärts ‚Bewegungen' sind möglich ideal wenn nur ein Durchgang durch den Cursorr benötigt wird. Veränderungen an Datensätzen durch Andere werden nicht berücksichtigt.

• Keyset: Änderungen von Anderen sind sichtbar, Hinzugefügte Sätze nicht.

• Dynamic: Alle Änderungen von Anderen sind sichtbar.

• Static: Es sind keine Änderungen von Anderen sichtbar, aber vorwärts und rückwärts ‚Bewegungen sind möglich.

Der Cursor kann sowohl als Client-Side Cursor als auch als Server-Side Cursor geführt werden. Der Server Cursor ist der Default. Dies kann verändert werden durch das Setzen des CursorLocation Properties auf 3.

Das RecordSet Objekt hat eine Filter Eigenschaft. Damit ist es möglich die Daten des Cursors selektiv zu betrachten.

Es gibt eine Find Methode um Daten im Cursor zu finden.

Ein Client-Side Cursor kann indiziert werden, indem ein Feld als optimized gesetzt wird:

oRecordSet.Fields('company_name').Properties('optimize') = .T.

Das Rücksetzen auf .F. beseitigt den Index wieder.

Recordsets können auch in lokalen Dateien zwischengespeichert werden. Es handelt sich dann um ‚disconnected Recordsets' mit diesem Feature kann eine ähnliche Funktionalität erreicht werden wie durch VFP offline Views. Die Probleme, die dann beim Update entstehen können müssen durch den Programmierer, oder indirekt durch den Anwender behandelt werden.

oRecordSet.Save("c:\rs\foo.rs")

Sie können dann wieder geöffnet werden. Die Änderungen können auch dann an eine Datenquelle weitergegeben werden:

oRecordSet.Open("c:\temp\foo.rs",,3,3)
oConnection.open("tastrade","","")
oRecordset.activeconnection = oConnection
orecordset.updatebatch()

Vorteile von ADO

Nachfolgende Vorteile sind mit dem Einsatz von ADO verbunden:

• Der Einsatz von ADO mit VFP hat vor allem Vorteile beim Bau von Komponenten und bei der Zusammenarbeit mit Komponenten. ADO Recordsets können als Parameter zwischen Komponenten übergeben werden. Das gilt sowohl für VFP Komponenten, als auch für andere (z.B. VB).
• Man hat mit VFP den Vorteil, daß man interaktiv Datenzugriffsobjekte erzeugen und ‚ausprobieren' kann. Wenn man die Eigenschaften der Objekte kennt kann man sie im ansprechen und sie sind dann auch im Debugger sichtbar.
• Man kann mit VFP Komponenten erstellen, die auch Daten an andere Umgebungen übergeben, ohne daß man ein komplexes Interface bauen muß, oder eine ASCII Schnittstellen Datei.
• Es ist möglich (neu!) VFP Controls an ADO Felder zu binden (Controlsource). Auch das Grid OCX kann nun in VFP an ADO Daten gebunden werden.

Nachteile von ADO

Nachfolgende Nachteile sind mit dem Einsatz von ADO verbunden:

• Man muß das Objekt Modell kennenlernen und die Methoden anzuwenden lernen. Manches ist auch nur über Versuch und Irrtum heraus zu bekommen (wie bei vielen COM Objekt Modellen).
• Manche Dinge funktionieren anders, als man es von VFP ‚gewohnt' ist (Filter, Find, Reccount).
• Die Zusammenarbeit mit VFP funktioniert noch nicht reibungslos und nicht mit allen Conztrols (VFP Grid!).
• Die unterschiedlichen Datenquellen für ADO liefern möglicherweise Daten in unterschiedlichen Formaten zurück, so daß möglicherweise eine Nachbearbeitung vor der Verwendung notwendig ist.
• Die Datentypen selbst können je nach Datenquelle unterschiedlich sein.
• Die VFP Datenumgebung kann nicht mit ADO verwendet werden.
• Ohne das VFPCOM Tool kann nicht auf Events reagiert werden.

RDS

Auf die Funktionalität von RDS für den Remote Data Access soll hier nicht im Detail eingegangen werden. Die Aufgabe von RDS ist es Daten über das HTTP Protokol (d.h. über das Internet) einem Client zur Verfügung zu stellen und zwar in Form eines ADO Recordsets.

Zu diesem Zweck existieren drei weitere Objektdefinitionen:

• DataSpace: Bietet die Möglichkeit Eine Verbindung vom Client zum COM Objekt auf dem Server zu verwalten (ähnlich dem Connection Objekt)
• DataFactory: Ein COM Objket auf dem Server, das dazu dient die Daten für den Client bereit zu stellen. Die Aufgabe diese Objektes ist es Recordsets zwischen Server und Client zu übertragen.
• DataControl: Das COM Objekt, das die Daten auf dem Client eigentlich verwaltet. Es enthält dann ein Recordset Objekt, welches ein (von oben) bekanntes ADO Recordset Objekt ist.

Eine Verbindung zu Remote Daten kann auch über das ADO Connection Objekt erreicht werden, wenn als Provider ‚MS Remote.1' angegeben wird und die URL des Servers als ‚Remote Server' im Connection String übergeben wird.

RDS ist also deshalb interessant weil mit dieser Möglichkeit alle ADO Features auch über das Internet hinweg verfügbar sind. Man sollte dabei allerdings auf Datensicherheit achten, und möglichst nicht gerade mit Server Side Cursoren arbeiten, oder einen Full Table Scan als Client Side Cursor erstellen. Diese Problematik ist allerdings von Client/Server Lösungen her schon bekannt!

Zusammenfassung

ADO ist die Methode um auf alle möglichen Datenquellen zuzugreifen. Es wird in Zukunft mehr und mehr direkte Treiber für ADO (OLE DB) geben.

ADO sollte mit VFP verwendet werden, wenn man COM Komponenten baut, da die Verbindung über ADO Recordsets über alle möglichen Entwicklungstools verwendet werden kann. ADO bietet sich also als Datenzugriffsmethode besonders an wenn mit VFP middle Tier Module gebaut werden sollen.

ADO ist also für VFP Programmierer interessant wenn nicht nur VFP als Frontend eingesetzt wird, sondern mit VFP COM Komponenten erstellt werden.

ADO bietet die Möglichkeit einen universellen Datenzugriff über das Internet zu ermöglichen (RDS).