Daten aus Excel einlesen
Nico Wessels
wenn ich eine Excel-Datei einlesen möchte, kann ich das ja über die
COM-Schnittstelle machen. Dazu muss ich die "Microsoft Excel 12.0 Object
Library" in meinem Projekt referenzieren.
Wenn ich das richtig verstehe, referenziere ich hiermit eine spezielle
Version dieser DLL. Wenn jemand ein altes Excel drauf hat, wird das bei
ihm nicht laufen, richtig? Eventuell auch nicht, wenn er ein neueres
Excel drauf hat, oder? Kann ich diese DLL in einem Setup eigentlich
mitliefern, oder geht das nicht?
Selbst wenn ich das Einlesen über COM realisiere, sehe ich noch so ein
paar Problem: evtl. schlechte Performance, evtl. Probleme wenn dasselbe
Dokument im Hintergrund bearbeitet wird?
Ich mich, was es sonst noch für Möglichkeiten gibt und was sich
empfiehlt. Ich habe gesehen, dass man eine Excel-Datei auch im CSV oder
XML-Format speichern kann. Wäre das was?
Bei CSV sehe ich beim Parsen Probleme, da Excel hier ja seine Regeln
beim Export hat (z.B. Codierung des ";", wenn dies als Text in einer
Zelle geschrieben stehe und ";" als Trenner im CSV verwendet wird).
Das XML-Format sieht zunächst recht einfach aus. Allerdings kenne ich
keine Fallstricke, wenn man dies einlesen will. Kann mir hier jemand
Auskunft geben, ob diese Variante zu empfehlen ist, oder nicht?
Peter Fleischer
news:87ff8q...@mid.individual.net...
> ...
> wenn ich eine Excel-Datei einlesen möchte, kann ich das ja über die
> COM-Schnittstelle machen. Dazu muss ich die "Microsoft Excel 12.0 Object
> Library" in meinem Projekt referenzieren.
Hi Nico,
alternativ ist auch die Nutzung der Jet und damit ein datenbanktypischer
Zugriff möglich. Ein installiertes Excel ist dazu nicht erforderlich.
Problematisch in dieser Version ist nur, wenn die Daten nicht "sauber" sind,
z.B., wenn in einer Datumsspalte solche Einträge enthalten sind wie "11.
KW", "sofort", "IV. Quartal".
--
Viele Gruesse
Peter
Frank Dzaebel
> wenn ich eine Excel-Datei einlesen möchte, kann ich das ja über die
> COM-Schnittstelle machen. Dazu muss ich die "Microsoft Excel 12.0 Object
> Library" in meinem Projekt referenzieren.
ok, müssen tust Du das ja nicht mehr, da man auch
ab .NET 4.0 über Type Embedding gehen kann.
Dadurch werden ggf. nur benutzte Typen überhaupt
eingebettet und u.a. die Gesamtgröße kleiner. (->NoPIA)
> Wenn ich das richtig verstehe, referenziere ich hiermit eine spezielle
> Version dieser DLL.
im Prinzip ja.
Aber man kann auch COM-Aufrufe machen, die
nahezu Versions-unabhängig sind, indem man
deren tiefste zu supportende Signatur (im IA) benutzt.
Das ist auch die von mir oft empfohlene Implementations-Art.
>Wenn jemand ein altes Excel drauf hat, wird das bei ihm nicht laufen,
>richtig? Eventuell auch nicht, wenn er ein neueres Excel drauf hat, oder?
>Kann ich diese DLL in einem Setup eigentlich mitliefern, oder geht das
>nicht?
die IA kannst Du mitliefern. Früher hat man halt gern
auf die PIA-Downloads von MS in den Setup-Anforderungen
verwiesen.
> Selbst wenn ich das Einlesen über COM realisiere, sehe ich noch so ein
> paar Problem: evtl. schlechte Performance, evtl. Probleme wenn dasselbe
> Dokument im Hintergrund bearbeitet wird?
nicht unbedingt, das kommt auf das Szenario und Implementation
an. Viele Dinge, wie etwa gleichzeitiges Bearbeiten, etc. beherrscht
Excel ja auch out of the box (auch COM) mit entsprechenden
Einstellungen.
> Ich mich, was es sonst noch für Möglichkeiten gibt und was sich
> empfiehlt. Ich habe gesehen, dass man eine Excel-Datei auch im CSV oder
> XML-Format speichern kann. Wäre das was?
Sehr viele!
Das neue OData - also über Datenservices - über reine
Datenquellen gebundene Darstellungen, dabei können
die Datenquellen nahezu beliebig sein - oder WebServices und und.
Also könntest Du eine externe für die vielleicht performant
oder einfach anzusprechende Datenquelle (auch Datei) benutzen und Excel
einfach diese referenzeren lassen um so seine Werte, Graphen
etc. darstellen zu lassen. Allgemein dazu (u.a.) vielleicht:
[Daten in Office-Lösungen]
http://msdn.microsoft.com/de-de/library/xx069ybh.aspx
> Bei CSV sehe ich beim Parsen Probleme, da Excel hier ja seine Regeln
> beim Export hat (z.B. Codierung des ";", wenn dies als Text in einer
> Zelle geschrieben stehe und ";" als Trenner im CSV verwendet wird).
Na, da gibt es u.a. Möglichkeiten über die Schema.ini, aber
im Prinzip gibt es auch die OleDb-Möglichkeit ohne Excel-
Installation etc. ...
[Importing CSV file into Database with Schema.ini - Creating Schema.ini
file dynamically or at run-time to import CSV file data in Asp.Net]
http://www.aspdotnetcodes.com/Importing_CSV_Database_Schema.ini.aspx
[OLE DB-Anbieter für Jet]
http://msdn.microsoft.com/de-de/library/ms175866.aspx
> Das XML-Format sieht zunächst recht einfach aus. Allerdings kenne ich
> keine Fallstricke, wenn man dies einlesen will. Kann mir hier jemand
> Auskunft geben, ob diese Variante zu empfehlen ist, oder nicht?
Das kommt wirklich sehr auf Deine Hauptanforderungen an ..
Performance, Menge an Daten, ob gemeinsame Datenquellen
erlaubt sein sollen, und und.
Auch wieder Versions-abhängig ... Die Endung xlsx wurde ja
ab Excel 2007 letztlich eh schon für gezipptes XML (-> OpenXML)
benutzt.
In .NET ist Excel da über den Packaging Namespace "erreichbar".
Oder Dinge wie:
[.NET Excel Wrapper - Read, Write, Edit & Automate Excel Files in .NET
with ease]
http://excelwrapperdotnet.codeplex.com/
Da spielt auch viel "Geschmack" und Anforderungs-Erfüllung mit.
Das kann man von außen schlecht pro oder Contra empfehlen.
ciao Frank
--
Dipl.Inf. Frank Dzaebel [MCP/MVP C#]
http://Dzaebel.NET
Christian Treffler
> wenn ich eine Excel-Datei einlesen möchte, kann ich das ja über die
> COM-Schnittstelle machen. Dazu muss ich die "Microsoft Excel 12.0 Object
> Library" in meinem Projekt referenzieren.
>
> Wenn ich das richtig verstehe, referenziere ich hiermit eine spezielle
> Version dieser DLL. Wenn jemand ein altes Excel drauf hat, wird das bei
> ihm nicht laufen, richtig?
Die Befürchtung hatte ich auch. Wir hatten bisher Office 2003 in der
Firma und ich hatte die Version 11 der DLL referenziert. Als dann die
ersten Rechner auf Office 2007 umgestellt wurden, habe ich mein Programm
gleich auf deren Rechner getestet: Kein Problem.
Inzwischen habe ich einen neuen Rechner und gleich mal neu kompiliert
mit Referenz auf die Version 12 der DLL. Dann das ganze auf dem alten
Rechner getestet: Kein Problem.
> Kann ich diese DLL in einem Setup eigentlich
> mitliefern, oder geht das nicht?
In den Eigenschaften Deiner Referenz auf die DLL gibt's eine Eigenschaft
"Local". Die stellst Du auf True, dann wird die DLL in den Folder der
*.exe kopiert. So habe ich's nach dem Umstellen auf Office 2007 gemacht.
Ob es auch ohne diese Umstellung gegangen wäre, weiß ich nicht.
CU,
Christian
Frank Dzaebel
> Die Befürchtung hatte ich auch. Wir hatten bisher Office 2003 in der
> Firma und ich hatte die Version 11 der DLL referenziert. Als dann die
> ersten Rechner auf Office 2007 umgestellt wurden, habe ich mein Programm
> gleich auf deren Rechner getestet: Kein Problem.
Nur "Testen" ;-) besser ist da ggf. ~Wissen, denn
Office 2003 und 2007 sind da zwei Spezialkandidaten, denn hier
funktioniert das über "publisher policy assemblies". Diese
führen einen Rebind-Vorgang auf die aktuellere Methode bei jedem
COM-Call aus.
Code, der gegen die Office 2003 PIAs entwickelt wurde
läuft auch unter Office 2007 (2003 Code ist *aufwärtskompatibel*) -
also ggf. ohne Neukompilierung oder Code-Änderungen [MS].
Aber Achtung, die Gegenrichtung ist *nicht* von MS supportet:
http://groups.google.com/group/microsoft.public.office.developer.automation/msg/5a474198ea727ac8
http://groups.google.com/group/microsoft.public.de.german.entwickler.dotnet.csharp/msg/275d2b2bf4f67d84
(und kann u.a. zu Crashes führen)
Weiterhin Achtung, die oben geschilderten Dinge gelten zunächst
eben nur bzgl. dieser beiden Versionen 2003 und 2007.
Für Office XP und Office 2003 gilt so etwas zum Beispiel nicht.
Für Nico kommen ja ggf. auch andere Versionen in Betracht, so
er zumindest die Versionen nicht auf "> 2003" einschränkte.
Obwohl funktionsfähig, gibt es natürlich trotzdem oft Dinge,
die in der neuren Office-Version schlicht anders implementiert werden
"sollten" - etwa im Bereich UI:
http://blogs.msdn.com/b/jensenh/archive/2006/11/10/the-office-2007-ui-bible.aspx
> In den Eigenschaften Deiner Referenz auf die DLL gibt's eine Eigenschaft
> "Local". Die stellst Du auf True, dann wird die DLL in den Folder der
> *.exe kopiert. So habe ich's nach dem Umstellen auf Office 2007 gemacht.
> Ob es auch ohne diese Umstellung gegangen wäre, weiß ich nicht.
wie ich schon in meinem ersten Posting geschrieben habe,
es geht in C# 4.0 auch Type Embedding. Da es nicht klar geworden
zu sein scheint, doch ein paar Links dazu:
[Exemplarische Vorgehensweise: Einbetten von Typinformationen aus
Microsoft Office-Assemblys (C# und Visual Basic)]
http://msdn.microsoft.com/de-de/library/ee317478.aspx
(siehe oben auch:
"So erstellen Sie eine Anwendung, die mit mehreren
Versionen von Microsoft Office kompatibel ist")
[Typäquivalenz und eingebettete Interop-Typen]
http://msdn.microsoft.com/de-de/library/dd997297.aspx
In dieser Lösungs-Art bettet man für jede Office-Version
die benötigten (eben nicht die ganze PIA) Office-COM-Typen ein.
___________
Oft implementiert man aber einfach gegen die tiefste zu
supportende IA (/ PIA). Allerdings ist COM-Interop eben nur
eine mögliche Art, Nicos Fragen gingen IMHO ja in Richtung Wahl
der Technologie/ Vorgehen. Aber dazu wurde ja in meinem
ersten Posting schon einige Dinge erläutert.
Christian Treffler
> Nur "Testen" ;-) besser ist da ggf. ~Wissen
Gottseidank bin ich der glorreichen Lage, ein Programm für einen sehr
eingeschränkten Nutzerkreis innerhalb der Firma bereitzustellen. Da die
Software-Installation auf den einzelnen Rechnern auch sehr einheitlich
ist, reicht Testen hier völlig aus.
CU,
Christian
Frank Dzaebel
>> Nur "Testen" ;-) besser ist da ggf. ~Wissen
>
> Gottseidank bin ich der glorreichen Lage, ein Programm für einen sehr
> eingeschränkten Nutzerkreis innerhalb der Firma bereitzustellen. Da die
> Software-Installation auf den einzelnen Rechnern auch sehr einheitlich
> ist, reicht Testen hier völlig aus.
das mag vielleicht sogar in Deinem Fall zutreffen.
Aber hier geht es ja um Nicos Fall.
Nico Wessels
>> wenn ich eine Excel-Datei einlesen möchte, kann ich das ja über die
>> COM-Schnittstelle machen. Dazu muss ich die "Microsoft Excel 12.0
>> Object Library" in meinem Projekt referenzieren.
>
> ok, müssen tust Du das ja nicht mehr, da man auch
> ab .NET 4.0 über Type Embedding gehen kann.
> Dadurch werden ggf. nur benutzte Typen überhaupt
> eingebettet und u.a. die Gesamtgröße kleiner. (->NoPIA)
Es wird noch das Visual Studio 2005 eingesetzt und übersetzt für die
entsprechende .NET Version.
>> Wenn ich das richtig verstehe, referenziere ich hiermit eine spezielle
>> Version dieser DLL.
>
> im Prinzip ja.
> Aber man kann auch COM-Aufrufe machen, die
> nahezu Versions-unabhängig sind, indem man
> deren tiefste zu supportende Signatur (im IA) benutzt.
> Das ist auch die von mir oft empfohlene Implementations-Art.
Verstehe nur Bahnhof. Hast Du ein Beispiel, wie das aussehen könnte?
>> Wenn jemand ein altes Excel drauf hat, wird das bei ihm nicht laufen,
>> richtig? Eventuell auch nicht, wenn er ein neueres Excel drauf hat,
>> oder? Kann ich diese DLL in einem Setup eigentlich mitliefern, oder
>> geht das nicht?
>
> die IA kannst Du mitliefern. Früher hat man halt gern
> auf die PIA-Downloads von MS in den Setup-Anforderungen
> verwiesen.
Wo gibt es diese Interop Assembly?
>> Das XML-Format sieht zunächst recht einfach aus. Allerdings kenne ich
>> keine Fallstricke, wenn man dies einlesen will. Kann mir hier jemand
>> Auskunft geben, ob diese Variante zu empfehlen ist, oder nicht?
>
> Das kommt wirklich sehr auf Deine Hauptanforderungen an ..
> Performance, Menge an Daten, ob gemeinsame Datenquellen
> erlaubt sein sollen, und und.
Noch etwas mehr Hintergrund: Es soll in einem Programm eine Möglichkeit
geben, Daten aus verschiedenen Excel-Tabelle einzulesen und diese dann
in der angebundenen DB abzulegen. In den Excel-Files stehen
möglicherweise ein paar Tausend Zeilen und etwa 2 Spalten, die aber beim
Import nicht alle Relevant sind und auch nicht in der Reihenfolge in die
DB übernommen werden sollen. Es muss also ein Mapping von den Spalten
aus Excel zu den Spalten der DB-Tabelle geben. Im Programm selber wird
es dann einen Menü-Eintrag geben, über den man die zu importierende
Excel-Tabelle auswählen kann.
Grafiken gibt es in den Excel-Tabellen nicht.
Die Lösung über COM wird auch nicht so ganz bevorzugt, da im Hintergrund
wohl auch immer ein komplettes Excel geöffnet wird und die Verarbeitung
wohl auch nicht so ganz performant ist. Bedenken kamen auch auf, was
passiert, wenn z.B. im Hintergrund die Excel-Tabelle bereits geöffnet
ist und ob das beim Verarbeiten über die C#-Anwendung problematisch
werden könnte. Zudem wurden dann Bedenken geäussert, falls irgendwann
mal neuere Excel-Versionen auf die Rechner installiert werden oder das
C#-Programm auf Rechnern gestartet wird, die gar kein Excel haben. Auch
hier muss der Import funktionieren.
Ebenso werden generell auch Open-Source-Lösungen eher kritisch angesehen
wegen Lizenzrechtlicher Bedenken bzw. Forderung den eigenen Quellcode zu
öffnen.
> Da spielt auch viel "Geschmack" und Anforderungs-Erfüllung mit.
> Das kann man von außen schlecht pro oder Contra empfehlen.
Daher nochmal obige Zusatzinformationen.
Nico Wessels
> Die Befürchtung hatte ich auch. Wir hatten bisher Office 2003 in der
> Firma und ich hatte die Version 11 der DLL referenziert. Als dann die
> ersten Rechner auf Office 2007 umgestellt wurden, habe ich mein Programm
> gleich auf deren Rechner getestet: Kein Problem.
> Inzwischen habe ich einen neuen Rechner und gleich mal neu kompiliert
> mit Referenz auf die Version 12 der DLL. Dann das ganze auf dem alten
> Rechner getestet: Kein Problem.
>
>> Kann ich diese DLL in einem Setup eigentlich
>> mitliefern, oder geht das nicht?
>
> In den Eigenschaften Deiner Referenz auf die DLL gibt's eine Eigenschaft
> "Local". Die stellst Du auf True, dann wird die DLL in den Folder der
> *.exe kopiert. So habe ich's nach dem Umstellen auf Office 2007 gemacht.
> Ob es auch ohne diese Umstellung gegangen wäre, weiß ich nicht.
Aber gebe ich dann nicht die DLL mit raus und laufe in Lizenz-Probleme?
Ich mein, ich hätte nichts dagegeben, die DLL lokal einzubinden und dann
mitzuliefern. Dann weiß man wenigstens, dass es mit dieser Version
funktioniert.
Fraglich ist hier aber für mich auch noch, ob das dann auf Rechnern ohne
Excel überhaupt noch funktioniert. Möglicherweise bestehen noch
Abhängigkeiten zu anderen DLLs die mit Excel kommen.
Nico Wessels
>>> Nur "Testen" ;-) besser ist da ggf. ~Wissen
>>
>> Gottseidank bin ich der glorreichen Lage, ein Programm für einen sehr
>> eingeschränkten Nutzerkreis innerhalb der Firma bereitzustellen. Da die
>> Software-Installation auf den einzelnen Rechnern auch sehr einheitlich
>> ist, reicht Testen hier völlig aus.
>
> das mag vielleicht sogar in Deinem Fall zutreffen.
> Aber hier geht es ja um Nicos Fall.
Ich kenne das mit "Programmieren für einen eingeschränkten Nutzerkreis
zu gut". Plötzlich ändert sich was an der Installation, oder plötzlich
kommen z.B. Rechner ohne installiertes Office zum Einsatz und dann steht
der Boss da und sagt, warum tut Dein Programm denn nicht mehr? Dann
sagst Du, dass hier eben zu den damaligen Verhältnisse implementiert
wurde und sofort kommt die kritische Rückfrage, ja hätte man das nicht
auch anders machen können, jetzt kostet mich die Umstellung wieder xxx
EUR. ;-)
Christian Treffler
> Fraglich ist hier aber f�r mich auch noch, ob das dann auf Rechnern ohne
> Excel �berhaupt noch funktioniert.
So, wie ich das sehe, ist ein installiertes Excel Voraussetzung, damit
das l�uft. In meiner Applikation wird Excel gestartet und gesteuert.
CU,
Christian
Frank Dzaebel
>>> wenn ich eine Excel-Datei einlesen möchte, kann ich das ja über die
>>> COM-Schnittstelle machen. Dazu muss ich die "Microsoft Excel 12.0
>>> Object Library" in meinem Projekt referenzieren.
>>
>> ok, müssen tust Du das ja nicht mehr, da man auch
>> ab .NET 4.0 über Type Embedding gehen kann.
>> Dadurch werden ggf. nur benutzte Typen überhaupt
>> eingebettet und u.a. die Gesamtgröße kleiner. (->NoPIA)
>
> Es wird noch das Visual Studio 2005 eingesetzt und übersetzt für die
> entsprechende .NET Version.
dann scheidet Type Embedding zunächst für Deine Anforderungen
aus, sollte man aber im Blick behalten.
BTW: unbedingt langsam auf 2010 wechseln - gibt im Prinzip
nur Vorteile, wenn man nicht gerade alte Mobile-Apps pflegen muss.
>>> Wenn ich das richtig verstehe, referenziere ich hiermit eine spezielle
>>> Version dieser DLL.
>>
>> im Prinzip ja.
>> Aber man kann auch COM-Aufrufe machen, die
>> nahezu Versions-unabhängig sind, indem man
>> deren tiefste zu supportende Signatur (im IA) benutzt.
>> Das ist auch die von mir oft empfohlene Implementations-Art.
>
> Verstehe nur Bahnhof. Hast Du ein Beispiel, wie das aussehen könnte?
ok. IA bedeutet Interop Assembly. Das ist die Assembly, die
durch die Einbindung der "Microsoft Excel XX Object Library"
(über Verweise) eine "Microsoft.Office.Interop.Excel.dll" erzeugt,
die Du zum Beispiel über Eigenschaften auf "Lokale Kopie"=true
festlegen kannst, und so zur Verfügung hast.
Ich hatte hier mal ein Beispiel für Word gemacht:
[Späte Bindung bei C# am Beispiel Word]
http://dzaebel.net/LatebindWord.htm
Die "tiefste zu supportende IA" ist entsprechend die
Version der Interop Assembly, dessen entsprechende Office
Version Deine Kunden als unterste Version haben.
Also sagen wir mal Office 97 - obwohl ich mal annehme,
es ist wahrscheinlich Office XP o.ä..
Nun solltest Du bei der Entwicklung entweder solche
latebind COM Konstrukte/Aufrufe (wie in meinem Artikel) nehmen,
oder eine Mischung, die dann eben aufwärtskompatibel sind (neben anderen).
Es kommen quasi höchstens Parameter hinzu, was aber eben kompatibel ist.
Und da sind wir bei der (Typ) Signatur ... das sind eben die Namen
von Parametern, Typen und Rückgabewerten, die den Typ eindeutig machen.
Nur einige wenige in Vor-Versionen als deprecated gekennzeichneten
Member können in der Folge-"Folge"-Version ggf. nicht mehr da
sein, aber das ist sehr selten.
[oder eben bei .NET 4.0 eben enorme Vereinfachungen "geniessen").
Es gibt andere Varianten der Implementierungs-Strategien
für versionsunabhängiges Schreiben von managed Office-Apps.
>>> Wenn jemand ein altes Excel drauf hat, wird das bei ihm nicht laufen,
>>> richtig? Eventuell auch nicht, wenn er ein neueres Excel drauf hat,
>>> oder? Kann ich diese DLL in einem Setup eigentlich mitliefern, oder
>>> geht das nicht?
>>
>> die IA kannst Du mitliefern. Früher hat man halt gern
>> auf die PIA-Downloads von MS in den Setup-Anforderungen
>> verwiesen.
>
> Wo gibt es diese Interop Assembly?
bei Dir - siehe Erläuterung oben.
BTW: normal wird aber die PIA (also die primäre Interop
Assembly) des Herstellers (hier MS) als best practice angesehen.
> Noch etwas mehr Hintergrund: Es soll in einem Programm eine Möglichkeit
> geben, Daten aus verschiedenen Excel-Tabelle einzulesen und diese dann
> in der angebundenen DB abzulegen.
Aha!
Das war ja eine Variante, die ich erwähnte.
Da braucht Excel ggf. wirklich nicht installiert sein.
Denn in Excel definierst Du einfach die DB-Verbindung
und wählst dann halt deine Datenquelle aus. In der
Implementierung greifst Du dann einfach direkt über
die managed DB-Provider von .NET auf die Datemquelle
zu. Oder eben direkt über .NET XML-Methoden (o.ä.) .
Oder vielleicht (oft extremst einfach) ein DataSet nehmen.
DataSet.WriteXml() und fertig :-)
> Die Lösung über COM wird auch nicht so ganz bevorzugt, da im Hintergrund
> wohl auch immer ein komplettes Excel geöffnet wird und die Verarbeitung
> wohl auch nicht so ganz performant ist.
Das ist verständlich und das würde ich dann auch nicht nehmen,
wenn tatsächlich die Anforderungen so "günstig" pro
der DB/XML-Provider-Technik liegen.
> Ebenso werden generell auch Open-Source-Lösungen eher kritisch angesehen
persönlich versuche ich die auch gern zu vermeiden, wenn
man selber einfache Lösungen herstellen kann.
Nico Wessels
>> Noch etwas mehr Hintergrund: Es soll in einem Programm eine
>> Möglichkeit geben, Daten aus verschiedenen Excel-Tabelle einzulesen
>> und diese dann in der angebundenen DB abzulegen.
>
> Aha!
> Das war ja eine Variante, die ich erwähnte.
> Da braucht Excel ggf. wirklich nicht installiert sein.
> Denn in Excel definierst Du einfach die DB-Verbindung
> und wählst dann halt deine Datenquelle aus. In der
> Implementierung greifst Du dann einfach direkt über
> die managed DB-Provider von .NET auf die Datemquelle
> zu. Oder eben direkt über .NET XML-Methoden (o.ä.) .
> Oder vielleicht (oft extremst einfach) ein DataSet nehmen.
> DataSet.WriteXml() und fertig :-)
Da liegt aber das Excel-File vor und ich erstelle dann eben einfach die
Verbindung zu dieser Datenquelle aus meinem C# Programm heraus.
Was hälst Du denn von der Variante, die Leute das File einfach in XML
speichern zu lassen und dieses dann zu parsen? Mit den C# XML-Methoden
würde das natürlich auch recht einfach gehen. Hattest Du das ohnehin
damit gemeint?
Frank Dzaebel
>> Das war ja eine Variante, die ich erwähnte.
>> Da braucht Excel ggf. wirklich nicht installiert sein.
>> Denn in Excel definierst Du einfach die DB-Verbindung
>> und wählst dann halt deine Datenquelle aus. In der
>> Implementierung greifst Du dann einfach direkt über
>> die managed DB-Provider von .NET auf die Datenquelle
>> zu. Oder eben direkt über .NET XML-Methoden (o.ä.) .
>> Oder vielleicht (oft extremst einfach) ein DataSet nehmen.
>> DataSet.WriteXml() und fertig :-)
> Was hälst Du denn von der Variante, die Leute das File einfach in XML
> speichern zu lassen und dieses dann zu parsen? Mit den C# XML-Methoden
> würde das natürlich auch recht einfach gehen. Hattest Du das ohnehin
> damit gemeint?
ja, genau das hatte ich gemeint - wobei Du eben
für Excel sogar im C# Code einfach ein DataSet nehmen kannst
und am Ende (zum Beispiel) mit ds.WriteXml("daten.xml")
dieses XML auf einfachste Weise persistieren kannst, quasi
auch ohne XML Aufrufe, nur mit Manipulation der Werten
des DataTables. Aber gut - Linq to XML wäre ja ähnlich einfach.
XML als Format ist zum Teil etwas zu Speicher-hungrig, aber
in Deinem Fall, wo es rund 1000 Datensätze sind, wohl ok.
Nun solltest Du am Ende ggf. noch gewährleisten, dass beim
Öffnen der Arbeitsmappe die Daten aus der ggf. geänderten
XML Datei aktualisiert werden:
[Aktualisieren verbundener (importierter) Daten - Excel - Microsoft
Office]
http://office.microsoft.com/de-de/excel-help/aktualisieren-verbundener-importierter-daten-HP010087045.aspx
(siehe: Automatisches Aktualisieren von Daten beim Öffnen der
Arbeitsmappe)
Nico Wessels
>> Was h�lst Du denn von der Variante, die Leute das File einfach in XML
>> speichern zu lassen und dieses dann zu parsen? Mit den C# XML-Methoden
>> w�rde das nat�rlich auch recht einfach gehen. Hattest Du das ohnehin
>> damit gemeint?
>
> ja, genau das hatte ich gemeint - wobei Du eben
> f�r Excel sogar im C# Code einfach ein DataSet nehmen kannst
> und am Ende (zum Beispiel) mit ds.WriteXml("daten.xml")
> dieses XML auf einfachste Weise persistieren kannst, quasi
> auch ohne XML Aufrufe, nur mit Manipulation der Werten
> des DataTables. Aber gut - Linq to XML w�re ja �hnlich einfach.
> XML als Format ist zum Teil etwas zu Speicher-hungrig, aber
> in Deinem Fall, wo es rund 1000 Datens�tze sind, wohl ok.
Wobei hier noch eine 0 fehlt -> 10.000
Wird aber auch noch in Ordnung sein, denke ich.
> Nun solltest Du am Ende ggf. noch gew�hrleisten, dass beim
> �ffnen der Arbeitsmappe die Daten aus der ggf. ge�nderten
> XML Datei aktualisiert werden:
>
> [Aktualisieren verbundener (importierter) Daten - Excel - Microsoft Office]
> http://office.microsoft.com/de-de/excel-help/aktualisieren-verbundener-importierter-daten-HP010087045.aspx
>
> (siehe: Automatisches Aktualisieren von Daten beim �ffnen der Arbeitsmappe)
Danke f�r die Tipps!
Frank Dzaebel
>> in Deinem Fall, wo es rund 1000 Datens�tze sind, wohl ok.
>
> Wobei hier noch eine 0 fehlt -> 10.000
> Wird aber auch noch in Ordnung sein, denke ich.
DataSet.WriteXml() hat zum Beispiel bei einem
heute ~durchschnittlichen Rechner etwa folgende
Performance (mal f�r strings mit durchschnittlich 8
Zeichen L�nge) :
Spalten:10, Zeilen:1000, Zeit: ~33 Millisekunden
Spalten:10, Zeilen:10000, Zeit: ~330 Millisekunden
Spalten:20, Zeilen:10000, Zeit: ~660 Millisekunden
Spalten:100, Zeilen:10000, Zeit: ~3,3 Sekunden
Das DataSet.ReadXml() dann aber etwa 3,5 mal
soviel wie das Schreiben.
> Danke f�r die Tipps!
gern.
Nico Wessels
>>> in Deinem Fall, wo es rund 1000 Datens�tze sind, wohl ok.
>>
>> Wobei hier noch eine 0 fehlt -> 10.000
>> Wird aber auch noch in Ordnung sein, denke ich.
>
> DataSet.WriteXml() hat zum Beispiel bei einem
> heute ~durchschnittlichen Rechner etwa folgende
> Performance (mal f�r strings mit durchschnittlich 8
> Zeichen L�nge) :
>
> Spalten:10, Zeilen:1000, Zeit: ~33 Millisekunden
> Spalten:10, Zeilen:10000, Zeit: ~330 Millisekunden
> Spalten:20, Zeilen:10000, Zeit: ~660 Millisekunden
> Spalten:100, Zeilen:10000, Zeit: ~3,3 Sekunden
>
> Das DataSet.ReadXml() dann aber etwa 3,5 mal
> soviel wie das Schreiben.
Dann l�uft das durch wie fl�ssige Butter!
Die Implementierung mit JET und OleDB l�uft bei mir auch ganz gut. Das
F�llen eines DataSet und Mergen der DataTable mit der bereits
vorhandenen DB verh�lt sich ganz gut und ist kaum f�r den User bemerkbar.