J'ai un serveur capable de créer et d'exécuter une tâche d'importation Excel à l'aide de l'Assistant d'importation. J'essaie d'automatiser ce processus à l'aide d'un package Visual Studio 2010 Integration Services que je développe sur ce serveur.
Le problème survient lorsque vous essayez de concevoir le package. J'ai ajouté une connexion Excel et l'ai pointé vers le fichier Excel sur un disque local (le même fichier que j'ai déjà importé avec succès à l'aide de l'assistant d'importation). Lorsque j'ajoute une source Excel au flux de données et que je spécifie la connexion Excel, lorsque je vais dans la liste déroulante Nom de la feuille Excel, je vois seulement "Aucune table ni aucune vue ne peut être chargée" et j'obtiens le message d'erreur suivant.
"Impossible de récupérer les informations de la table pour le gestionnaire de connexions . Impossible de se connecter à la source à l'aide du gestionnaire de connexions ..."
Je ne peux pas trouver cette erreur enregistrée n'importe où et je ne sais pas pourquoi elle échoue. Le répertoire est partagé avec les utilisateurs authentifiés et le fichier n'est pas utilisé.
Des idées comment déboguer cette erreur? Je comprends que des problèmes peuvent survenir en mode 64 bits, mais est-ce que cela s'applique au développement?
Je devrais ajouter qu’il s’agit d’un fichier Excel 2007 .XLSX et que la connexion est définie sur Excel 2007.
Il semble que la version 32 bits d'Excel n'ait pas été installée. Rappelez-vous que SSDT est un IDE 32 bits. Par conséquent, lorsque les données proviennent de SSDT, les fournisseurs de données 32 bits sont utilisés. Lors de l'exécution du package en dehors de SSDT, il s'exécute en mode 64 bits (pas toujours, mais principalement) et utilise les fournisseurs de données 64 bits.
Gardez toujours à l'esprit que si vous souhaitez exécuter votre package en 64 bits (ce que vous devez viser), vous aurez besoin des fournisseurs de données 32 bits (pour le développement en SSDT) ainsi que des fournisseurs de données 64 bits (pour exécution du paquet en production).
J'ai téléchargé les pilotes d'accès 32 bits à partir de:
Après l'installation, je pouvais voir les feuilles de calcul
La source:
La solution consiste à enregistrer le fichier Excel sous Excel 97-2003.
J'ai également rencontré ce problème aujourd'hui, mais j'ai trouvé une solution différente de l'utilisation d'Excel 97-2003. Selon Maderia , le problème est que SSDT (Outils de données SQL Server) est une application 32 bits et ne peut utiliser que des fournisseurs 32 bits. mais le fournisseur de base de données ACE OLE 64 bits est probablement installé. Vous pouvez jouer avec essayer d’installer le fournisseur 32 bits, mais vous ne pouvez pas avoir les versions 64 et 32 installées en même temps. La solution suggérée par Maderia (et qui a fonctionné pour moi) était de définir DelayValidation = TRUE sur les tâches pour lesquelles j'importais/exportais le fichier Excel 2007.
La solution de contournement simple consiste à ouvrir le fichier et à appuyer simplement sur le bouton Enregistrer dans Excel (il n'est pas nécessaire de modifier le format). une fois enregistré dans Excel, il commencera à fonctionner et vous devriez pouvoir voir ses feuilles dans la DFT.
Les recommandations de cet article Extraction de données à partir d'Excel avec SSIS ont résolu le problème pour moi.
J'ai téléchargé le pilote 32 bits de MS Access Database Engine 2010 À partir du lien de cet article.
Définissez également les propriétés de configuration du projet pour le débogage Run64BitRuntime = False
Dans SQL Server 2014, SSMS (Catalogue du service d'intégration -> SSISDB -> Environnements -> Projets pour tous les packages dans la case à cocher Valider cochée 32 bit Runtime
.
Mes packages SSIS fonctionnent maintenant dans les environnements VS 2013 et SQL Server 2014.
Vous devez utiliser une version plus ancienne du pilote de connectivité de données ( Pilote Office System 2007: Composants de connectivité de données ) et sélectionner Excel version 2007-2010 dans la fenêtre de configuration du gestionnaire de connexions. pour Office 2016 est corrompu
Ma réponse est très similaire à celle de @biscoop, mais je vais en dire un peu plus sur ce qui est susceptible de s’appliquer à la question ou à d’autres personnes.
J'ai eu un .xls qui était une extraction d'une de nos webapps. La connexion Excel ne fonctionnerait pas (message d'erreur: "aucune table ni vue ne pourrait être chargée"). En guise de remarque, lors de l'ouverture du fichier, il y aurait un avertissement indiquant que le fichier provenait d'une source en ligne et que le contenu devait être activé.
J'ai essayé de sauvegarder le même fichier en tant que .xlsx et cela a fonctionné . J'ai essayé de sauvegarder le même fichier avec un autre nom en tant que .xls et cela a fonctionné aussi . Donc, comme dernier test, je n'ai ouvert que le code source fichier .xls, en cliquant sur Enregistrer et la connexion a fonctionné.
Réponse courte: essayez simplement de voir si l’ouverture du fichier et la sauvegarde permettaient de résoudre le problème.