Microsoft abandonne OLE DB dans SQL Server, Denali sera la dernière version du SGBD à soutenir l'API d'accès aux données

Le 05/09/2011, par Hinault Romaric, Chroniqueur Actualités

Microsoft abandonne progressivement son interface de bas niveau pour l’accès aux données OLE DB (Object Linking and Embedding, Database) pour ODBC.

L’API Microsoft OLE DB avait été développée pour permettre l’accès à différentes sources de données, incluant celles n’utilisant pas un processeur de requête SQL. La technologie avait été conçue dans le but de remplacer ODBC (Open Database Connectity).

Cependant, ODBC c’est imposé au fil du temps comme le standard de facto utilisé actuellement dans l’industrie pour l’accès et la manipulation des données relationnelles au détriment d’OLE DB.

Dans son souci d’assurer l’interopérabilité entre ses produits et ses partenaires, Microsoft annonce donc la fin du support de la technologie OLE DB au sein de son moteur de base de données SQL Server en faveur d’ODBC.

La prochaine version du SGBD SQL Server, Denali (actuellement disponible en version CTP), sera donc la dernière à supporter l’API. OLE DB sera encore pris en charge 7 ans après la publication de la version finale de Denali.

Microsoft encourage les développeurs à utiliser dorénavant ODBC dans leurs projets futurs.

Cette orientation vers ODBC offrira également une plus grande clarté aux développeurs C/C++ qui pourront désormais concentrer leurs efforts uniquement sur une seule API.

La plate forme Cloud de Microsoft, SQL Azure, a déjà intégré ce virage vers ODBC.

Une décision qui suscite néanmoins plusieurs interrogations auprès des développeurs, car Microsoft avait présenté OLE DB comme un outil plus puissant qu’ODBC. De plus, OLE DB propose certaines fonctionnalités (qui ont été utilisées par des développeurs) et qui ne sont pas disponibles avec ODBC.

Il est vrai que ces développeurs auront encore quelques années pour négocier cette transition.

Et vous ?

Que pensez-vous de ce choix de Microsoft ?

Source : Blog SQL Server

Les rubriques (actu, forums, tutos) de Développez :

Accueil

SGBD & SQL

SQL-Server

Les derniers commentaires postés :

Retrouver la discussion sur le forum

Franck SORIANO
Responsable Delphi
le 22/09/2011

Citation:

Envoyé par Glouferu

Je trouve aussi qu'ils se foutent bien de notre gueule ... Apparemment la politique de Microsoft aujourd'hui est d'annoncé les futurs changement. Si il y a trop de mécontent, op ils annulent leur propal.

La suite donc au prochain épisode !

Ce n'est pas du foutage de gueule. Ca s'appelle au choix : Ecouter ses clients/utilisateurs, ou ceder à la pression de ses clients/utilisateurs

Citation:

salut je ne maitrise pas l'API ODBC à 100% mais ODBC c'est très basique pour la simple raison que c'est supposé supporter n'importe quel SGBD.
Donc cette méthode ne fonctionnera pas avec ODBC tu n'as pas d'équivalent.

Je ne retrouve plus le lien. Mais dans un doc où Microsoft comparait OLE-DB et ODBC suite à l'annonce, ils disaient que ODBC possédait également une API pour faire du bulk copy.
De toute façon je ne vois pas comment Microsoft pourrait penser sortir une nouvelle version de SQL sans qu'on dispose d'une API pour le bulk copy natif en mémoire. SSIS ne pourait plus fonctionner...

Mat.M
Expert Confirmé Sénior
le 23/09/2011

Huuumm ça ne serait pas cette fonction

http://msdn.microsoft.com/en-us/libr...=VS.85%29.aspx

Citation:

SQLBulkOperations Function
Conformance
Version Introduced: ODBC 3.0 Standards Compliance: ODBC
Summary
SQLBulkOperations performs bulk insertions and bulk bookmark operations, including update, delete, and fetch by bookmark.

Syntax
other

SQLRETURN SQLBulkOperations(
SQLHSTMT StatementHandle,
SQLUSMALLINT Operation);

Le MSDN ça sert à quelque chose

Donc j'ai écris des aneries mea culpa

mikedavem
Responsable SQL Server
le 23/09/2011

Citation:

je pense aussi beaucoup aux packages SSIS.
Dans la plupart, les connections vers les bases SQL étaient recommandées avec le connecteur OLEDB.

Effectivement mais personnellement en fonction de la cible (ou source) d'ailleurs j'ai toujours préféré utiliser ODBC (comme par exemple avec les drivers Iseries de l'AS400 qui m'ont toujours fourni plus de performance que les drivers OLEDB).

Citation:

J'entends par là que SQL Server 2008 prend en charge les DTS 2000 ce qui n'était plus le cas sous SQL Server 2005. Mais bon la prise en charge est limitée ! Le but est un retour en arrière avant de repartir de l'avant. Forcément on ne va pas relancer la folie des DTS.

Les lots DTS sont prises en charge dans la version 2005 et 2008.

Citation:

C'est un choix de Microsoft d'abandonner OLEDB pour des raisons qui me semblent valables :

- ODBC est aujourd'hui le standard alors que OLEDB non
- On peut trouver ODBC sur toutes les plateformes alors que OLEDB non
- Cela permettra aux équipes de Microsoft de se concentrer sur la technologie ODBC.
- Je vois ici beaucoup de posts où OLEDB est plus performant que ODBC mais personnellement je n'ai jamais constaté cela et j'ai vu parfois le contraire ..

++

Jinroh77
Membre Expert
le 23/09/2011

Je ne suis pas particulièrement pour ou contre cette disparition, à la rigueur, tant mieux d'aller vers les standards. Par contre, dans mes souvenirs, sur SSIS Microsoft recommandait plus que chaudement l'utilisation des composant OLE plutôt que ODBC ou même ADO.

mikedavem
Responsable SQL Server
le 23/09/2011

Effectivement mais encore une fois je parle pour moi ici avec une source de type AS400 j'ai toujours eu à utilisé une connexion de type ODBC si je voulais que les performances soient au rendez vous et ceci même avec SSIS

StringBuilder
Membre Expert
le 23/09/2011

Citation:

Envoyé par iberserk

A stringBuilder:

Il y a ADO.NET qui est sorti ensuite(7 ans au bas mots...)
Pas sur que ca :
http://msdn.microsoft.com/fr-fr/libr...(v=vs.80).aspx
fonctionne avec une chaîne de connexion ODBC...

ADO.NET fonctionne avec un connecteur natif à la base, donc c'est ni ODBC, ni OLEDB. Donc tout ce qui est xxx.NET, il n'y aura aucun changement.

Sinon, avec .NET, il reste la possibilité de passer par les connecteurs ADO classiques, qui sont compatibles ODBC, au cas où le SGBD ne dispose pas d'un connecteur ADO.NET

Pour les vieux programmes (Visual Studio 6 et antérieurs), le passage de OLEDB à ODBC doit se faire de façon "totalement" transparente si on utilise ADO (MDAC) pour se connecter. Attention cependant aux drivers ODBC, souvent très buggés (ceux d'Oracle par exemple étaient une horreur, il fallait prendre ceux écrits par Microsoft et serrer les fesses très fort qu'on n'aie jamais besoin d'utiliser de BLOB par exemple);

Franck SORIANO
Responsable Delphi
le 25/09/2011

Citation:

Envoyé par StringBuilder

Sinon, avec .NET, il reste la possibilité de passer par les connecteurs ADO classiques, qui sont compatibles ODBC, au cas où le SGBD ne dispose pas d'un connecteur ADO.NET

Attention, Microsoft a dit qu'ils arrêtaient le provider OLEDB de SQL Server, ils n'ont pas dit qu'ils arrêtaient OLEDB !

De plus, ce n'est pas ADO qui est compatible ODBC. ADO ne fonctionne qu'avec OLEDB. C'est une surcouche sur OLEDB pour en facilité l'usage.
Par contre il existe un provider OLEDB qui fait la passerelle sur ODBC, ce qui permet d'utiliser ADO avec un driver ODBC, en accumulant les couches d'adaptations...

mikedavem
Responsable SQL Server
le 25/09/2011

Effectivement Frank tu as raison, ceci concerne uniquemnt SQL Server.

Citation:

Par contre il existe un provider OLEDB qui fait la passerelle sur ODBC, ce qui permet d'utiliser ADO avec un driver ODBC, en accumulant les couches d'adaptations...

Je pense notamment que tu penses à MSDASQL (Microsoft OLEDB for ODBC).

On a le schéma suivant :

Citation:

System.Data.OleDbClient -> OLE32.DLL -> MSDASQL Provider -> ODBC32.DLL -> Driver -> Data Source

StringBuilder
Membre Expert
le 26/09/2011

Non, moi je parle de ce genre de chaines de connexions, utilisées par MDAC (qui a été renommé ADO, pour je ne sais quelle raison) :

http://www.connectionstrings.com/ibm-db2

On voit bien qu'on peut utiliser directement un drivers ODBC, avec ou sans DSN. Pour moi, il n'y a pas de surcouche OLEDB entre le drivers ODBC et MDAC.

Franck SORIANO
Responsable Delphi
le 26/09/2011

Désolé, je ne vois pas de quoi tu parles !
Dans la référence que tu cites :
- La première chaines de connexion utilse le connecteur .Net Db2.
- La deuxième utilise le provider OLEDB de Microsoft pour DB2.
- La troisième utilise le provider OLEDB d'IBM pour DB2.
- La quatrième utilise le connecteur OLEDB de .Net.
- La cinquième est de l'ODBC direct. Mais il ne s'agit pas d'ADO pour autant.
- La dernière est le connecteur OBDC de .Net

Je vois nulle part de l'ADO faisant de l'ODBC...

Citation:

utilisées par MDAC (qui a été renommé ADO, pour je ne sais quelle raison)

Non, tu mélanges plusieurs choses :
- ADO (Microsoft ActiveX Data Object) est une technologie permettant d'accéder à une source de données OLEDB. C'est une librairie d'objets COM dont le but est de simplifier l'utilisation de OLEDB.
- MDAC (Microsoft Data Access Components) : C'est un package de déploiement qui contient un certain nombre de drivers et technologies pour se connecter à quelques grands SGBD. MDAC contient ADO, les providers OLEDB Microsoft pour SQL Server, Oracle, Access et la passerelle ODBC. Il contient également les drivers ODBC Microsoft pour les mêmes SGBD.

Donc oui, tu peux te connecter en ODBC directement à certain SGBDs en installant MDAC, mais ce n'est pas de l'ADO pour autant.

Retrouvez la suite de la discussion

Microsoft abandonne OLE DB dans SQL Server, Denali sera la dernière version du SGBD à soutenir l'API d'accès aux données

Best Of

Actualités les plus lues

Ressources

Forums

Communauté

FAQs (1825 réponses)

Contact