ODBC

[bigpoint]

Welche Verbindung zum SQL Server 2000 mit visual c++ (MFC ) sollte man benutzen ?
Ich kenne nur ODBC und ADO aber welche besser ist dh. schneller und sicher habe keine Ahnung.

[Andreas Kosch]

Hallo,

da Microsoft angekündigt hat (siehe MDAC Roadmap), dass ODBC bei zukünftigen Windows-Versionen entsorgt wird, ist ADO als Zugriffsschicht auf die <i>OLE DB Provider</i> der zukunftssichere und für den Entwickler vor allem auch der effektivere Weg. Außerdem stellt Microsoft mit <i>ADO.NET</i> auch einen Migrationsweg in die .NET-Welt zur Verfügung

[bigpoint]

Hallo,
welche Versionen meinst Du denn ?
Also ich benutze 2000/XP und da ist ODBC als Standar

[Andreas Kosch]

Hallo,

die von Microsoft bereitgestellte <i>MDAC Roadmap</i> soll uns mit Informationen versorgen, wie es in den nächsten Jahren weitergeht. Bei der Umstellung auf 64 Bit werden ganze Teile des alten APIs wegfallen, unter anderem auch die ODBC-Unterstützung

[bigpoint]

Danke für Antwort ;-)
Jetzt ist aber so:
ist es wirklich kompliziert und umständlich wenn die Umstellung auf 64 Bit passiert das ganze von ODBC auf ADO umzustellen ?? Ich habe nämlich gehört ( keine Ahnung ob es stimmt ), dass ODBC viel schneller sein sollte als ADO und das ADO grundsätzlich für Access gedacht ist

[Andreas Kosch]

Hallo,

&gt;..das ganze von ODBC auf ADO umzustellen ..

zu diesem Zeitpunkt wird auch ADO bereits von ADO.NET ersetzt - wobei ADO.NET auch problemlos "alte" ADO-Objekte einbinden kann. Wenn man jetzt allerdings bereits mit ADO beginnt, wird später der Migrationsaufwand zu ADO.NET deutlich niedriger.

&gt;..das ADO grundsätzlich für Access gedacht ist ..

ADO ist der objektorientiere Überbau für OLE DB und kann somit auf alle Datenbanken zugreifen, für die es einen OLE DB Provider gibt. Im Fall von einer ACCESS-Datenbank nutzt ADO die <i>Microsoft JET Engine</i>, aber für den Zugriff auf den MS SQL Server den <i>OLE DB Provider for SQL Server</i> - um nur einmal 2 Beispiele zu nennen.

&gt;..dass ODBC viel schneller sein sollte als ADO ...

Das kommt auf die Konfiguration an. Wenn man nur mit dem Recordset-Objekt arbeitet und dort keine Standardeinstellung ändert, mag das stimmen. Bei der Kombination von Connection-, Command- und Recordset-Objekt mit handoptierten Einstellungen haben meine Performance-Testprogramme keine nennenswerten Unterschied festgestellt. Erst mit ADO.NET und den neuen .NET-Providers wird ODBC locker abgehängt, so dass die Performance kein Grund für eine Entscheidung gegen ADO ist.

P.S: OLE DB- und ADO-Objekte sind In-Process-Server (COM), die im gleichen Adressraum des Aufrufers liegen. Im Fall der frühen Bindung (Dual Interface) greift der Client über Zeiger zu, so dass die mehrfache Zeigerverkettung (Client -> ADO -> OLE DB) bei den Heute üblichen CPUs keine messbare Zeitverschlechterung mit sich bringt