Discussion :

[Hinault Romaric]

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


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

[_skip]

Que pensez-vous de ce choix de Microsoft ?

Je vais peut être passer pour un troll (j'espère pas), mais il me semble que très peu de SGBD non microsoft proposaient une couche OLEdb réellement efficace et aboutie. Je pense que personne depuis plusieurs années n'a commencé un développement en se basant sur de l'OLEdb, sauf peut être les utilisateurs de certains RAD comme windev qui profitaient des fonctionnalités supplémentaires par rapport à ODBC (récupération de metadata notamment).

[CAML]

via le .net Microsoft recommandait de passer par l'OLEDB et maintenant il l'abandonne. Faudrait savoir quoi

[_skip]

via le .net Microsoft recommandait de passer par l'OLEDB et maintenant il l'abandonne. Faudrait savoir quoi

Ado.net plutôt non?

[Freem]

OLE DB (parfois orthographié OLEDB ou OLE-DB) est une API développée par Microsoft permettant l'accès aux données.

OLE DB se sert d'interfaces COM (Component Object Model)1. Il a été conçu dans le but de remplacer ODBC, de ce fait il permet l'accès à des bases de données exotiques ou des sources de données qui n'utilisent pas un processeur de requêtes SQL.

OLE DB fait partie du framework MDAC.

Il faut dire que je n'entend parler que rarement de SGBDR n'utilisant le SQL, et que ODBC est plutôt très populaire, dans le genre.
Je doute que l'usage d'OLE DB soit très répandu, et je pense que ms l'a compris, et que c'est pour ça qu'ils lâchent l'affaire.

Sinon, c'est quoi la différence entre ODBC et OLE-DB?
Meilleure performance? Ca ne me semble pas a l'ordre du jour...
Plus simple à utiliser? Plus bas niveau, donc j'en doute, et l'époque est moins à l'optimisation du code que celle du temp.
Plus aisément portable? J'en doute.
Alors pourquoi utiliser cette techno?

PS: ce sont de vraies questions, donc si on me met un down, je veux bien qu'on m'explique pourquoi.

[Philippe Robert]

Etonnant !

J'ai toujours préféré utiliser OLEDB car plus performant qu'ODBC.
Qu'en est-il de SQL Native Client ?

[Franck SORIANO]

Il faut dire que je n'entend parler que rarement de SGBDR n'utilisant le SQL, et que ODBC est plutôt très populaire, dans le genre.
Je doute que l'usage d'OLE DB soit très répandu, et je pense que ms l'a compris, et que c'est pour ça qu'ils lâchent l'affaire.

Au contraire, OLEDB et sa surcouche ADO sont les standards pour accéder à un SGBD sous Windows depuis une bonne décennie...
La plupart des applications natives sous Windows utilisent ADO. Autrement dit OLEDB. Il ne faut pas oublier qu'ADO est une surcouche pour faciliter l'appel à OLEDB. Et très souvent pour se connecter à un SGBD en ODBC, on utilise ADO avec un provider OLEDB qui se greffe par dessus un driver ODBC...

OLEDB est assez lourd et complexe à utiliser, mais si on fait l'effort de s'y mettre, les performances sont vraiment excellentes !

Peu de développeur en on conscience mais aujourd'hui dans une appli BDD, la première source de ralentissement, se sont les performances de l'API d'accès au SGBD du côté client !
Sous SQL Server, le jour où j'ai remplacé la couche ADO de Delphi par ma propre implémentation utilisant directement OLEDB, j'ai multiplié par 4 la montée en charge de l'application... L'écart de performances d'une API à une autre est phénoménal !

Je pense que Microsoft doit justifier ce choix en se disant que maintenant les applis doivent passer sous .NET. Et qu'en .NET on utilise ADO.NET.
SQL Server disposant d'un provider .NET qui est à la fois triviale d'utilisation (comparé à OLEDB), tout en étant encore plus performant qu'OLEDB...

Par contre petite question. Comment on fait un IRowsetFastLoad avec ODBC ?

[Invité]

OLEDB avait évincé ODBC dans la logique d'accès aux données MS pour implémenter les objets activex et bypasser la couche des source de données paramétrées dans le panneau de configuration.
A l'époque , on y voyait une optimisation puisque les programmes fonctionnaient dés l'installation et il n'était pas nécessaire de passer en mode admin et paramétrer l'acces aux données sur chaque machine cliente.

Par contre les benchmarks que j'avais faits montraient une baisse de perf d'environ 20% pour oledb contrairement à un cliché de l'époque.

La migration entre ODBC et OLEDB correspondait exactement au passage de DAO à ADO lors de l'upgrade de VB5 à VB6 ou encore de Office 97 à office 2000 et supérieur.

Je vois un avantage à odbc , c'est la sécurité : la fait de stocker le mot de passe crypté sur la machine cliente permet de ne pas le stocker dans la chaine de connection compilée dans le programme client.

Ainsi le mot de passe est entré par l'administrateur une fois pour toutes au moment de la configuration de la machine. Il reste complètement inconnu de l'utilisateur. Priorité à la sécurité donc..

Par la suite en C#, ADO.net est venu avec un jeu de primitives et curseurs complètement différents sans qu'on puisse dire si cela favorisait l'un ou l'autre des drivers odbc ou oledb

Je crois que ces deux familles de drivers ont connu des évolutions drastiques depuis l'origine. Cela dit les développeurs VBA devraient être plus impactés que les autres.

[bigjim2]

20% de pertes avec OLEDB, je ne pense pas que MS aurait livré un produit dans cet état.

Cela paraît logique si on considère que même MS ne peut pas s'amuser à payer des gens pour maintenir une technologie pour le plaisir.

Cela peut aussi indiquer qu'à terme (d'ici 10 ans) Microsoft souhaite arrêter COM, ou faire reposer le moins de choses possible dessus.

Je vois un avantage à odbc , c'est la sécurité : la fait de stocker le mot de passe crypté sur la machine cliente permet de ne pas le stocker dans la chaine de connection compilée dans le programme client.

C'est un un point de vue un peu partiel :
1) On peut crypter la communication OLEDB.
2) On peut utiliser l'authentification Windows, c'est ce qui est d'ailleurs recommandé.
3) En cas de connexion avec utilisateur SQL, on peut (on doit!) crypter le mot de passe dans le fichier de configuration. .NET Framework propose des API pour ce faire, mais on peut en utiliser d'autres.
4) Stocker le mot de passe sur la machine cliente, en clair dans le registre, ce n'est pas forcément une bonne idée non plus.
5) Ce n'est pas très adapté à de gros parcs.

[fred85]

Dans notre société, nous utilisons OleDB dans des modules VBA, avec Delphi Win32 pour accéder à différentes bases dont SQL Server.
Cela va donc énormément nous géner.

De plus la plupart des états Crystal Reports utilisent OleDB (et pas uniquement chez nous). là les conséquences sont énormes !!!

Sinon, nous sentons fortement l'arrêt prochaine de toutes les technologies non .Net chez Microsoft. D'ici à ce que les applications Windows normales passent dans un sous système (style les applications 16 bits actuellement), il n'y a pas loin...

[didou6869]

J'ai du mal à comprendre cet abandon... Depuis fin 2001 et ma conversion à 95% au .NET (C# et VB.NET), j'ai, sauf obligation pour certaines bases exotiques, utilisé uniquement OLE DB ou Link !

Est-ce que Link est également concerné ?

[StringBuilder]

Depuis VB ou autres langages utilisant ADO pour se connecter aux bases de données (en gros, les objets Connection, Transaction, RecordSet et autres) il n'y a aucun changement : il suffit de modifier la chaîne de connexion pour utiliser le drivers ODBC à la place du drivers OLE DB.
=> Pas plus besoin de créer un DSN en ODBC qu'en OLE DB
=> Pour ainsi dire aucun changement au niveau des fonctionnalités (aux bugs près, genre le drivers ODBC d'Oracle fourni par Oracle... est à jeter aux orties !)

Mise à part pour ceux qui tapent en dur dans les librairies d'accès aux données (C/C++) tous les autres langages de haut niveau passent généralement par ADO, donc aucun impact dramatique !

[Franck SORIANO]

Je pense aussi que contrêtement, l'impact sera limité sur les applications existantes.
Il ne doit guère y avoir que les développeurs C/C++ qui appellent OLEDB directement. Et combien même, même en OLEDB directe il est possible d'utiliser le provider qui se connecte sur ODBC. D'ailleurs en ADO, c'est bien ce qui se passera.

Est-ce que Link est également concerné ?

A priori non.
Microsoft parle uniquement des applications Natives.
Les applications .Net possèdent un provider ADO.NET dédié pour SQL Server, totalement indépendant de OLEDB.
En .NET logiquement on n'est pas concerné (sauf à faire de l'ADO.NET par dessus OLEDB...).

[Ptit_Dje]

Ca risque d'impacter pas mal de packages SSIS par contre!

[Philippe Robert]

Ca risque d'impacter pas mal de packages SSIS par contre!

Si SSIS existe encore lorsque OLEDB sera abandonné. Comme ce fut le cas avec l'abandon de DTS, il faudra tout réécrire !

[kisitomomotene]

M$ et ces mil et une techno qu'il crée et qu'il abandonne (vb, asp, com qui ont été abandonnés..). Il donne l'impression de ne pas avoir de vision à long terme, et de faire du bricolage juste pour du fric

[Invité]

M$ et ces mil et une techno qu'il crée et qu'il abandonne (vb, asp, com qui ont été abandonnés..). Il donne l'impression de ne pas avoir de vision à long terme, et de faire du bricolage juste pour du fric

Merci pour cette subtile démonstration.

[camus3]

Merci pour cette subtile démonstration.

C'est quand même un peu vrai. Et de nombreux exemples sont la pour confirmer les faits. Je pense à Iron Python ou Iron Ruby (abandonné à "l'open source"), ou "javascript".NET , et maintenant ils veulent nous faire manger du HTML5 à toutes les sauces pour le développement Windows 8 et Windows phone... il n'y a pas de politique cohérente en terme de cycle de vie des produits MS. Je pense à aussi à Linq to SQL , qui même en étant basique était bien pratique et simple à mettre en oeuvre face à Entity.

[iberserk]

Je pense à aussi à Linq to SQL

Mais seulement compatible SQL SERVER, oseriez vous reprocher cette ouverture à MS?

Que trouvez vous de si compliqué dans LTE comparé à LTS?

[iberserk]

J'ai du mal à comprendre cet abandon... Depuis fin 2001 et ma conversion à 95% au .NET (C# et VB.NET), j'ai, sauf obligation pour certaines bases exotiques, utilisé uniquement OLE DB ou Link !

Est-ce que Link est également concerné ?

Link n'existe pas voulez vous parler de LINQ to SQL et LINQ TO ENTITIES?