[C#] komplette Excel-Datei auslesen

[Blackodem]

Grüßt euch,

ich hab ein kleines Problem auf der Arbeit:

Ich schreibe ein Tool das sowohl Quelltext, Textdateien als auch Exceldateien auslesen, es mit Regex bearbeiten und anschließend das Ergebnis in einer Exceldatei ausgeben soll. Das auslesen der Quelltexte und Textdateien funktioniert bereits, die Regexverwertung und die Excel ausgabe auch, aber beim einlesen aus Excel stoße ich auf ein Problem:

Ich muss "alle" Daten aus der Datei auslesen, aber ich kann immer nur auf einzelne Zellen zugreifen in dem ich sie z.B. über A1, 1 anspreche

z.B. (Range lRange = lWorksheet.get_Range("A" + i.ToString(), 1)

das machte es mir aber unmöglich alle Daten auszulesen, da es ja auch eine Tabelle geben kann die bis zur Spalte XYZ reicht.

Habt ihr eine Ahnung wie ich das Problem lösen kann, also quasi alle Einträge einer Excel-Datei hintereinander in einen String zu speichern?

Ich danke euch

[lilith2k3]

Warum arbeitest Du e.g. nicht mit einer OleDB-Verbindung und liest die Arbeitsmappe in ein Dataset? Von da aus kannst Du bequem weiterarbeiten.

[Argbeil]

little2k3 hat recht. Wenn du jetzt auf die Zellen uugreifen kannst, hast du eine Abhängigkeit zu Excel, vermutlich per COM Referenz? D.h. auf dem Rechner auf dem deine Anwendung läuft muss Excel installiert sein, evtl. auch noch in der richtigen Version.

Bau lieber einen oledb Connection zu der Excel-datei auf, du kannst dann wie auf eine Datenbank per oledbcommand oder dataAdapter auf die Excel-Sheets zugreifen.

[lilith2k3]

little2k3 hat recht

(lilith2k3 ... unter uns gesagt *g* - aber ich find's gut, wenn jemand sagt, ich habe recht)

[streffin]

per jet auf die Excel zugreifen ist zwar bequemer, aber ich kann da nur von abraten.

Das hat einige Nachteile, die zu Datenfehlern führen können, je nach Anwendungsfall kann das recht ungesund sein.

Schönes Beispiel ist das Typeguessing das vorgenommen wird. Auf gut deutsch, anhand der ersten n Zeilen wird der Datentyp bestimmt, und dann ohne rücksicht auf verluste getypecastet. Ist immer schön wenn man z.b. Telefonnummern einliest, 0711 ist halt was anderes als 711. Aber numerisch ists schon

Dein erster Ansatz funktioniert wunderbar.

Das Range Objekt hat eine tostring, die dir die gesammte range als 2 dimensionales Object Array ausgibt.

Das kannst du dann in C# mit 2 Schleifen durchwandern (die inner für die columns der row, die äussere für die rows), und dir in eine anständige Datenstruktur schreiben. Je nach dem was du damit vor hast halt, ich würd aber sagen, dass ne Datatable wohl nicht ganz verkehrt sein dürfte.

Das ganze ist nichtmal wirklich langsamer als per ole db auf die Excel zuzugreifen, ich hat den Eindruck dass es sogar schneller war, die Range in den Speicher zu Jagen, und dann im Ram mit den Daten zu arbeiten, als die odbc Variante.

Ich würd dir aber auf jedenfall empfehlen das ganze als Range einzulesen, und nicht über odbc, wie gesagt, das gibt ne reihe lustige Nebeneffekte wie das führende Nullen weg sind, ein Punkt im Spalten Header hinterher ne Raute ist, gibt da viele Spassige Sachen die dich um den Verstand bringen können.

Per Range eingelesen wird jede Zelle explizit zum String konvertiert, selbst Datumswerte bekommst du auf die Weise sauber zurück, das kannste bei odbc komplett erden.

//Edit :

Wenn du unter Office 2003 arbeitest / die dll verwendest, dann würd ich davon abraten mehr als 20k Zeilen auf einmal einzulesen, da schmeist dir die DLL dann eventuell ne out of memory Exception. Ist aber umschiffbar das Problem, liest halt ne 2003er Excel in ner Schleife ein, nimmst nur ein paar tausend Zeilen am Stück in die Range.

Gruß

Sven

Bearbeitet 15. Februar 2011 von streffin

[Argbeil]

Ich bin der Überzeugung dass der erste Ansatz wesentlich mehr Nachteile bietet, bei der COM Variante fällt mir für diese Anforderung kein einziger Vorteil ein.

COM Marshalling ist zur Laufzeit extrem langsam da der erzeugte Wrapper dynamische Invocation durchführen muss ( siehe hier ) und zudem den Excel Prozess erstmal hochfahren muss. Man hat eine extrem enge Bindung an Excel und in der Vergangenheit gab es da häufig Probleme wie Memory-Leaks die erst durch Service Packs gefixt wurden.

Das Verhalten bei der Typ-Erkennung ist kein besonderes Problem. Da man die Struktur in Excel nicht erzwingen kann und der User auch in eine Währungsspalte "Hallo" schreiben kann, muss man jeden Wert sowieso erstmal als String behandeln und validieren.

Zudem ist das ganze COM/Excel Konstrukt zum reinen auslesen von Daten völlig unnötig. Wenn man Excel-Dateien formatieren, erzeugen, ändern und speichern will macht das vielleicht Sinn - aber auch dafür gibts native .net Excel-File Komponenten.

Der allerwichtigste Grund ist aber: Das System ist nicht Thread-Safe! In einer WebAnwendung würde das ganze ohnehin nicht funktionieren. Wird die Anwendung über Terminal-Services ausgeführt wird sie instabil, evtl. schon wenn sie mehrmals gestartet wird. Microsoft rät übrigens ohnehin ab Office Komponenten zur automatisierung zu verwenden. Quelle

[SilentDemise]

Wie groß ist die Excel Datei?

Einlesen von Daten aus Excel geht auch gut und sehr effizient mittels LINQ