Fehler "Ungültige Pufferlänge" bei TADOTable.Post

[Codehunter]

Hallo!

Ich habe zwei Excel-Dateien (XLS). Für beide habe ich mir in der ODBC-Verwaltung je einen Benutzer-DSN angelegt. In meinem Projekt habe ich für jede der beiden DSN eine ADOConnection, eine ADOTable, eine DataSource und ein DBGrid angelegt. Die ADOConnections sind auf ihren jeweiligen DSN konfiguriert, alles ist mit einander verbunden und Connected bzw. Active sind jeweils TRUE.

Die beiden Grids zeigen auch richtigerweise alle Daten aus den beiden Excel-Tabellen an. Ich kann auch per ADOTable.First/Next durch die Datenmenge navigieren, die Datenmenge per .Edit in den Schreibmodus versetzen und per AsInteger:= einen Wert zuweisen.

Nur wenn ich dann nach dem jeweiligen AsInteger:= ein ADOTable.Post durchführe, erhalte ich eine Fehlermeldung vom ODBC-Excel-Driver (siehe Anhang)

Wo mache ich da jetzt den Fehler?

Grüße
Cody

[sx2008]

Der ODBC-Treiber von Excel hat deutliche Schwachpunkte; schlieslich ist er aus heutiger Sicht auch schon "steinalt".
Man sollte eher den OLE-DB Provider benützen. Hier der Connectionstring:

Code:

Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\MyExcel.xls; Extended Properties="Excel 8.0;HDR=Yes;IMEX=0"

Das HDR=YES bedeutet, dass die 1. Zeile die Feldnamen enthält.

[Codehunter]

Danke, das hat schon mal sehr viel gebracht. Meine Routine läuft jetzt schon mal eine ganze Weile und aktualisiert dann auch diverse Datensätze. Wenn Excel (Das Programm) gleichzeitig offen ist kann ich die Aktualisierungen sozusagen auch "live" sehen, wenn auch nur seeeehr langsam.

Nach 509 Datensätzen bricht die ganze Routine dann mit einer weiteren Fehlermeldung ab (siehe Anhang). Der Datensatz bei dem meine Routine aussteigt unterscheidet sich inhaltlich nicht von den Datensätzen die vorher problemlos verarbeitet wurden.

[jobo]

Zitat:

Zitat von Codehunter (Beitrag 1204451)

Der Datensatz bei dem meine Routine aussteigt unterscheidet sich inhaltlich nicht von den Datensätzen die vorher problemlos verarbeitet wurden.

Nun, er sollte sich aber mindestens über einen Schlüsselwert unterscheiden. Was man bei Excel sieht, was tatsächlich drinsteht, wie es vom Treiber interpretiert wird, sind leider sehr unterschiedliche Dinge. Dafür gibt es halt im Normalfall Datenbanken, Excel ist keine und Du wirst immer solchen Problemen nachjagen. Je mehr Benutzer in den Daten editieren, desto mehr solcher Probleme.

[Bernhard Geyer]

Ich würde Excel direkt über die Automatisierungsschnittstelle von Excel bedienen oder über eine native Excel Read/Write-Komponente.
Über OLE DB handelt man sich eigentlich nur Probleme ein auch wenn es so schön aussieht.

Auch ist der Provider "Microsoft.Jet.OLEDB.4.0" veraltet und wird irgendwann nicht mehr bei der Standardauslieferung dabei sein (Im Embedded-Umfeld ist er schon öfters nich mehr vorhanden)

[blondervolker]

Und Access 2007 oder 2010?
Nutze ich auch und geht gut.:-D

[Bernhard Geyer]

Zitat:

Zitat von blondervolker (Beitrag 1204497)

Und Access 2007 oder 2010?

Hat aber einen anderen Provider (Provider=Microsoft.ACE.OLEDB.12.0) und ist nur drauf wenn man auch Access installiert hat.
Und eine Lösung zu implementieren die auf andere MS-Anwendungen (und damit extra Lizenzkosten verursacht) angewiesen ist, ist m. E. ungünstig.

[Codehunter]

Erstmal danke soweit für eure Antworten. Das Indexproblem hat sich dann recht einfach lösen lassen indem ich eine Spalte in der Tabelle angelegt habe und jede Zeile per "=Zeile()" zugewiesen habe (im Excel-Programm). Diese Spalte habe ich dann bei TADOTable.MasterFields angegeben, brachte aber keinen Mehrwert. Scheinbar bastelt sich der ODBC-Treiber den Tabellenindex selbst zurecht solange er irgendwas finden kann was die Zeilen/Datensätze eindeutig macht. Mit der numerierten Spalte war jedenfalls der besagte zweite Fehler auch weg.

Nur um keine Missverständnisse aufkommen zu lassen: Ich baue keine Produktivprojekte mit Excel. Eigentlich hasse ich den Kram wie die Pest. Ich habe aber Vorgesetzte hat die Stein und Bein darauf schwören und jeglichen Datenaustausch per Excel praktizieren und keine Lust, Zahlenkolonnen händisch einzuklimpern. Drum schreib ich mir eben einen kleinen Konverter zwischen meiner SQL-Datenbank und der Vorgabeliste aus der Chefetage. Ich hab die Daten dann in Sekunden wo andernfalls zwei Sekretärinnen jeweils 3 Tage dran sitzen.

Was ist Excel eigentlich nun genau? Weder eine Datenbank noch ein Schreibprogramm, sondern irgendwas dazwischen. Quasi eine Chimäre oder ein Bastard. Selbst Access, wollte vielleicht mal eine Datenbank werden und ist auf halbem Wege stecken geblieben.

[Jumpy]

Excel ist eine Tabellenkalkulation(ssoftware). Was immer das nun heißt.

[Codehunter]

Jo für mich stellt sich da die Frage: Wurde die Software erschaffen um die Anforderung "Tabellenkalkulation" zu erfüllen oder wurde das Wort erschaffen um ein sinnfreies Programm zu beschreiben?

Genauso könnte man es "Zahlenschubsdingsbums" nennen. Es gibt ja Leute, die benutzen es zum Layouten von komplexen Formularen. Ich habe sogar schon Schülerzeitungen gesehen die Excel als DTP-Programm einsetzten.

Der Grund, warum ich mit Excel nicht warm werde, lässt sich exemplarisch an der Funktion bzw. dem Button "Zellen verbinden" herleiten: Wäre Excel spaltenorientiert, dann dürfte man sowas gar nicht machen können. Es gibt auch lustige Berechnungsfunktionen, die zellenorientiert arbeiten. Verbindet man aber Zellen, auf die sich andere Zellen per Formel beziehen, dann gibts Datensalat. Also ist es auch nicht unbedingt Zellenorientiert.

Fazit: Excel ist eine Datenbank für Leute die nicht wissen was eine Datenbank ist. Excel ist ein DTP-Programm für Leute, die mit großen DTP-Programmen nicht klar kommen. Und Excel ist ein Schreibprogramm, die damit angeben wollen dass ihnen Word nicht ausreichen täte.