Client/Server von A. Kosch - fehlende Seite(n)

[Thomas Schweikert]

Hallo Herr Kosch,

habe mir vor kurzem ihr o.g. Buch zugelegt.
Im Kapitel über ADO endet die Seite 137
... sieht ADO den folgenden Implementierungsweg vor:

Seite 138 ist dann aber komplett leer.
Gibt es eine Möglichkeit an diese fehlende Seite zu
kommen (Verlag ?)

[Andreas Kosch]

Hallo,

in der Tat ist hier eine Seite verlorengegangen. In meinem Manuskript war folgendes zu lesen:

Das ADO-Objektmodell lehnt sich an die OLE DB-Objekte an und stellt mit Connection; Command und Recordset vergleichbare Objekte bereit. Das Recordset ist das zentrale Objekt von ADO und entspricht dem Rowset-Objekt von OLE DB. Somit liefert auch ADO die Daten in tabellarischer Form.<br>
ADO hat das Ziel, als Middleware die Daten aus den unterschiedlichsten Quellen zu verwalten. Somit muß ADO sowohl mit SQL-Datenbanken umgehen können, aber auch mit eMail-Systemen wie zum Beispiel EXCHANGE. Da somit gravierende Unterschiede zu überbrücken sind, sieht ADO den folgenden Implementierungsweg vor:<br>
1. Das Programm stellt eine Verbindung zu einer Datenquelle (Data Source) her.<br>
2. Das Programm definiert ein Kommando (Command), mit dem der Zugriff auf die gewünschten Informationen möglich wird. Werden Parameter benötigt, steht ein eigenes Parameter-Objekt zur Verfügung.<br>
3. Das Programm sorgt dafür, daß ADO das Kommando ausführt.<br>
4. Wenn als Folge des ausgeführten Kommandos eine Datenmenge zurückgeliefert wird, die in tabellarischer Form vorliegt, puffert ADO diese Daten in einem Cache. Dieser Cache kann je nach Konfiguration entweder auf dem Server oder auch auf dem Client vorgehalten werden. Die Daten werden als Datenmenge vom Recordset-Objekt abgebildet, wobei die Werte einer bestimmten Tabellenspalte von einer Kollektion von Field-Objekten wiedergegeben werden.<br>
5. Werden die Daten im Cache geändert, muß ADO einen Weg vorsehen, wie diese Änderungen in der originalen Datenquelle eingetragen werden.
6. Ein Error-Objekt kann optional für die Fehlerbehandlung verwendet werden.

Sie sehen – mit ADO kommt etwas Neues auf Sie zu. Um den Umstieg von der BDE auf ADO zu erleichtern, stellt Delphi 5 mit TADOQuery, TADOTable, und TADOStoredProc spezielle Komponenten bereit. Alle diese Komponenten können vollständig von TADODataSet oder TADOCommand ersetzt werden und dienen daher nur dazu, die Migration zu erleichtern. Dies bedeutet jedoch auch, daß eine neue Anwendung nicht auf diese Komponenten zurückgreifen sollte und statt dessen direkt über TADODataSet und/oder TADOCommand implementiert wird.

Betrachten Sie ADO nicht als direkten Nachfolger der BDE. Zum einen ist ADO auf OLE DB-Treiber angewiesen – und somit nur auf bestimmte Datenbankformate beschränkt. Der OLE DB-Treiber für Paradox, der von Microsoft zur Verfügung gestellt wird, kann nur bis zum Level 5 auf Paradox-Tabellen zugreifen. Also bleibt für die aktuellen Paradox-Versionen nur die BDE übrig. Und zum anderen greift nun sogar die Microsoft JET-Engine 4.0 aus Microsoft Office2000 beim Zugriff auf dBASE- und Paradox-Tabellen auf die BDE zurück, falls eine installierte BDE auf dem Rechner vorgefunden wird. Dafür gibt es natürlich einen Grund – je nach konkreter Einsatzumgebung ist einmal ADO und das andere Mal die BDE schneller.
&#10

[Patrick Sack]

<br>Danke!
<br>
<br>Mir fehlte (natürlich) auch die Seite.
<br>
<br>mfg
<br>P

Hallo Herr Kosch,

vielen Dank für die schnelle Reakion