Discussion :

[mikedavem]

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]

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]

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]

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

++

[StringBuilder]

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]

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.