IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MS SQL Server Discussion :

Microsoft abandonne OLE DB dans SQL Server


Sujet :

MS SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Rédacteur
    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    Janvier 2007
    Messages
    4 570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2007
    Messages : 4 570
    Billets dans le blog
    121
    Par défaut Microsoft abandonne OLE DB dans SQL Server
    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
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  2. #2
    Membre éprouvé
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Par défaut
    Citation Envoyé par Hinault Romaric Voir le message
    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).

  3. #3
    Membre très actif
    Profil pro
    Inscrit en
    Février 2006
    Messages
    235
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Février 2006
    Messages : 235
    Par défaut
    via le .net Microsoft recommandait de passer par l'OLEDB et maintenant il l'abandonne. Faudrait savoir quoi

  4. #4
    Membre éprouvé
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    Novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 898
    Par défaut
    Citation Envoyé par CAML Voir le message
    via le .net Microsoft recommandait de passer par l'OLEDB et maintenant il l'abandonne. Faudrait savoir quoi
    Ado.net plutôt non?

  5. #5
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2008
    Messages
    836
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2008
    Messages : 836
    Par défaut
    Citation Envoyé par wikipedia
    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.

  6. #6
    Membre confirmé
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2008
    Messages : 240
    Par défaut
    Etonnant !

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

  7. #7
    Membre Expert

    Profil pro
    Leader Technique
    Inscrit en
    Juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 756
    Par défaut
    Citation Envoyé par Freem Voir le message
    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 ?

  8. #8
    Candidat au Club
    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    3
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 3
    Par défaut
    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.

  9. #9
    Futur Membre du Club
    Profil pro
    Inscrit en
    Octobre 2006
    Messages
    4
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2006
    Messages : 4
    Par défaut Il y a d'autres conséquences
    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...

  10. #10
    Membre à l'essai
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mars 2011
    Messages
    5
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 5
    Par défaut Un standard .NET !!
    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é ?

  11. #11
    Expert confirmé
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 197
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 197
    Billets dans le blog
    1
    Par défaut
    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 !

  12. #12
    Membre Expert

    Profil pro
    Leader Technique
    Inscrit en
    Juin 2005
    Messages
    1 756
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Leader Technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 756
    Par défaut
    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...).

  13. #13
    Membre Expert

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2007
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : Août 2007
    Messages : 1 216
    Par défaut
    Ca risque d'impacter pas mal de packages SSIS par contre!

  14. #14
    Membre confirmé
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    240
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Janvier 2008
    Messages : 240
    Par défaut
    Citation Envoyé par Ptit_Dje Voir le message
    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 !

  15. #15
    Membre très actif
    Inscrit en
    Août 2005
    Messages
    307
    Détails du profil
    Informations forums :
    Inscription : Août 2005
    Messages : 307
    Par défaut
    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

  16. #16
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par kisitomomotene Voir le message
    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.

  17. #17
    Membre très actif
    Profil pro
    Inscrit en
    Juillet 2010
    Messages
    657
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Juillet 2010
    Messages : 657
    Par défaut
    Citation Envoyé par 7gyY9w1ZY6ySRgPeaefZ Voir le message
    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.

  18. #18
    Membre Expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Par défaut
    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?

  19. #19
    Membre Expert Avatar de iberserk
    Homme Profil pro
    Architecte de base de données
    Inscrit en
    Novembre 2004
    Messages
    1 795
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Architecte de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2004
    Messages : 1 795
    Par défaut
    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?

  20. #20
    Membre averti
    Profil pro
    developpeur
    Inscrit en
    Novembre 2003
    Messages
    33
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : developpeur

    Informations forums :
    Inscription : Novembre 2003
    Messages : 33
    Par défaut
    Tout à fait d’accord avec kisitomomotene.

    Tout est fait par Microsoft pour engranger le maximum de pognon dans un minimum de temps, le reste n’est que littérature. En informatique c’est quasiment toujours la même chose donc pour montrer que cela évolue en permanence, ils créent des nouvelles technologies, nouveaux langages, nouveaux modes de distribution (par exemple location avec le cloud qui générera plus de pognon qu’une simple vente).
    Toutes ces nouveautés sortent le plus souvent buggées et ne sont pas débuggées complètement quand elles sont remplacées par d’autres. J’en ai connu des abandons par Microsoft. Ils se servent aussi des développeurs et des « meilleurs parmi eux » (les MVP, lol) pour accroitre leur notoriété afin de placer dans chaque PC leurs OS et la suite Office. C’est cela le monopole.

Discussions similaires

  1. Qualité et métrique dans SQL server
    Par Liloye dans le forum MS SQL Server
    Réponses: 5
    Dernier message: 14/03/2005, 08h35
  2. Importer des données dans sql server avec DELPHI ???
    Par moutanakid dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 11/08/2004, 17h22
  3. Copie de donnees dans SQL server 2000
    Par papayou42 dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 19/12/2003, 10h58
  4. Procedure stockée avec ntext dans SQL server 2000
    Par nagababa dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 20/11/2003, 20h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo