Excel mit ADO auslesen klappt nur sporadisch

[Christian Seehase]

Moin Zusammen,

vorab:
Ich versuche mich gerade in ADO einzuarbeiten, und benötige gerade den Zugriff auf Excel-Daten, so ist es zu diesem "Einstiegsprojekt" für ADO gekommen.

Hierbei muss ich eine Tabelle einer Excel-Datei (mehrere Arbeitsblätter) über ADO auslesen.
Zum testen verwende ich hierfür eine ADOConnection und eine ADOTable.

Delphi-Quellcode:

  AdoConnection1.ConnectionString := 'Provider=Microsoft.Jet.OLEDB.4.0;Data Source='+
                                     OpenDialog1.FileName +
                                     ';Extended Properties="Excel 8.0;HDR=No";Persist Security Info=False;';
  AdoConnection1.Open;

Das funktioniert.

Delphi-Quellcode:

  AdoTable1.Connection := AdoConnection1;
  AdoTable1.TableName  := '[Tabelle1$]';
  AdoTable1.Active     := true;

Soweit ist noch alles gut

Dann wähle ich mir die erste für mich interessante Zeile aus.
  AdoTable1.RecNo := 23; Auch das klappt wie erwartet.
Jetzt gehe ich in einer Schleife durch die Tabelle, um mir die verschiedenen Spalten der Zeilen auszulesen.
Dazu prüfe ich erst einmal, ob die Zelle Inhalt hat
if AdoTable1.FieldByName('F'+IntToStr(i)).Value = null then begin falls ja, wird über den Datentyp die Art der Umwandlung in lesbaren Inhalt bestimmt
case AdoTable1.FieldDefList.FieldDefs[i].DataType of Wird hierbei ein von mir nicht berücksichtiger Typ gefunden, so lasse ich mir den Feldnamen und die Nummer des Typs ausgeben.
Auf diesem Wege konnte ich feststellen, dass die Zellen entweder vom Typ ftDateTime oder vom Typ ftWideString sind.

Das Problem ist:
Nur die erste Spalte (Typ ftWideString), in der Tageskürzel stehen (MO, DI ...), und die dritte (auch ftWideString) in der Zeiten stehen, werden mir korrekt ausgegeben, der Rest der Felder wird mit <leer> gefüllt
In der Datei ist die erste Spalte vom Format "Normal", die zweite hat das Format Datum (tt.mm.jj), und alle restlichen das gleiche Benutzerdefinierte Format ([h]:mm;@), auch die, deren Inhalt in Spalte drei angezeigt werden

Mit D7 und D2006 erhalte ich jeweils das gleiche Ergebnis.

Hat jemand einen Tip für mich, woran das liegen könnte?

Vielen Dank im Voraus.

[alzaimar]

Die ADO-Verbindung zu einer XLS-Tabelle dürfte nur dann gut funktionieren, wenn die XLS-Datei wirklich eine Tabelle ist. Ich denke, komplexe Strukturen, oder nur sporadisch befüllte Zellen überfordern diesen Treiber.

Suche mal hier im Forum nach ähnlichen Problemen (XLS-Datei lesen)...

[Bernhard Geyer]

Excel und ADO ist ein etwas kritisches Paar da hier auch unerwartete Effekte auftreten können wenn mit Formeln und Zellenformatierung gearbeitet wird.

Besser ist es entweder mit einem nativen XLS-Reader zu arbeiten oder den Zugriff über das COM-Objekt von Excel direkt zu machen

[jensw_2000]

Auf deine Frage habe ich leider keine direkte Antwort, weil das Problem bisher nie bei mir aufgetreten ist.
Ich habe dir mal schnell ein kleines "quick and dirty" Spielprojekt zusammengebastelt.
Eventuell kannst du so eine Lösung finden.

[Edit]
Aus Formeln resultierende Daten werden damit übrigens auch sauber ausgelesen.


Schöne Grüße,
Jens

[Christian Seehase]

Moin Zusammen,

erst einmal vielen Dank für die rege Beteiligung
Es beruhigt mich ja, dass ich wohl keinen offensichtlichen Fehler gemacht habe

@alzaimar

Zitat von alzaimar:

Ich denke, komplexe Strukturen, oder nur sporadisch befüllte Zellen überfordern diesen Treiber.

Ich weiss auch nicht, wie der Treiber das intern regelt, aber das wäre für mich zumindest keine Erklärung dafür, das gerade die zweite Spalte, in der ja schlicht ein Datum mit Standardformatierung steht als leer angesehen wird, die erste aber immer korrekt ausgelesen wird.

@Bernhard

Zitat von Bernhard Geyer:

oder den Zugriff über das COM-Objekt von Excel direkt zu machen

Das wollte ich nach Möglichkeit vermeiden, auch wenn ich mal davon ausgehen kann, dass auf den Rechnern, auf denen das Tool laufen soll Excel installiert ist.

@Jens:
Danke für das Demoprojekt.
Da werde ich mal schauen, ob es damit geht, und wo ggf. die Unterschiede zu meiner Variante liegen.

[alzaimar]

Falls Du nicht weiterkommst, helfen nur BIFF-Libraries oder die Komponenten auf den einschlägigen Seiten (Torry, Swiss, DSP etc.)
Meine Erfahrung:
FlexCel: 98% sauber
Axolot: 99.5% sauber (50 Euronen).

Den Rest hab ich dann nicht mehr getestet.

[Christian Seehase]

Moin Zusammen,

da der Zugriff auf die Excel-Dateien, die ich auslesen muss sich, sich wohl leider mit ADO nicht so hinzubekommen ist (leider ) muss ich es, wohl oder übel, mit den COM-Server machen.

Durch die Verwendung verschiedener Test-Dateien konnte ich zwar herausbekommen, dass die Problematik System hat, aber die Erzeugung der Quelldateien anzupassen, damit der Zugriff über ADO wie gewünscht funktioniert, wäre dann doch etwas zuviel des Guten

@alzaimar:
Danke für die Tips.
Dadurch bin ich auf eine recht umfangreiche Dokumentation des BIFF-Formates gestossen (von OpenOffice.org), die ich mir bei Gelegenheit mal näher ansehen werde. Immerhin deckt die auch schon BIFF8X mit ab (Excel 2003).

[Bernhard Geyer]

Zitat von alzaimar:

FlexCel: 98% sauber

Auch schon die kostenpflichtige neueren Versionen bei TMS getested?

[alzaimar]

Kleinigkeit zum Schluss (das Kleingedruckte):
Die offizielle BIFF-Doku von Microsoft hat einen Haken (der eventuell bei der von OpenOffice.org schon korrigiert ist): Sie ist fehlerhaft!

Wenn man ein Tool anhand der MS-BIFF-Doku bastelt, fällt man auf die Schnauze! EXCEL selbst hält sich nicht an die Dokumentation und friemelt irgendwie die XLS-Dateien hin. Na ja, wirst ja sehen.

@Bernhard: Ich habe eine Killer-XLS-Datei, an der sich bisher alle (bis auf axolot) die Zähne ausgebissen haben. Aber meine Tests sind schon 2-3 Jahre alt. Da ich mit XLSReadWriteII zufrieden bin, hab ich mich nicht weiter drum gekümmert. Aber eins ist klar: Die TMS/FlexCel- Komponenten sind alleine schon vom Design und Konzept her allererste Sahne!

[Bernhard Geyer]

Zitat von alzaimar:

Kleinigkeit zum Schluss (das Kleingedruckte):
Die offizielle BIFF-Doku von Microsoft hat einen Haken (der eventuell bei der von OpenOffice.org schon korrigiert ist): Sie ist fehlerhaft!

Ein Schelm wer böses dabei denkt ....
Mußt MS evtl. diese Schnittstelle aufgrund einer Monopol-Klage herausrücken?

Passt auch zu den Fehlern in der IE-TLB. Dort gibt es Funktionen die bekanntermaßen (über zig-Versionen) nicht funktionieren und an vollkommen unerwarteten Stellen beschrieben werden das dieser Fehler so halt ist und auch nichts geändert wird.