Comment puis-je résoudre l'erreur 0xC0209303 de SSIS Excel Connection Manager?
J'ai créé un package SSIS qui importe un fichier Excel dans une table SQL Server.
Le package SSIS s'exécute sans problème lorsque je l'exécute localement sur ma machine, mais lorsque je l'exécute sur le serveur où le package sera planifié, j'obtiens l'erreur ci-dessous (à partir d'un fichier texte, je génère des erreurs pour utiliser la journalisation SSIS).
Après des recherches, les seules recommandations que j'ai pu trouver étaient de définir la propriété Run64BitRuntime sur false, ce que j'ai fait mais toujours pas de chance. Je doute que c'est ce qui cause mon erreur car l'erreur ne spécifie rien concernant 64 bits (comme c'était le cas dans les articles que j'ai trouvés).
J'ai également pensé que le serveur ne disposait peut-être pas des pilotes Excel appropriés, mais je ne pense pas que ce soit le cas non plus, car le message d'erreur disait généralement que les pilotes n'étaient pas enregistrés.
Je n'ai actuellement pas accès à distance au serveur. Je peux uniquement télécharger le package dans un dossier, puis il est exécuté par une application, donc les seuls messages d'erreur que je peux voir sont ceux qui se trouvent dans le journal des erreurs de texte que j'ai créé.
Code d'erreur DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. L'appel de la méthode AcquireConnection au gestionnaire de connexions "Envision" a échoué avec le code d'erreur 0xC0209303. Il peut y avoir des messages d'erreur publiés avant cela avec plus d'informations sur la raison pour laquelle l'appel de méthode AcquireConnection a échoué.
"Envision" est le nom de mon gestionnaire de connexions Excel.
Je remplis le chemin du fichier Excel et la chaîne de connexion à l'aide d'expressions.
L'expression de chaîne de connexion ressemble à ceci:
"Provider = Microsoft.ACE.OLEDB.12.0; Data Source =" + @ [User :: SourceFilePath] + "; Extended Properties = \" Excel 12.0 XML; HDR = YES\";"
Le SSIS Pacakge est exécuté par un nom d'utilisateur/compte Windows. Je pense que ce pourrait être un compte de services Web. (BDS_sprtIIS)
Quelqu'un a-t-il des solutions ou des suggestions sur la façon de résoudre ce problème du package fonctionnant uniquement sur ma machine locale mais pas sur le serveur réel sur lequel le package sera déployé?
J'ai trouvé la réponse ci-dessous sur un autre forum, est-ce la cause de mes problèmes? Ils disent essentiellement que le gestionnaire de connexions Excel essaie d'accéder au dossier temporaire des utilisateurs pour une raison quelconque et s'il n'a pas accès à ce dossier, il échouera:
J'ai également remarqué que le pilote Microsoft.JET.OLEDB.4.0 essaiera de lire le répertoire temporaire sous le profil de l'utilisateur connecté.
.
... Nous exécutons nos agents SQL à l'aide d'un compte de domaine de niveau inférieur et exécutons nos packages SSIS à l'aide d'un compte proxy. Vous avez raison, Procmon me l'a également confirmé. J'ai donné les droits du compte proxy au répertoire temporaire du profil (C:\Documents and Settings\SQLAgentDomainAccount\Local Settings\Temp) et cela a fonctionné!
Je n'utilise pas de travaux SQL Server ou de comptes proxy. Le package est simplement exécuté par un compte Windows très probablement via un script de ligne de commande.
Le compte Windows a accès au fichier mais je ne sais pas s'il a accès à son dossier "TEMP" (que je ne référence jamais dans le package, donc je ne sais pas pourquoi il aurait besoin d'avoir accès à ce dossier) ...
Il y avait 2 problèmes qui empêchaient le package de s'exécuter sur le serveur. Voici les 2 problèmes et les solutions que j'ai trouvés.
Le package est exécuté par une application qui utilise l'utilitaire DTexec 64 bits par défaut, mais le package doit être exécuté à l'aide de la version 32 bits de l'utilitaire pour pouvoir accéder correctement au fichier Excel via le gestionnaire de connexions Excel.
J'ai créé un package SSIS "wrapper" qui utilise une tâche d'exécution de processus qui appelle l'utilitaire DTExec 32 bits (au lieu de 64 bits) et passe la commande pour ouvrir le package d'origine.
![Execute Process Task]()
J'ai également dû installer la version 32 bits de Microsoft Access Database Engine 2010 Redistributable .
Lectures complémentaires:
Microsoft.ACE.OLEDB.12.0 n'est pas enregistré (débordement de pile)
L'installation du moteur d'accès 32 bits et son exécution en mode 32 bits ont fonctionné pour moi!