web-dev-qa-db-fra.com

Excel "La table externe n'est pas au format attendu."

J'essaie de lire un fichier Excel (xlsx) en utilisant le code ci-dessous. Je reçois un "La table externe n'est pas dans le format attendu." erreur sauf si le fichier est déjà ouvert dans Excel. En d'autres termes, je dois d'abord ouvrir le fichier dans Excel avant de pouvoir lire si de mon programme C #. Le fichier xlsx est sur un partage de notre réseau. Comment puis-je lire le fichier sans avoir à l'ouvrir d'abord? Merci

string sql = "SELECT * FROM [Sheet1$]";
string excelConnection = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + pathname + ";Extended Properties=\"Excel 8.0;HDR=YES;IMEX=1;\"";

using (OleDbDataAdapter adaptor = new OleDbDataAdapter(sql, excelConnection)) {
    DataSet ds = new DataSet();
    adaptor.Fill(ds);
}
155
Sisiutl

"La table externe n’est pas au format attendu." Cela 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 string path = @"C:\src\RedirectApplication\RedirectApplication\301s.xlsx";
public static string connStr = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + path + ";Extended Properties=Excel 12.0;";
229
FAtBalloon

Merci pour ce code :) Je l'apprécie vraiment. Travaille pour moi.

public static string 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 connstring As String = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + path + ";Extended Properties=Excel 12.0;";

et si c'est .xls , utilisez:

Private Const connstring As String = "Provider=Microsoft.Jet.OLEDB.4.0;" & "Data Source=" + path + ";Extended Properties=""Excel 8.0;HDR=YES;"""
23
Trex

(J'ai une réputation trop basse pour commenter, mais c'est un commentaire sur l'entrée de JoshCaba, utilisant le moteur d'as au lieu de Jet pour Excel 2007)

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

Cela s'applique également à Excel 2010.

14
cederlof

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 normalement être ouvert par MS Excel 2003. Mais Microsoft.Jet.OLEDB.4.0 et Microsoft.ACE.OLEDB.12.0 ont tous deux " La table externe n'est pas au format attendu "exception".

Enfin, le problème est, comme le dit l'exception, "que ce n'est pas au format attendu". Bien que son nom d'extention soit xls, mais lorsque je l'ouvre avec un éditeur de texte, il s'agit en fait d'un fichier html bien formé, toutes les données sont dans une <table>, chaque <tr> est une ligne et chaque <td> est un cellule. Ensuite, je pense que je peux l’analyser de manière html.

8
Joe Ding

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

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

En résumé, l'installation de plusieurs versions de bureau et de divers sdk, assemblys, etc. de bureau a conduit à la référence ACEOleDB.dll du registre pointant vers le dossier OFFICE12 au lieu de OFFICE14 dans 

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

Du lien:

Vous pouvez également modifier la clé de registre en modifiant le chemin d'accès à la DLL pour qu'il corresponde à celui de votre version d'Access. 

Access 2007 doit utiliser OFFICE12, Access 2010 - OFFICE14 et Access 2013 - BUREAU15

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

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

Nom de la valeur: (par défaut)

Données de 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

3
jordanhill123

J'avais des erreurs avec 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. Le fait de masquer la feuille de calcul a permis au classeur d’importer.

2
John M

J'ai également constaté cette erreur en essayant d'utiliser des formules complexes INDIRECT () sur la feuille en cours d'importation. J'ai remarqué cela parce que c'était la seule différence entre deux classeurs où l'un importait et l'autre non. Les deux étaient des fichiers .xLSX de 2007+ et le moteur 12.0 a été installé.

J'ai confirmé que c'était le problème par:

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

et l'erreur a disparu.

2
John M. Black

J'ai eu ce problème et le changement de propriétés étendues en import HTML l'a corrigé comme suit: this post de Marcus Miris:

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

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

1

Couru dans le même problème et a trouvé ce fil. Aucune des suggestions ci-dessus n'a aidé, à l'exception du commentaire de @ Smith sur la réponse acceptée le 17 avril 2013.

Le fond de mon problème est assez proche de celui de @ zhiyazw - il s’agit en fait d’essayer de définir un fichier Excel exporté (SSRS dans mon cas) comme source de données dans le paquet dtsx. Tout ce que je faisais, après quelques modifications, était de renommer la feuille de travail. Il n’est pas nécessaire que les mots soient 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 Reporting Services n'en est pas conscient.

1
kerwei

J'ai eu le même problème. qui est résolu en utilisant ces étapes:

1.) Cliquez sur Fichier

2.) Sélectionnez "enregistrer sous"

3.) Cliquez sur la liste déroulante (Enregistrer sous le type)

 enter image description here 

4.) Sélectionnez le classeur Excel 97-2003

 enter image description here 

5.) Cliquez sur le bouton Enregistrer

 enter image description here 

1
Kamran

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

1
Nelson

ACE a remplacé 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();
0
Akshay Upadhyay

Si le fichier est en lecture seule, supprimez-le et cela devrait fonctionner à nouveau.

0
Tehscript

Cela peut se produire lorsque le classeur est protégé par un mot de passe. Certaines solutions de contournement permettent de supprimer cette protection, mais la plupart des exemples que vous trouverez en ligne sont obsolètes. Quoi qu'il en soit, la solution simple consiste à déprotéger le classeur manuellement, sinon utilisez quelque chose comme OpenXML pour supprimer la protection par programme.

0
KthProg

Si vous avez toujours ce problème, puis vérifiez vos autorisations, 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 fil ne disposait d'aucune autorisation. Je devais modifier l'ensemble des autorisations du dossier. et cela a commencé à fonctionner (j’y ai traité de nombreux fichiers) ... Il correspond également à de nombreuses suggestions, telles que changer le nom du fichier ou vérifier que le fichier n’a pas été lâché par un autre processus.

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

0
Juan

Je viens d'ajouter 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. Reçoit 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 est que le fichier d'origine contenait plus de 110 000 lignes. 

0
Kieran Quinn

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

0
unbob

le fichier peut être verrouillé par un autre processus, vous devez le copier puis le charger comme il est dit dans ce post

0
user3140982

Mon étendue consiste en un téléchargement de modèle et en vérifie le modèle lorsqu'il est rempli de données.

1) Téléchargez un fichier de modèle (.xlsx) avec la ligne d’en-tête. le fichier est généré avec openxml et fonctionne parfaitement.

2) Téléchargez le même fichier sans aucune modification par rapport à son état téléchargé. Cela provoquerait une erreur de connexion et échouerait (la connexion OLEDB est utilisée pour lire la feuille Excel).

Ici, si les données sont remplies, le programme fonctionne comme prévu.

Toute personne ayant une idée du problème est liée au fichier que nous sommes en train de créer. Elle est au format xml si nous l’ouvrons et nous venons de sauvegarder, convertissons-la au format Excel et tout fonctionne bien.

Une idée de télécharger Excel avec le type de fichier préféré?

0

Travailler avec du code plus ancien et rencontré cette même exception générique. Il est très difficile de cerner le problème et j'ai donc pensé ajouter ceci au cas où cela aiderait quelqu'un d'autre.

Dans mon cas, il y avait du code ailleurs dans le projet qui ouvrait un StreamReader sur le fichier Excel avant le OleDbConnection a essayé d'ouvrir le fichier (cela a été fait dans une classe de base).

Donc, en gros, je devais d'abord appeler Close() sur l'objet StreamReader pour pouvoir ouvrir la connexion OleDb avec succès. Cela n'avait rien à voir avec le fichier Excel lui-même, ni avec la chaîne OleDbConnection (qui est naturellement celle que je cherchais en premier).

0
tbone

J'ai récemment eu cette "System.Data.OleDb.OleDbException (0x80004005): La table externe n'est pas dans le format attendu." une erreur se produit. Je m'appuyais sur Microsoft Access 2010 Runtime. Avant la mise à jour installée automatiquement sur mon serveur le 12 décembre 2018, mon code C # fonctionnait correctement à l'aide du fournisseur Microsoft.ACE.OLEDB.12.0. Après l'installation de la mise à jour du 12 décembre 2018, j'ai commencé à obtenir le fichier «La table externe n'est pas au format attendu» dans mon fichier journal.

J'ai abandonné l'exécution Microsoft Access 2010 et installé l'exécution Microsoft Access 2013 et mon code C # a recommencé à fonctionner sans "System.Data.OleDb.OleDbException (0x80004005): la table externe n'est pas au format attendu". les erreurs.

La version 2013 qui a corrigé cette erreur pour moi https://www.Microsoft.com/en-us/download/confirmation.aspx?id=39358

La version 2010 qui fonctionnait pour moi avant la mise à jour installée automatiquement sur mon serveur le 12 décembre . https://www.Microsoft.com/en-us/download/confirmation.aspx?id=10910https://www.Microsoft.com/en-us/download/confirmation.aspx?id=10910

J'ai également eu cette erreur le mois dernier dans un processus automatisé. Le code C # a bien fonctionné lorsque je l'ai exécuté pour le débogage. J'ai constaté que le compte de service exécutant le code avait également besoin d'autorisations sur le dossier C:\Windows\Temp.

0
vvvv4d

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 en Excel 2003

0
Andrey Belykh