Als VB (Visual Basic) ursprünglich herauskam, gab es hierfür kein eigentliches Datenmodell. Die Informationen mußten per API (Application Programming Interface) vom SQL-Server geholt werden und zwar über VBSQL. Da VBSQL haargenau auf den SQL-Server abgestimmt war und erst wenige Leute (Anm. d. Ü.: Entwickler) diesen SQL-Server hatten, war das ganz schön schwierig, trotz der einfachen Handhabungs- und Programmierarbeiten.

Früher gab es zwei Datenbank-Marktsegmente:

1. Den ISAM (Index Sequential Access Method) - Bereich mit dBASE, Paradox und Btrieve und Hunderten von Entwicklern auf dieser Schiene
2. Den sehr viel kleineren Markt mit allerdings enormer Kapitalbindung:
   Die MAINFRAME-Datenbanken mit ORACLE, INFORMIX, DB2 etc.
   SQL-Server spielte eine unscheinbare Rolle im zweiten Segment in den frühen 90ern.

Dann kam Visual Basic 3 mit der Jet-Engine (Anm. d.Ü.: In Access als Basis) und überrollte den ISAM-Markt. Mit dieser Entwicklung kam DAO (s.o.) mit speziellen Werkzeugen für diesen Bereich.

Außerdem wurde damit eine Hintertür für den Datenbank-Zugriff auf die Mainframe-Datenbanken per ODBC (Open DataBase Connectivity) geschaffen. Das ODBC-API wurde auf Nachfrage für Entwickler geschrieben, aber hatte Startschwierigkeiten, weil die Kunden mit dieser Art zu arbeiten noch nicht vertraut waren.

Als erste Schnittstelle für Visual Basic und SQL-Server ging VBSQL den gleichen Weg wie das
C-Interface, obwohl VBSQL ursprünglich für Sybase und SQL-Server gedacht war, schied Sybase später aus. Die RDOs (s.o.) wurden als einfach handzuhabende Möglichkeit entwickelt,
auf SQL-Server, Oracle und andere Mainframe-DB-Systeme zugreifen zu können (Über ODBC-API). Durch die spezifische Verwendung von "Stored Procedures" wurde es schnell populär.

ODBCDirect wurde für die MS-Office-Anwendungen klassischer Art entworfen, es konnte mit dem SQL-Server und ODBC-Datenquellen kommunizieren. Trotzdem zögerten einige Kunden, RDO anzuwenden, für diese speziell ist ODBCDirect gedacht und als schlanker Zusatz zu RDO.

Es hängt vom Konstruktionszweck der beiden Modelle, sowie von den verschiedenen Zugriffsarten der Datenbanken ab, Stored Procedures, ISAM und der Heranziehung von Tabellen oder Ergebnis-Sets.

Mit der Jet-Engine können Stored Procedures nicht gut gehandhabt werden, hierfür haben wir RDO.

Im Endeffekt waren da all die verschiedenen Modelle und wir hatten bestimmt nicht vor, unsere Kunden mit einer neuen Variante restlos zu verwirren.

Jetzt, da ADO (s.o.) da ist, haben wir endlich auch eine Möglichkeit, sowohl auf verschiedenste Datenbanken, wie auch auf Texte, Mails und Excel-Sheets zuzugreifen, da es nicht an Tabellen oder Stored Procedures gebunden ist, sondern nur an Daten-Ergebnis-Sets.

Mit Visual Basic kann man keine OLE-Datenbank direkt programmtechnisch ansprechen, mit dem ODBC-API aber schon, daher stellt ADO die Programmierschnittstelle zur OLE-DB dar. Für den Entwickler hängt der Einsatz des APIs oder ADO davon ab, ob ein Systemtool (Service) geschrieben werden soll, oder Datenergebnisse gebraucht werden. Heute ist ADO 1.5 ein Subset von RDO.

Für ADO 1.5 ist das richtig, da kann RDO manchmal mehr, aber mit ADO 2.0 wird man mehr Möglichkeiten als mit RDO haben.

Da es für ein Neuprojekt besser ist, mit ADO zu arbeiten, empfehle ich den RDO/DAO-Einsatz nur, wenn sonst große Umentwicklungsarbeiten notwendig werden. Den Einsatz des ODBC-APIs empfehle ich grundsätzlich nicht, da wir bereits mit ADO 1.4 und ADO 1.5 ausreichend Möglichkeiten haben.

Wir ziehen, da die OLE-Datenbank derzeit sehr solide aussieht, dieses Modell den ODBC-Treibern auf jeden Fall vor, das ist die Microsoft-Strategie. Wir werden hier die Entwicklung vorantreiben, da wir hier die größten Möglichkeiten im Bezug auf Vielfalt sehen.

Das ist eine Langzeitstrategie, aber noch in Vorbereitung.

Nichts ändern, was funktioniert ! Mit dem Einsatz von Web-Servern ensteht die Notwendigkeit, Daten auch auf diesen Servern zu manipulieren. dies wollen wir, z.B.: mittels HTML, über ADO erreichen. Dabei kann mit ADO auch Offline gearbeitet werden und, bei Neukontakt mit diesem Server, dann der Update gemacht werden.

Da ADO sehr flexibel ist, wurde es natürlich auch für die neueren Technologien entworfen, zum Beispiel für VBScript.

Man kann zwar ADO in einer Transaktion benutzen, es macht aber bei Offline-Arbeiten keinen Sinn. Es hängt also vom Grad der Online-Arbeiten ab.

Für die Entwickler: Der SQL-Server 7 wird genauso programmiert wie die Version 6, er ist aber flexibler. Wahrscheinlich wird der SQL-Server Bestandteil von Windows 95 und 98. Wollen Sie eine Anwendung für den Notebook schreiben die mit irgendeinem Server arbeiten soll ?

Wie Sie das erreichen können, ändert sich mit dem neuen Datenmodell:

Sie schreiben die Anwendung einmal, lassen den SQL-Server synchronisieren und replizieren, und das automatisch, ohne daß Sie die verschiedenen Gegebenheiten der einzelnen Datenbanken, oder deren Standort beachten müssen.

Wir können derzeit noch nicht darüber reden, was mit Access passieren wird. Access wird weiterbestehen, aber wir denken im Moment nicht über diese Entwicklung nach.