ADO | Edit | Post - aktualisierbare Abfrage

[marabu]

Du musst den Dataset schließen (Close) - erst dann kann Excel die Tabelle laden und die Berechnung durchführen. Dann muss Excel die Tabelle schließen und du kannst wieder auf die Daten zugreifen. Keine gute Lösung finde ich.

Du solltest vielleicht mal über OLE-Automation nachdenken ...

marabu

[cltom]

Nun, das Dataset wird geschlossen.

Zitat von marabu:

... erst dann kann Excel die Tabelle laden und die Berechnung durchführen. Dann muss Excel die Tabelle schließen und du kannst wieder auf die Daten zugreifen.

Was meinst Du damit, dass Excel die Tabelle schließt? Wie löse ich das "von aussen" aus?

[mkinzler]

Zitat:

Was meinst Du damit, dass Excel die Tabelle schließt? Wie löse ich das "von aussen" aus

?Per OLE/COM. Aber dann kannst du ja auch den rest darüber machen, dann entfällt auch das ständige Schließen und Wiederöffnen.

[cltom]

ok, das schaue ich mir mal an.

Vielen Dank erst mal!!

[cltom]

Nochmals aufwärm, ich bleib aber beim Thema:

Also die Datei mit einer ExcelApplication hinterher öffnen, speichern und wieder schließen funktioniert zwar, ist aber ziemlich unbefriedigend. a) weil unhübsch b) weil langsam. Gibt es echt keinen Weg, das mit ADO zu lösen? Wenn nicht sehe ich den Sinn eines ADO-Edit-Posts nicht so ganz. Wie soll man das sinnvoll einsetzen, wenn man die Datei irgendwo extra noch speichern muss?

Danke im voraus für weitere Hilfe!

gruß
tom

[marabu]

Hallo Tom,

soweit ich dein Problem verstehe suchst du nach einer Möglichkeit Excel als Taschenrechner zu missbrauchen. Offensichtlich sind die Formeln in Excel so komplex geraten, dass du sie nicht direkt in Delphi implementieren kannst. Also benötigst du eine Art der Programm-Programm-Kommunikation. Ich habe dir gezeigt, wie du ein Spreadsheet lesen und verändern kannst, aber da wusste ich noch nicht, was du wirklich vorhast.

Wenn möglich implementiere die Formeln direkt in Delphi, wenn nicht benutze die Automationsschnittstellen von Excel. Der Jet OLEDB Provider für Excel hilft dir hier nicht so recht. Er ist einfach vom Design her ungeeignet für deine Zwecke. Benutze ihn, wenn du Daten importieren oder exportieren möchtest.

Zitat von cltom:

Gibt es echt keinen Weg, das mit ADO zu lösen?

Ich laufe Gefahr mich zu wiederholen: Solange du das Spreadsheet im Zugriff hast, kann Excel die Datei nicht öffnen und umgekehrt. Der Provider greift exklusiv auf die Datei zu. Probiere es einfach mal aus.

Grüße vom marabu

[cltom]

Hallo marabu,

Zitat von marabu:

Offensichtlich sind die Formeln in Excel so komplex geraten, dass du sie nicht direkt in Delphi implementieren kannst.

nun, jein. Ein Teil der Formeln ist trivial, ein Teil relativ komplex und zwar so komplex, dass es nicht in Delphi nachgebaut werden soll (erst einmal).

Zitat von marabu:

Solange du das Spreadsheet im Zugriff hast, kann Excel die Datei nicht öffnen und umgekehrt. Der Provider greift exklusiv auf die Datei zu. Probiere es einfach mal aus.

Sorry, aber das verstehe ich nicht ganz. Ich öffne die ADO-Connection, mache locate, edit, post und schließe sie hinterher. In der derzeitigen Fassung öffne, lese und schließe ich die Excel-Datei andauernd, das macht eigentlich keine Probleme.
Welcher Provider greift dann noch auf die Datei zu?

Die OLE Automatisation hat mir eigentlich recht wenig gefallen, weil dann Excel immer aufgemacht werden muss. Das ist a) zeitintensiver und b) erlaubt es (soweit ich durchblicke) nicht so elegante Queries etc.

gruß
tom

[marabu]

Hallo Tom,

Zitat von marabu:

Solange du das Spreadsheet im Zugriff hast, kann Excel die Datei nicht öffnen und umgekehrt. Der Provider greift exklusiv auf die Datei zu. Probiere es einfach mal aus.

ich muss das revidieren - ich wechsle immer zwischen zwei Maschinen, auf einer ist MS Office installiert, auf der anderen nur der XL Viewer. Beim Testen mit MS Office gibt es keine Probleme mit dem Zugriff per ADO auf ein geöffnetes Spreadsheet. Weil ich das Stichwort Multi-User ins Spiel gebracht hatte, hier eine authentische Darstellung dazu:

MS KB Artikel 195951

IMPORTANT: Though ASP/ADO applications support multi-user access, an Excel spreadsheet does not. Therefore, this method of querying and updating information does not support multi-user concurrent access.

Zitat von cltom:

Die OLE Automatisation hat mir eigentlich recht wenig gefallen, weil dann Excel immer aufgemacht werden muss. Das ist a) zeitintensiver und b) erlaubt es (soweit ich durchblicke) nicht so elegante Queries etc.

Egal was du zuletzt machen wirst - Excel muss geöffnet werden, wenn du die Dienste der calculator engine nutzen willst. Wer sollte sonst deine Formeln auswerten?

Grüße vom marabu