Es ist erstaunlich von wie viel Technologie, sich Microsoft aktuell verabschiedet, oder Wege einschlägt, die manchen (zumindest mich) wirklich überraschen. Oder vielleicht überrascht es auch nicht, weil man gerade mit der Unberechenbarkeit der Branche rechnen muss!
OLE DB war vor Jahren die Technologie und jedem Entwickler wurde geraten von ODBC auf OLE DB umzusteigen, oder zumindest bei neuen Projekten OLE DB den Vorzug zu geben. Die höhere Performance und die größere Flexibilität haben bei weitem, die etwas komplexere Technik aufgewogen. Und Dank der guten ATL Client-Klassen war OLE DB auch zu handhaben.
Nun ist Schluß damit! Der nächste SQL-Server mit dem Codenamen Denali wird die letzte Version sein, die OLE DB unterstützen wird, so ist hier zu lesen:
http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx
Liest man die Kommentare aufmerksam, dann scheint es daran zu liegen, dass Microsoft Probleme hat, OLE DB in der Cloud vernünftig zum laufen zu bekommen. Microsoft macht es sich scheinbar einfach und schießt eine ganze Technologie ab, die mal als „die Technik“ eingeführt wurde.
D.h. eine langsamere Technik wird nun der Standard werden.
Für mich wieder mal eine Entscheidung, die sich mir in keiner Weise erklärt.
Ich verfolge die Diskussion um den MS-SQL Server nicht permanent und so ist mir dieser Artikel erst jetzt untergekommen.
Mehr Infos auch in diesem Thread, der eine kleine FAQ enthält:
http://social.technet.microsoft.com/Forums/en/sqldataaccess/thread/e696d0ac-f8e2-4b19-8a08-7a357d3d780f
Heftig finde ich die Antwort auf Frage 6, die einem auch kaum Hoffnung macht mit einem älteren Client evtl. noch auf den neuen Server zugreifen zu können:
Question6: If I have an OLE DB application that I write for Denali, will it be supported on a post Denali version of SQL Server that is released during the life of Denali?
Answer: No, in fact we may explicitly block the OLE DB applications on post-Denali versions of SQL Server. It is recommended that you plan your migration soon to ODBC, if you want to start using newer versions of SQL Server as soon as they release.
PS: Wie erkläre ich wohl meinen Kunden, die auf einmal 10%-30% langsamere Datenzugriffe haben werden, gerade wenn es größere Datenmengen geht ? Werden die mir glauben, wenn ich sage: Microsoft will es so? 🙁
fuer den Zugriff auf SQL Server – so wie Du es oben schreibst – empfiehlt es sich eh einen SQL Server Provider zu verwenden.
Hier sind .NET Applikationen gluecklicherweise vorerst auf der besseren Seite da dort SqlProvider unterstuetzt und auch fuer Post Denali SQL Server Versionen verfuegbar sein duerften.
Warum sollte man auf eine „rohes“ Interface ohne Klassen zurückgreifen?
Bisher war ODBC und OLE DB die erste Wahl der Schnittstelle… Ich wüsste kaum jemand, der das native SQL Interface benutzt, zudem es dazu meines Wissen keine unterstützenden Klassen in VS-C++ gibt.
Hi Martin,
ODBC gibt IMHO ordentlich Performance. Inner MFC gibts dafür ja CDatabase (jaja, weisst du ssicher schon) .. Ist natürlich kein natives SQL Interface, das stimmt schon.
Gruss