Ich versuche, eine Excel-Datei (xlsx) mit dem unten gezeigten Code zu lesen. Ich erhalte die Meldung "Externe Tabelle hat nicht das erwartete Format." Fehler, es sei denn, ich habe die Datei bereits in Excel geöffnet. Mit anderen Worten, ich muss die Datei zuerst in Excel öffnen, bevor ich sie aus meinem C # -Programm lesen kann. Die xlsx-Datei befindet sich auf einer Freigabe in unserem Netzwerk. Wie kann ich die Datei lesen, ohne sie zuerst öffnen zu müssen? Vielen Dank

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

"Externe Tabelle hat nicht das erwartete Format." Tritt normalerweise auf, wenn versucht wird, eine Excel 2007-Datei mit einer Verbindungszeichenfolge zu verwenden, die Folgendes verwendet: Microsoft.Jet.OLEDB.4.0 und Extended Properties = Excel 8.0

Die Verwendung der folgenden Verbindungszeichenfolge scheint die meisten Probleme zu beheben.

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

Danke für diesen Code :) Ich weiß das wirklich zu schätzen. Funktioniert bei mir.

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

Wenn Sie also eine diff-Version einer Excel-Datei haben, rufen Sie den Dateinamen ab. Wenn die Erweiterung .xlsx lautet , verwenden Sie Folgendes :

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

und wenn es sich um .xls handelt , verwenden Sie:

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

(Ich habe einen zu geringen Ruf, um einen Kommentar abzugeben, aber dies ist ein Kommentar zu JoshCabas Eintrag, bei dem die Ace-Engine anstelle von Jet für Excel 2007 verwendet wird.)

Wenn Sie Ace nicht auf Ihrem Computer installiert / registriert haben, können Sie es unter folgender Adresse herunterladen : https://www.microsoft.com/en-US/download/details.aspx?id=13255

Dies gilt auch für Excel 2010.

Fügen Sie einfach meinen Fall hinzu. Meine XLS-Datei wurde von einer Datenexportfunktion von einer Website erstellt. Die Dateierweiterung lautet XLS. Sie kann normalerweise von MS Excel 2003 geöffnet werden. Sowohl Microsoft.Jet.OLEDB.4.0 als auch Microsoft.ACE.OLEDB.12.0 haben eine " Externe Tabelle hat nicht die erwartete Ausnahme "Format".

Schließlich ist das Problem, genau wie die Ausnahme sagte, "es ist nicht im erwarteten Format". Der Erweiterungsname lautet zwar xls, aber wenn ich ihn mit einem Texteditor öffne, handelt es sich tatsächlich um eine wohlgeformte HTML-Datei. Alle Daten befinden sich in einer <Tabelle>, jede <tr> ist eine Zeile und jede <td> ist eine Zelle. Dann denke ich, ich kann es auf HTML-Weise analysieren.

Ich hatte das gleiche Problem. welche wie mit diesen Schritten gelöst:

1.) Klicken Sie auf Datei

2.) Wählen Sie "Speichern unter"

3.) Klicken Sie auf Dropdown (Dateityp)

4.) Wählen Sie Excel 97-2003 Workbook

5.) Klicken Sie auf die Schaltfläche Speichern

Ich hatte das gleiche Problem (mit ACE.OLEDB) und was es für mich gelöst hat, war dieser Link:

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

Das Wesentliche dabei ist, dass die Installation mehrerer Office-Versionen und verschiedener Office-SDKs, Assemblys usw. dazu geführt hat, dass die ACEOleDB.dll-Referenz in der Registrierung auf den Ordner OFFICE12 anstatt auf OFFICE14 verweist

C: \ Programme \ Gemeinsame Dateien \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL

Über den Link:

Alternativ können Sie den Registrierungsschlüssel so ändern, dass der DLL-Pfad dem Ihrer Access-Version entspricht.

Access 2007 sollte OFFICE12, Access 2010 - OFFICE14 und Access 2013 - OFFICE15 verwenden

(Betriebssystem: 64-Bit-Office: 64-Bit) oder (Betriebssystem: 32-Bit-Office: 32-Bit)

Schlüssel: HKCR \ CLSID {3BE786A0-0366-4F5C-9434-25CF162E475E} \ InprocServer32 \

Wert Name: (Standard)

Wertdaten: C: \ Programme \ Gemeinsame Dateien \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL

(Betriebssystem: 64-Bit-Office: 32-Bit)

Schlüssel: HKCR \ Wow6432Node \ CLSID {3BE786A0-0366-4F5C-9434-25CF162E475E} \ InprocServer32 \

Wert Name: (Standard)

Wertdaten: C: \ Programme (x86) \ Gemeinsame Dateien \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL

Ich habe diesen Fehler auch beim Versuch gesehen, komplexe INDIRECT () - Formeln auf dem zu importierenden Blatt zu verwenden. Ich bemerkte dies, weil dies der einzige Unterschied zwischen zwei Arbeitsmappen war, in die eine importiert wurde und die andere nicht. Bei beiden handelte es sich um .XLSX-Dateien ab 2007, und die 12.0-Engine wurde installiert.

Ich bestätigte, dass dies das Problem war durch:

• Erstellen einer Kopie der Datei (hatte immer noch das Problem, es war also kein Unterschied beim Speichern als)
• Auswählen aller Zellen im Blatt mit den indirekten Formeln
• Nur als Werte einfügen

und der Fehler verschwand.

Ich habe Fehler beim Lesen einer XLSX-Arbeitsmappe durch Dritte und Oledb erhalten. Das Problem scheint ein verstecktes Arbeitsblatt zu sein, das einen Fehler verursacht. Durch das Einblenden des Arbeitsblatts konnte die Arbeitsmappe importiert werden.

Wenn die Datei schreibgeschützt ist, entfernen Sie sie einfach und sie sollte wieder funktionieren.

Bin auf das gleiche Problem gestoßen und habe diesen Thread gefunden. Keiner der oben genannten Vorschläge hat geholfen, außer @ Smiths Kommentar zur akzeptierten Antwort am 17. April 13.

Der Hintergrund meines Problems liegt nahe genug bei @ zhiyazw - im Grunde genommen wird versucht, eine exportierte Excel-Datei (in meinem Fall SSRS) als Datenquelle im dtsx-Paket festzulegen. Nach einigem Basteln habe ich nur das Arbeitsblatt umbenannt. Es muss nicht klein geschrieben sein, wie @Smith vorgeschlagen hat.

Ich nehme an, dass ACE OLEDB erwartet, dass die Excel-Datei einer bestimmten XML-Struktur folgt, aber Reporting Services ist sich dessen irgendwie nicht bewusst.

Diese Adresse der Excel-Datei hat möglicherweise eine falsche Erweiterung. Sie können die Erweiterung von xls in xlsx oder umgekehrt ändern und es erneut versuchen.

Die Datei wird möglicherweise von einem anderen Prozess gesperrt. Sie müssen sie kopieren und dann wie in diesem Beitrag beschrieben laden

Dies kann auch eine Datei sein, die Bilder oder Diagramme enthält. Weitere Informationen finden Sie unter : http://kb.tableausoftware.com/articles/knowledgebase/resolving-error-external-table-is-not-in-expected-format

Es wird empfohlen, als Excel 2003 zu speichern

Ich füge nur meine Lösung zu diesem Problem hinzu. Ich habe eine XLSX-Datei auf den Webserver hochgeladen, dann daraus gelesen und Masseneinfügungen in SQL Server vorgenommen. Erhielt die gleiche Fehlermeldung, versuchte alle vorgeschlagenen Antworten, aber keine funktionierte. Schließlich habe ich die Datei als Excel 97-2003 (.xls) gespeichert, was funktioniert hat. Das einzige Problem, das ich jetzt habe, ist, dass die Originaldatei mehr als 110.000 Zeilen hatte.

Wenn Sie immer noch dieses Problem haben, überprüfen Sie Ihre Berechtigungen. Ich habe viele dieser Vorschläge ausprobiert. Mein konkretes Problem war, dass die Datei, die ich verarbeiten wollte, unter Quellcodeverwaltung stand und der Thread keine Berechtigungen hatte. Ich musste die gesamten Ordnerberechtigungen ändern und es fing an zu funktionieren (ich habe dort viele Dateien verarbeitet) ... Es stimmt auch mit vielen Vorschlägen überein, z. B. den Namen der Datei zu ändern oder zu überprüfen, ob die Datei nicht von einem anderen Prozess gelöscht wird.

Ich hoffe es hilft dir.

Ich hatte dieses Problem und das Ändern der erweiterten Eigenschaften in HTML-Import hat es gemäß diesem Beitrag von Marcus Miris behoben :

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

Anstelle von OleDb können Sie auch Excel Interop verwenden und das Arbeitsblatt schreibgeschützt öffnen.

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

ACE hat JET abgelöst

Ace unterstützt alle früheren Versionen von Office

Dieser Code funktioniert gut!

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

Dies kann auftreten, wenn die Arbeitsmappe kennwortgeschützt ist. Es gibt einige Problemumgehungen, um diesen Schutz zu entfernen, aber die meisten Beispiele, die Sie online finden, sind veraltet. In beiden Fällen besteht die einfache Lösung darin, den Schutz der Arbeitsmappe manuell aufzuheben. Andernfalls können Sie den Schutz mithilfe von OpenXML programmgesteuert entfernen.

Ich habe diesen Fehler kürzlich in einem Kontext gesehen, der keiner der zuvor aufgeführten Antworten entsprach. Es stellte sich heraus, dass es sich um einen Konflikt mit AutoVer handelte . Problemumgehung: Deaktivieren Sie AutoVer vorübergehend.

Ich hatte kürzlich diese "System.Data.OleDb.OleDbException (0x80004005): Externe Tabelle hat nicht das erwartete Format." Fehler auftreten. Ich habe mich auf Microsoft Access 2010 Runtime verlassen. Vor dem Update, das am 12. Dezember 2018 automatisch auf meinem Server installiert wurde, lief mein C # -Code mit dem Microsoft.ACE.OLEDB.12.0-Anbieter einwandfrei. Nachdem das Update vom 12. Dezember 2018 installiert wurde, begann ich, die "Externe Tabelle hat nicht das erwartete Format" in meiner Protokolldatei abzurufen.

Ich habe die Microsoft Access 2010-Laufzeit beendet und die Microsoft Access 2013-Laufzeit installiert, und mein C # -Code begann wieder ohne "System.Data.OleDb.OleDbException (0x80004005): Externe Tabelle hat nicht das erwartete Format." Fehler.

2013-Version, die diesen Fehler für mich behoben hat https://www.microsoft.com/en-us/download/confirmation.aspx?id=39358

2010-Version, die vor dem Update, das am 12. Dezember automatisch auf meinem Server installiert wurde, für mich funktioniert hat. https://www.microsoft.com/en-us/download/confirmation.aspx?id=10910 https://www.microsoft.com/en-us/download/confirmation.aspx?id=10910

Ich hatte auch diesen Fehler letzten Monat in einem automatisierten Prozess aufgetreten. Der C # -Code lief beim Debuggen einwandfrei. Ich habe festgestellt, dass das Dienstkonto, auf dem der Code ausgeführt wird, auch Berechtigungen für den Ordner C: \ Windows \ Temp benötigt.

Mein Bereich besteht aus dem Herunterladen von Vorlagen und überprüft die Vorlage, wenn sie mit Daten gefüllt ist.

1) Laden Sie eine Vorlagendatei (.xlsx) mit der Kopfzeile herunter. Die Datei wird mit openxml generiert und funktioniert einwandfrei.

2) Laden Sie dieselbe Datei ohne Änderung des heruntergeladenen Status hoch. Dies führt zu einem Verbindungsfehler und schlägt fehl (die OLEDB-Verbindung wird zum Lesen des Excel-Arbeitsblatts verwendet).

Wenn die Daten gefüllt sind, funktioniert das Programm hier wie erwartet.

Jeder, der eine Idee hat, dass das Problem mit der Datei zusammenhängt, die wir erstellen, ist im XML- Format, wenn wir sie öffnen und einfach speichern, um sie in das Excel-Format zu konvertieren, und es funktioniert gut.

Haben Sie eine Idee, das Excel mit dem bevorzugten Dateityp herunterzuladen?

Ich habe mit älterem Code gearbeitet und bin auf dieselbe generische Ausnahme gestoßen. Es ist sehr schwer, das Problem aufzuspüren, daher dachte ich, ich würde es hier hinzufügen, falls es jemand anderem hilft.

In meinem Fall gab es an anderer Stelle im Projekt Code, der einen StreamReader in der Excel-Datei öffnete, bevor OleDbConnection versuchte, die Datei zu öffnen (dies wurde in einer Basisklasse durchgeführt).

Im Grunde musste ich nur Close()zuerst das StreamReader-Objekt aufrufen, dann konnte ich die OleDb-Verbindung erfolgreich öffnen. Es hatte nichts mit der Excel-Datei selbst oder mit der OleDbConnection-Zeichenfolge zu tun (was ich natürlich zuerst gesehen habe).