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 , par Hinault Romaric, Responsable .NET
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Mat.M Mat.M - Expert éminent sénior https://www.developpez.com
le 22/09/2011 à 18:27
Citation Envoyé par Glouferu  Voir le message
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 !

ça on est d'accord
C'est comme avec VB6: je viens de quitter une entreprise le logiciel principal a été développé sous VB6 pendant des années maintenant il est quasimment stable et arrivé à maturité.
Et il faut quasiment tout jeter et passer à .NET
Avatar de Franck SORIANO Franck SORIANO - Membre expert https://www.developpez.com
le 22/09/2011 à 21:04
Citation Envoyé par Glouferu  Voir le message
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

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...
Avatar de Mat.M Mat.M - Expert éminent sénior https://www.developpez.com
le 23/09/2011 à 0:56
Huuumm ça ne serait pas cette fonction

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

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
Avatar de mikedavem mikedavem - Expert éminent sénior https://www.developpez.com
le 23/09/2011 à 7:08
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).

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.

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.

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 ..

++
Avatar de Jinroh77 Jinroh77 - Membre chevronné https://www.developpez.com
le 23/09/2011 à 9:49
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.
Avatar de mikedavem mikedavem - Expert éminent sénior https://www.developpez.com
le 23/09/2011 à 10:57
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

++
Avatar de StringBuilder StringBuilder - Expert confirmé https://www.developpez.com
le 23/09/2011 à 11:11
Citation Envoyé par iberserk  Voir le message
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);
Avatar de Franck SORIANO Franck SORIANO - Membre expert https://www.developpez.com
le 25/09/2011 à 19:08
Citation Envoyé par StringBuilder  Voir le message
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...
Avatar de mikedavem mikedavem - Expert éminent sénior https://www.developpez.com
le 25/09/2011 à 19:44
Effectivement Frank tu as raison, ceci concerne uniquemnt SQL Server.

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 :

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

++
Avatar de StringBuilder StringBuilder - Expert confirmé https://www.developpez.com
le 26/09/2011 à 11:35
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.
Avatar de Franck SORIANO Franck SORIANO - Membre expert https://www.developpez.com
le 26/09/2011 à 21:00
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...

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.
Offres d'emploi IT
Architecte et intégrateur scade/simulink H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Ingénieur conception en électronique de puissance H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Architecte sécurité des systèmes d'information embarqués H/F
Safran - Ile de France - 100 rue de Paris 91300 MASSY

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil