J'essaie de lire un fichier Excel (xlsx) en utilisant le code ci-dessous. J'obtiens un "La table externe n'est pas au 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 le lire à partir de mon programme C #. Le fichier xlsx est sur un partage sur notre réseau. Comment puis-je lire le fichier sans avoir à l'ouvrir au préalable? 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);
}

"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 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;";

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 une 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;"""

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

Si Ace n'est pas installé / enregistré sur votre ordinateur, vous pouvez l'obtenir à l' adresse : https://www.microsoft.com/en-US/download/details.aspx?id=13255

Cela 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 au format attendu "exception.

Enfin, le problème est, comme le disait l'exception, "ce n'est pas dans le format attendu". Bien que son nom d'extension 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.

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

1.) Cliquez sur Fichier

2.) Sélectionnez "enregistrer sous"

3.) Cliquez sur le menu déroulant (Enregistrer comme type)

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

5.) Cliquez sur le bouton Enregistrer

J'ai eu ce même problème (en utilisant 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 de bureau et de divers sdk de bureau, assemblages, etc. avait conduit à la référence ACEOleDB.dll dans le registre pointant vers le dossier OFFICE12 au lieu de OFFICE14 dans

C: \ Program Files \ Common Files \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL

Depuis le lien:

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

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

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

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

Nom de la valeur: (par défaut)

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

(Système d'exploitation: 64 bits Office: 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) \ Common Files \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL

J'ai également vu cette erreur en essayant d'utiliser des formules INDIRECT () complexes sur la feuille qui est importée. J'ai remarqué cela 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 a été installé.

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

• Faire une copie du fichier (il y avait 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 en tant que valeurs uniquement

et l'erreur a disparu.

J'obtenais des erreurs avec la lecture tierce et Oledb d'un classeur XLSX. Le problème semble être une feuille de calcul masquée qui provoque une erreur. L'affichage de la feuille de calcul a permis l'importation du classeur.

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

Ran 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 à la réponse acceptée du 17 avril 2013.

Le contexte de mon problème est assez proche de celui de @ zhiyazw - essentiellement en essayant 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 bricolages, a été de renommer la feuille de calcul. Il n'est pas nécessaire que ce soit en minuscules, 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.

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

le fichier peut être verrouillé par un autre processus, vous devez le copier puis le charger comme il est dit 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 d'enregistrer sous Excel 2003

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 masse dans SQL Server. Obtenait 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) qui a fonctionné ... le seul problème que j'ai maintenant est que le fichier d'origine avait plus de 110 000 lignes.

Si vous rencontrez toujours ce problème, 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 n'avait pas d'autorisations, j'ai dû modifier toutes les autorisations du dossier et cela a commencé à fonctionner (je traitais de nombreux fichiers là-dedans) ... Cela correspond également à de nombreuses suggestions comme changer le nom du fichier ou vérifier que le fichier n'est pas repéré 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 l'a corrigé selon cet article de Marcus Miris:

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

Au lieu d'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

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();

Cela peut se produire lorsque le classeur est protégé par mot de passe. Il existe quelques solutions de contournement 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 programme.

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

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

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

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

Version 2010 qui fonctionnait pour moi avant la mise à jour qui a été automatiquement installée sur mon serveur le 12 décembre. https://www.microsoft.com/en-us/download/confirmation.aspx?id=10910 https://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 # fonctionnait bien lorsque je l'ai exécuté en débogage. J'ai trouvé que le compte de service exécutant le code avait également besoin d'autorisations sur le dossier C: \ Windows \ Temp.

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

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

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

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

Quiconque a une idée du problème est lié au fichier que nous créons, il est en xml format si nous l'ouvrons et sauvegardons simplement le convertir au format Excel et cela fonctionne bien.

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

Travailler avec un code plus ancien et rencontré cette même exception générique. Très difficile de localiser le problème, j'ai donc pensé ajouter ici 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 que OleDbConnection n'essaye d'ouvrir le fichier (cela a été fait dans une classe de base).

Donc, fondamentalement, j'avais juste besoin d'appeler Close()d'abord l'objet StreamReader, puis je pourrais 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 là où je regardais en premier).