Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Accès aux données : ODBC (et par extension OLEDB aussi) et plateforme Windows 64 bits (x64 pour les intimes) et WoW

Celles et ceux ayant essayé une fois la connectivité ODBC en 64 bits (x64*) comprendront le véritable cauchemar de ces problématiques de drivers. Ces derniers ne sont pas réellement liés aux drivers eux même, mais à la couche de compatibilité mise en place sous Windows lors de la naissance de la première plateforme 64bits supportée par Windows.

Un peu d'histoire…

x64 signifie pour extented 64 bits, qui est en fait la technologie amd64 d'AMD et emt64 d'Intel. Elle ne doit pas se confondre avec ia64 qui est la plateforme Intel Itanium, abandonné pour les prochaines versions de Windows. Or c'est justement cette dernière qui fût la première à sortir des cartons et à devoir être supporté par Microsoft sous Windows.

La plateforme ia64 ne partageait que peu de points communs avec celle 32 bits des Pentium (x86), c'est la raison pour laquelle Microsoft a opté pour une séparation du 32 bits et du 64 bits. Les anciennes applications 32 bits fonctionnaient donc, mais dans une couche à part dénommée WoW (pour : Windows on Windows). Disons que pour simplifier, tout y est doublé, cette couche a donc sa base de registre, son système de fichier, son répertoire system32, etc. On a même une version d'IE en 64 bits et une en 32 bits, une version de CMD.EXE, etc.

La séparation se justifie parfaitement sur la plateforme ia64, comme le code 32bits x86 est en fait émulé par le processeur et code 64 bits ia64 bien plus performant dispose de son propre environnement d'exécution. Mais quand AMD a sorti sa plateforme AMD64, qui elle n'était que l'extension de la plateforme x86, 100% compatible avec l'existant et des performances conservées en 32 bits… Le choix a été fait de conserver ce « double » Windows ! Plus tard Intel a rejoint AMD en proposant l'EMT64 la plateforme en passant changea de nom, connue maintenant sous le sigle x64.

Et l'accès aux données ?

Sous les Windows de la famille 64 bits le système se décompose comme suit :

 

x86 (WoW)

x64

Base de registre HKLM\Software

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node

HKEY_LOCAL_MACHINE\SOFTWARE

Programmes

C:\Program Files (x86)

C:\Program Files

Système

C:\Windows\SysWOW64

C:\Windows\System32

Emplacement des drivers

C:\Program Files (x86)\Common Files\System

C:\Program Files\Common Files\System

 

Je mets Wow entre parenthèse dans le tableau… par la suite je considère implicitement que quand je parle de 32 bits je parle de WoW, donc de la couche 32 bits dans Windows x64 !

Les drivers ODBC et OLEDB étant référencés dans la base de registre et certaines de leur DLL étant dans l'espace système de Windows, il est assez logique de les voir dans le 2 déclinaisons que sont le 32 et le 64 bits.

Pour compliquer tout cela, lorsque l'on travaille sur un serveur de base de données (BI incluse) la quasi-totalité des services sont en 64 bits tandis que les outils de développement sont en 32 bits. Et la situation ne change pas avec Visual Studio 2010 qui reste en 32 bits. Donc Management Studio (SSMS) et BI Development Studio (BIDS) doivent utiliser les drivers 32 bits, tandis que le moteur relationnel, Analysis Services (SSAS), Reporting Services (SSRS) et Integration Services (SSIS) utilisent les drivers 64 bits.

Les drivers

Il résulte de cette schizophrénie de Windows, une conséquence simple : les drivers doivent être installés en double ! Et la configuration de ces derniers doit elle aussi se faire 2 fois.

Côté ODBC, historiquement la situation n'était pas vraiment reluisante, il n'existait pas de drivers x64 ODBC pour OLEDB. A moins que le service pour lequel vous développiez ne supporte nativement l'ODBC cela se compliquait un peu.

Sous Windows 2003 un patch a été fourni, livrant ce fameux driver ODBC pour OLEDB en 64 bits (ia64 et x64) :
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=000364db-5e8b-44a8-b9be-ca44d18b059b&displaylang=en

Depuis Vista et Windows Server 2008, ce driver est fourni par défaut. Seulement il ne permet que de se connecter à un driver existant ODBC en 32 ou 64 bits.

Que faire ? Eh bien ceci :

  • Chercher le driver 64 bits (x64) et 32 bits (x86) de votre source de données (valable pour ODBC ou OLEDB)

  • Attention les noms sont parfois trompeurs en fonction de l'éditeur. Chez Oracle on trouve le 32 bits sous le nom de win32 et le 64 bits sous le nom de x86_x64, on pourrait croire que le second contient les 2, il n'en est rien.
  • Installer le driver 64 bits
  • Installer le driver 32 bits (vérifiez bien que vous n'écrasez pas l'installation précédente)
  • Configurer la connexion aux données en 64 bits :
    • Pour l'ODBC : C:\Windows\system32\odbcad32.exe
  • Configurer la connexion en 32 bits :
    • Pour l'ODBC : C:\Windows\SysWOW64\odbcad32.exe
  • Testez !!!

Pour plus de facilité (votre chaine de connexion ne changeant pas entre développement et production généralement) utilisez le même nom de DSN avec ODBC !

En fonction de la procédure d'installation du driver, 2 astuces qui pourraient vous sauvez la vie…

  • CMD existe lui aussi en 2 version, utile à savoir pour créer les variables d'environnement avec la commande SET en 32 et 64 bits
    • 32 bits : C:\Windows\SysWOW64\CMD.exe
    • 64 bits : C:\Windows\system32\CMD.exe
  • Pour tester, créez simplement un fichier texte sur le bureau. Changez son extension en .UDL et double cliquez pour éditer… Vous avez là un mini éditeur de chaîne de connexion OLEDB… 32 bits.

Pour vérifier que le driver est bien installé, vous pouvez aussi aller directement dans les répertoires où les DLL sont déployées :

  • ODBC
    • 32 bits
      • C:\Windows\SysWOW64
    • 64 bits
      • C:\Windows\System32
  • OLEDB
    • 32 bits
      • C:\Program Files (x86)\Common Files\System\Ole DB
    • 64 bits
      • C:\Program Files\Common Files\System\Ole DB

Le cas particulier de Jet… Alias le driver pour Excel et Access. Il n'existe pas de driver Jet pour la plateforme x64 (mais existe pour ia64), ne cherchez pas c'est inutile. Par contre Access 2010 arrive avec un driver de remplacement nommé ACE qui supporte aussi bien x86 que x64 :

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=C06B8369-60DD-4B64-A44B-84B371EDE16D&displaylang=en

Ne sautez pas de joie tout de suite… L'installation, même du driver seul, nécessite de désinstaller les composants Office x86 ! Donc patiente, particulièrement sur un environnement de production.

Et si les drivers n'existent pas ?

Si vous avez un moteur de base de données courant sur le marché… Oracle, DB/2, etc. Normalement pas de soucis, l'une des dernières versions devrait exister en 32 et 64 bits. Seule l'installation pourrait se révéler complexe.

Par contre si vraiment pas de drivers n'existent en 32 ou 64 bits il va falloir tricher un peu. Généralement (dans plus de 99%) c'est le driver 32 bits qui existera. Certains projets de Business Intelligence ont une option pour déployer le lot dans un environnement 32 bits

 

En effet SSIS a 2 exécutables… Un 32 bits et un autre 64 bits. 

On peut ruser en passant un appel externe qui lui sera en 32 bits… Par exemple, via : le Shell de commande Windows : C:\Windows\SysWOW64\CMD.exe (32 bits !).

Si le cas inverse se produit… On n'a pas le driver en 64 bits ou alors on n'a pas réussi à l'installer. Une technique utile dans ce cas serait de créer un serveur lié sous SQL Server, celui-ci sera dans la plateforme du serveur installé et donc le driver référencé sera le 32 ou 64 bits suivant la plateforme de SQL Server.

Certes, ce n'est pas l'idéal, mais ça peut sauver la vie quand on a tout essayé… Et puis ça marche dans les 2 sens… Un client 32 bits peut se connecter à une instance 64 bits qui référence le driver OLEDB 64 bits. Un client 64 bits peut se connecter à une instance 32 bits… Vous connaissez la suite.

Vous n'avez pas les licences pour ? SQL Server est là pour vous et fonctionnera parfaitement pour cet usage atypique !

En conclusion

Pour ma part j'espère que toutes les applications, et particulièrement Visual Studio vont faire le grand saut vers le 64 bits… Office y est bien passé avec succès. A ce moment-là adieu les problèmes de couche de compatibilité. Quoique jusqu'au prochain saut technologique, souvenez-vous du passage au 32 bits !

Bon accès aux données...

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Publié vendredi 8 octobre 2010 18:11 par christian
Classé sous :

Commentaires

Pas de commentaires
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01