“La table externe n’est pas au format attendu.” se produit généralement lorsque vous essayez d’utiliser un fichier Excel 2007 avec une chaîne de connexion qui utilise: Microsoft.Jet.OLEDB.4.0 et Extended Properties = Excel 8.0

L’utilisation de la chaîne de connexion suivante semble résoudre la plupart des problèmes.

 public static ssortingng path = @"C:\src\RedirectApplication\RedirectApplication\301s.xlsx"; public static ssortingng connStr = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + path + ";Extended Properties=Excel 12.0;"; 

Merci pour ce code 🙂 Je l’apprécie vraiment. Travaille pour moi.

 public static ssortingng connStr = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + path + ";Extended Properties=Excel 12.0;"; 

Donc, si vous avez la version diff du fichier Excel, obtenez le nom du fichier, si son extension est .xlsx , utilisez ceci:

 Private Const connssortingng As Ssortingng = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + path + ";Extended Properties=Excel 12.0;"; 

et s’il s’agit de .xls , utilisez:

 Private Const connssortingng As Ssortingng = "Provider=Microsoft.Jet.OLEDB.4.0;" & "Data Source=" + path + ";Extended Properties=""Excel 8.0;HDR=YES;""" 

(J’ai trop peu de réputation pour commenter, mais c’est un commentaire sur l’entrée de JoshCaba, en utilisant le moteur Ace au lieu de Jet pour Excel 2007)

Si vous n’avez pas installé / enregistré Ace sur votre ordinateur, vous pouvez l’obtenir à l’ adresse suivante : http://www.microsoft.com/downloads/details.aspx?FamilyID=7554F536-8C28-4598-9B72-EF94E038C891&displaylang=en

Il s’applique également à Excel 2010.

Ajoutez juste mon cas. Mon fichier xls a été créé par une fonction d’exportation de données à partir d’un site Web, l’extension de fichier est xls, il peut être normalement ouvert par MS Excel 2003. Mais Microsoft.Jet.OLEDB.4.0 et Microsoft.ACE.OLEDB.12.0 ont un ” La table externe n’est pas dans le format “exception”.

Enfin, le problème est, comme l’a dit l’exception, “ce n’est pas dans le format attendu”. Bien que son nom soit xls, mais quand je l’ouvre avec un éditeur de texte, c’est en fait un fichier HTML bien formé, toutes les données sont dans un

J’ai eu ce même problème (en utilisant le ACE.OLEDB) et ce qui l’a résolu pour moi était ce lien:

http://support.microsoft.com/kb/2459087

L’essentiel est que l’installation de plusieurs versions d’office et de plusieurs sdk, assemblys, etc. de bureau a conduit à la référence ACEOleDB.dll dans le registre pointant vers le dossier OFFICE12 au lieu de OFFICE14 dans

C: \ Program Files \ Fichiers communs \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL

À partir du lien:

Vous pouvez également modifier la clé de registre en modifiant le chemin d’access à la DLL pour correspondre à celui de votre version Access.

Access 2007 devrait utiliser OFFICE12, Access 2010 – OFFICE14 et Access 2013 – OFFICE15

(OS: 64bit Office: 64bit) ou (OS: 32bit Office: 32bit)

Clé: HKCR \ CLSID {3BE786A0-0366-4F5C-9434-25CF162E475E} \ InprocServer32 \

Nom de la valeur: (par défaut)

Données de la valeur: C: \ Program Files \ Fichiers communs \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL

(OS: Bureau 64 bits: 32 bits)

Clé: HKCR \ Wow6432Node \ CLSID {3BE786A0-0366-4F5C-9434-25CF162E475E} \ InprocServer32 \

Nom de la valeur: (par défaut)

Données de la valeur: C: \ Program Files (x86) \ Fichiers communs \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL

J’ai également constaté cette erreur lors de la tentative d’utilisation de formules INDIRECT () complexes sur la feuille en cours d’importation. Je l’ai remarqué parce que c’était la seule différence entre deux classeurs où l’un importait et l’autre pas. Les deux étaient des fichiers .XLSX 2007+ et le moteur 12.0 était installé.

J’ai confirmé que c’était le problème en:

• Faire une copie du fichier (toujours le problème, donc ce n’était pas une différence de sauvegarde)
• Sélection de toutes les cellules de la feuille avec les formules indirectes
• Coller comme valeurs seulement

et l’erreur a disparu.

J’obtenais des erreurs lors de la lecture par un tiers et par Oledb d’un classeur XLSX. Le problème semble être une feuille de calcul masquée qui provoque une erreur. Afficher la feuille de calcul active le classeur à importer.

Au lieu de OleDb, vous pouvez utiliser Excel Interop et ouvrir la feuille de calcul en lecture seule.

https://msdn.microsoft.com/en-us/library/microsoft.office.interop.excel.workbooks.open(v=office.15).aspx

le fichier peut être verrouillé par un autre processus, vous devez le copier, puis le charger comme indiqué dans cet article

Cela peut également être un fichier contenant des images ou des graphiques, voir ceci: http://kb.tableausoftware.com/articles/knowledgebase/resolving-error-external-table-is-not-in-expected-format

La recommandation est de sauvegarder au format Excel 2003

Il suffit d’append ma solution à ce problème. J’étais en train de télécharger un fichier .xlsx sur le serveur Web, puis de le lire et de l’insérer en bloc dans SQL Server. A reçu ce même message d’erreur, a essayé toutes les réponses suggérées mais aucune n’a fonctionné. Finalement, j’ai enregistré le fichier sous Excel 97-2003 (.xls), ce qui a fonctionné … le seul problème que j’ai maintenant, c’est que le fichier d’origine contenait plus de 110 000 lignes.

Si vous avez toujours ce problème, puis vérifiez vos permissions, j’ai essayé plusieurs de ces suggestions et mon problème concret était que le fichier que je voulais traiter était sous contrôle de code source et que le thread n’avait aucune autorisation. et cela a commencé à fonctionner (je traitais beaucoup de fichiers là-dedans) … Cela correspond aussi à beaucoup de suggestions comme changer le nom du fichier ou vérifier que le fichier n’est pas détourné par un autre processus.

J’espère que ça t’aide.

J’ai eu ce problème et la modification des propriétés étendues en importation HTML a corrigé ce problème selon ce post de Marcus Miris:

 strCon = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & importedFilePathAndName _ & ";Extended Properties=""HTML Import;HDR=No;IMEX=1"";" 

ACE a dépassé JET

Ace Prend en charge toutes les versions précédentes d’Office

Ce code fonctionne bien!

  OleDbConnection MyConnection; DataSet DtSet; OleDbDataAdapter MyCommand; MyConnection = new System.Data.OleDb.OleDbConnection(@"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=..\\Book.xlsx;Extended Properties=Excel 12.0;"); MyCommand = new System.Data.OleDb.OleDbDataAdapter("select * from [Sheet1$]", MyConnection); DtSet = new System.Data.DataSet(); MyCommand.Fill(DtSet); dataGridView1.DataSource = DtSet.Tables[0]; MyConnection.Close(); 

Cela peut se produire lorsque le classeur est protégé par mot de passe. Il existe des solutions pour supprimer cette protection, mais la plupart des exemples que vous trouverez en ligne sont obsolètes. Dans tous les cas, la solution simple consiste à déprotéger le classeur manuellement, sinon utilisez quelque chose comme OpenXML pour supprimer la protection par programmation.

J’ai récemment vu cette erreur dans un contexte qui ne correspond à aucune des réponses précédemment répertoriées. Il s’est avéré être un conflit avec AutoVer . Solution: désactivez temporairement AutoVer.

Ran dans le même problème et a trouvé ce fil. Aucune des suggestions ci-dessus n’a aidé, sauf le commentaire de @ Smith à la réponse acceptée le 17 avril 13.

L’arrière-plan de mon problème est assez proche de celui de @ zhiyazw – essayant essentiellement de définir un fichier Excel exporté (SSRS dans mon cas) comme source de données dans le package dtsx. Tout ce que j’ai fait, après quelques retouches, était de renommer la feuille de travail. Il n’a pas besoin d’être en minuscule comme @Smith l’a suggéré.

Je suppose que ACE OLEDB s’attend à ce que le fichier Excel suive une certaine structure XML mais que Reporting Services n’en ait pas conscience.

Cette adresse de fichier Excel peut avoir une extension incorrecte. Vous pouvez changer l’extension de xls à xlsx ou vice versa et réessayer.