ADO-Problematik
Leserbewertung(3):bewerten...
kommentieren...
Hans Brender

Für alle, die bisher mit Microsoft Access über die DAO zugegriffen haben (Jet-Problematik) und die sich jetzt mit ADO beschäftigen, zeigen wir hier einige Tipps, wie sie Hürden und Klippen in ADO umgehen können. Original-Microsoft Links mit nützlichen (englischen) MDAC-Artikeln:
  • Q232053 INFO: List of Files Installed by MDAC 2.1 (GA)
  • Q238239 INFO: List of Files Installed by MDAC 2.1 SP 2
  • Q174191 SAMPLE: ODBC 3.0 Installation
  • Q175018 HOWTO: Acquire and Install the Microsoft Oracle ODBC Driver
  • Q170769 PRB: ODBC Resource DLL Is a Different Version Than ...Error
  • Q177913 HOWTO: Use the MDAC Standalone Setup EXE in Unattended Mode
  • Q216149 How to Install ODBC or MDAC on Terminal Server
  • Q191094 PRB: MDAC 2.0 Requires DCOM95 to Install Under Windows 95
  • Q190463 INFO: What are MDAC, DA SDK, ODBC, OLE DB, ADO, RDS, and ADO/MD?
  • Q190475 INFO: Understanding Microsoft's Oracle ODBC Driver Versions
  • Q190773 INFO: ODBC/OLE DB/ADO/RDS Are Inter-Dependent for MDAC 2.0
Die nachfolgenden Artikel sind auch korrekt für spätere MDAC - Versionen, dies bedeutet, dass Installation und Distribution individueller MDAC - Komponenten weder vorgesehen noch unterstützt werden !!
  • Q191704 PRB: Unable to Load File to Register It During Setup -- msdadc.dll
  • Q185622 HOWTO: Add the MDAC Redistribution Setup to CAB Files
  • Q232525 FP2000: After installing MS PWS 4.0, MDAC is Downgraded
  • Q218184 PRB: Restart After MDAC Installation Causes Error

ADO 2.0 und 2.1

Was ist die zur Zeit gültige Version von ADO (MDAC) ? 2.0 , 2.1 oder 2.5 ?

Microsoft warnt eindeutig, die Version 2.1 außerhalb von Testumgebungen einzusetzten, ohne dass das Servicepack MDAC 2.1 SP1 herausgebracht wurde. Es kann zu Instabilitäten kommen. Hintergrund ist der, dass ADO 2.1 im ServicePack 5 des SQL-Servers 6.5 bzw. mit dem neuen SQL-Server 7.0 ausgeliefert wird. Dabei wird auch der neue OLEDB Provider für Jet ( Version #4.00.2115.25 ) installiert. Wird dieser Treiber von außen (z.B. VB/VC) angesprochen, kann es zu Problemen kommen. (siehe Microsoft)

Welche MDAC Version ist auf meinem Rechner installiert ?

Die Antwort finden Sie in den Dateien Msdadc.dll und Oledb32.dll. Besser ist jedoch genaue Analyse durch den Microsoft MDAC Componenten Checker

MDAC version Msdadc.dll Oledb32.dll Notes
MDAC 1.5c 1.50.3506.0 N/A  
MDAC 2.0 2.0.3002.4 2.0.1706.0  
MDAC 2.0 SP1 2.0.3002.23 2.0.1706.0  
MDAC 2.0 SP2 2.0.3002.23 2.0.1706.0 Superset: SP1
MDAC 2.1.0.3513.2 (SQL) 2.10.3513.0 2.10.3513.0  
MDAC 2.1.1.3711.6 (Internet Explorer 5) 2.10.3711.2 2.10.3711.2  
MDAC 2.1.1.3711.11 (GA) 2.10.3711.2 2.10.3711.9  
MDAC 2.1.2.4202.3 (GA) SP2      
MDAC 2.7 SP1 (WinXP) 2.71.9030.0 2.71.9031.4

Seit dem 1.7.99 verfügbar: MDAC 2.1.2.4202.3 (GA): Microsoft ADO 2.1
Seit April 2000 auch für MDAC 2.5 RTM geeignet

Microsoft MDAC Component Checker

Die Problematik der installierten MDAC - Version hat sich noch nicht entspannt. Allerdings hat Microsoft mit dem MDAC Component Checker ein Tool zum Download zur Verfügung gestellt, welches
  • die installierte MDAC -Installation auf einem PC identifiziert
  • eine Serie von Reports generiert, die alle benötigten Dateien identifiziert und lokalisiert
  • DLL- Konflikte aufzeigt und die bestehende MDAC Installation auf Wunsch entfernt
Die Download - Größe des gepackten Component-Checkers beträgt 573 KB

Welche Versionen gibt es und woher stammen sie ?

1.5 (IE4.0) = 1.5 (IE4.0)
1.5 PDC97 = 1.5 PDC97
1.5a SDK = 1.5a
1.5b OCM setup = 1.5b
1.5c SDK = 1.5c
1.5d (IE4.0 SP1) = 1.5d (IE4.0 SP1)
2.0.3002.20 (GA) = 2.0
2.0.3002.23 (NT4 SP4) (OLAP) = 2.0 SP1 (OLAP)
2.0.3002.23 (NT4 SP4) = 2.0 SP1
2.0.3002.28 (GA) = 2.0 SP2
2.1 SP2 (2.1.2.4202.3) GA = 2.1 SP2 (2.1.2.4202.3) GA
2.1.3513.2 (SQL) = 2.1 RTM
2.1.3711.11(GA) = 2.1 GA
2.1.3711.6 = 2.1 SP1
2.50.3719.14 (Win2K Beta3) = NT4.0 - 2.50.3719.14
2.5 (4403.3) = 2.5 (4403.3)
2.5 Release (2.50.4403.12) = 2.5 RTM (2.50.4403.12)
im Beta-Test: 2.6



ADO-ODBC

Gegeben sei ein Query, welches über 2 Tabellen eine SQL Abfrage definiert, wobei in beiden Tabellen eine Spalte den gleichen Feldnamen hat:

Adresse Kommunikation  
ID ID <-- beide Tabellen haben ein Feld mit gleichem Namen
Name Telefon  
Vorname Fax  

Die SQL-Syntax sieht unter Access wie folgt aus:

SELECT Adresse.ID, Adresse.Name, Kommunikation.ID, Kommunikation.Telefon
FROM Adresse, Kommunikation;

Access SQL ist in der Lage und stellt bei Gleichheit zweier Feldnamen durch Voranstellen des Tabellennamens eine Eindeutigkeit her.

Wenn Sie dieses Query in Access abspeichern und über ADO-ODBC auf dieses Query zugreifen, und in Ihrem Recordset danach auf den Feldnamen zugreifen, werden Sie feststellen, dass der Tabellenname verlorengeht.

RS![Adresse.Id] <-- ergibt einen Fehler

Abhilfe:

Umgestalten des gespeicherten Querys oder Zugriff nicht über Feldnamen sondern Feldnummer.

ADO-Access native

Wer seine Querys in Access gespeichert hat, und auf diese nur noch mit dem Namen zugreift hat bei der Umstellung auf ADO Version 2.0 ein Problem.

Es ist nämlich mittels des Jetproviders 3.5x nicht möglich, auf gespeicherte Aktions-Abfragen zuzugreifen. Dies beinhaltet alle Delete, Update oder Insert Abfragen.

Aufgrund der unterschiedlichen SQL-Syntax und den damit verbundenen Problemen hat Microsoft den Zugriff aus dem Nativen Treiber immer noch gesperrt.

Workaround:
  • Über ADO-Schemata das Query auslesen, und als SQL-String übergeben. Dabei müssen Sie jedoch Performance-Einbußen hinnehmen und eine Methode zum Lesen des SQL-Schemas programmieren.In späteren funktionierenden Versionen können Sie dann den Zugriff auf das SQL-Schema unterbinden
Abhilfe:
  • den Zugriff auf Access von nativem Treiber auf Zugriff über ODBC umstellen

ADO-ODBC-Access

Wer über parametrisierte Abfragen via DAO auf die Access-Datenbank zugreift, hat in der Vergangenheit (Access 2.0) schon erste Probleme erfahren. Damals wurde nämlich mit dem Update auf Version 2.5 kein explizites Casting mehr durch die Jet-Engine durchgeführt, dies musste der Programmierer selbst erledigen. Urplötzlich verhielt sich die Applikation ohne jede Source-Code Änderung ganz anders.

Wer seine Applikation im Hinblick auf Upsizing zu einer "höheren" Datenbank (SQL-Server, Oracle, etc.) auf die neue, von Microsoft propagierte Zugriffsmethode ADO umstellen will, hat erneut mit den Tücken zu kämpfen. Zum einen sind parametrisierte, in Acess97 hinterlegte Abfragen über den nativen OLEDB-Treiber in der ADO-Version 2.0 schlichtweg nicht möglich. Zwar lassen sich normale Parameterabfagen erledigen, aber bei Update- oder Delete-Abfagen versagt der native Treiber schlichtweg seinen Dienst (siehe ADO-Access-nativ). Bleibt nur noch der Zugriff auf Access97 über ADO und ODBC.

Während mit der DAO die Reihenfolge der Parameter, wenn Sie mit dem Namen übergeben wurde, unerheblich war, die Jet-Engine erledigte dies, ist dies beim ODBC-Treiber leider nicht so. Die benannten Parameter müssen in genau der Reihenfolge übergeben werden, wie sie in Access als Parameter hinterlegt worden sind.

gespeicherte Abfrage in Access SQL:

PARAMETERS KOPF Long, SERPOS Text;
SELECT SerienPosition.Id ...

Die Reihenfolge der benannten Parameter muss zuerst KOPF und dann SERPOS lauten.