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 :)
++
Version imprimable
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 :)
++
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.Citation:
Envoyé par iberserk
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);
Attention, Microsoft a dit qu'ils arrêtaient le provider OLEDB de SQL Server, ils n'ont pas dit qu'ils arrêtaient OLEDB !Citation:
Envoyé par StringBuilder
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...
Effectivement Frank tu as raison, ceci concerne uniquemnt SQL Server.
Je pense notamment que tu penses à MSDASQL (Microsoft OLEDB for ODBC).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...
On a le schéma suivant :
++Citation:
System.Data.OleDbClient -> OLE32.DLL -> MSDASQL Provider -> ODBC32.DLL -> Driver -> Data Source
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.
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...
Non, tu mélanges plusieurs choses :Citation:
utilisées par MDAC (qui a été renommé ADO, pour je ne sais quelle raison)
- 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.