ADO | Edit | Post - aktualisierbare Abfrage

[cltom]

Hej DP!

kann eigentlich nicht so schwer sein, funktioniert aber trotzdem nicht: edit in einer Excel-Datei, die via ADO angesprochen wird.

Was vorhanden ist:

Datasource, ADOConnection, ADODataset (cmdTable) und dann folgende simple zeilen.

Delphi-Quellcode:

with dataset_xyz do
begin
  Edit;
  FieldValues['feldname'] := 99;
  Post;
end;

=> Operation muss eine aktualisierbare Abfrage verwenden.

Danke für Tipps!

gruß
tom

[mkinzler]

Wie sieht die Abfrage aus?

[cltom]

öhm, keine Query, sondern Table (dataset.commandtype := cmdTable).

Geht edit/post nur auf einer Query?

[mkinzler]

Es geht nur bei einem updateable View. Dies hängt von der Abfrage und der Datenbank ab. eine Abfrage, die sich auf eine Tabelle bezieht (was bei einer Table der Fall ist ; select * from Tabelle) ist das der Fall, also scheint es, ob eine ADO-Verknüpfung mit Excel nicht updateable ist.

[cltom]

ob es hier scheitert?

Zitat:

Use the TADODataSet component's CommandText property to retrieve the dataset, specifying either a table name or an SQL statement (SELECT only). TADODataSet is not capable of issuing Data Manipulation Language (DML) SQL statements that do not return result sets (like DELETE, INSERT, and UPDATE). For this use a component like TADOCommand or TADOQuery.

[mkinzler]

Dann versuch es doch mal mit einem TADOQuery, ob es da funktioniert.

[marabu]

Guten Morgen.

Ein ADO Dataset verliert seine Update-Fähigkeit, wenn der OLE DB Provider für Excel bei der Analyse der Daten feststellt, dass in einer Spalte verschiedene Datentypen gemischt auftreten.

Nachtrag: Es gibt einen KB Artikel zu diesem Thema: How to Query and Update Excel Data Using ADO From ASP

Grüße vom marabu

[cltom]

hej!

danke für den Hinweis. Reicht es da schon, wenn der Spaltentitel in der ersten Zeile steht? Dann kann ich ja nicht mehr darauf zugreifen?!

Und gibt es eine Möglichkeit drumherum? Wie es halt immer so ist, dass es eine Excel-Tabelle sein soll und keine richtige Datenbank steht fest und dass User möglicherweise Datentypen vermischen kann auch passieren.


gruß
tom

[cltom]

ok, ein Stückchen schlauer weiss ich nun, was HDR=Yes heisst ...

Mittlerweile ist auch ReadOnly=False drin, was die ursprüngliche Fehlermeldung elminiert hat, stattdessen erhalten ich jetzt:

"Installierbares ISAM nicht gefunden"

Microsoft.Jet.OLEDB.4.0 ist aber im ConnectionString drin, was ist nun verkehrt?

danke

[cltom]

ach ja und via Query kriege ich das gleiche. "Installierbares ISAM nicht gefunden"

[marabu]

Leider kann ich das mangels Excel auf meiner Maschine nicht überprüfen. Wenn die Treiber auf dem aktuellen Stand sind, dann vermute ich einen Fehler im ConnectionString. Kannst du den mal einstellen?

marabu

[cltom]

Ich habe es mittlerweile auf einem zweiten Rechner probiert, dito. Hier einfach der betreffende Teil:

Delphi-Quellcode:

  Datasource1.DataSet := ADODataset1;
  ADODataset1.CommandType := cmdTable;
  ADODataset1.CommandText := tablename;
  ADODataset1.Connection := ADOConnection1;
  ADOConnection1.ConnectionString := 'Provider=Microsoft.Jet.OLEDB.4.0;Data Source='+filename+';ReadOnly=False;Extended Properties="Excel 8.0;HDR=Yes;IMEX=1";Persist Security Info=False';
  ADOConnection1.LoginPrompt := False;
  ADODataset1.Active := True;

with ADODataset1 do
begin
  Locate('xyz', 'abc',[]);
  Edit;
  FieldValues['lnm'] := 99;
  Post;
end;

Danke für Hilfe!

[marabu]

Guten Morgen,

bei mir geht es so:

Delphi-Quellcode:

begin
  with TADODataset.Create(self) do
  begin
    CommandType := cmdTableDirect;
    CursorType := ctStatic;
    LockType := ltPessimistic;
    ConnectionString := 'Provider=Microsoft.Jet.OLEDB.4.0;'
                      + 'Data Source=.\Mappe1.xls;'
                      + 'Mode=ReadWrite;'
                      + 'Extended Properties="Excel 8.0;HDR=Yes";'
                      + 'Persist Security Info=False';
    CommandText := 'SELECT * FROM [Tabelle1$A1:C5]';
    Open;
    Locate('a', '3', []);
    Edit;
    FieldValues['c'] := 123;
    Post;
    Close;
    Free;
  end;
end;

Da sind schon ein paar Unterschiede - kannst du sie sehen?

Grüße vom marabu

[mikhal]

Umfasse mal den Dateinamen mit ", wenn ein Leerzeichen im Dateinamen vorkommt (z.B. \Eigene Dateien\...) bringt das ADO mächtig durcheinander...

Grüße
Mikhal

[cltom]

Hej!

Danke für die Antworten. Irgendwie funktioniert es trotzdem nicht.

Mit ReadOnly=False; im Connection String kommt immer:
'Installierbares ISAM nicht gefunden', unabhängig ob ich cmdTable oder cmdTableDirect nehme.

Mit Mode=ReadWrite im Connection String kommt:
'Tabellenname nicht gefunden' bei cmdTableDirect
und
'Operation muss eine aktualisierbare Abfrage enthalten' bei cmdTable;

Keinen Unterschied macht es, wenn ich den Dateinamen in Anführungszeichen setze. Habe mal auch testweise eine Access-Tabelle gemacht, mit der funktioniert es auf Anhieb. Lese-Zugriff auf diese Excel-Tabelle geht auch tadellos.

Hab keine Idee, woran das liegt. Habe mal ein simples Testprojekt angehängt, vielleicht hat jemand Zeit, zu schauen, ob es bei ihm geht.

danke im Voraus, ligrü
tom

[marabu]

Ahoi Tom,

nimm den Parameter ReadOnly aus dem ConnectionString, er ist verantwortlich für den ISAM-Fehler - und weg mit IMEX=1 aus den Extended Properties, dadurch verliert der RecordSet seine Update-Fähigkeit.

Grüße vom marabu

[cltom]

jooo!!

Gott sei's gedankt, getrommelt und gepfiffen. Es funktioniert. Danke!!

[cltom]

Zusatzfrage:

wenn ich eine auf diese Weise veränderte Excel-Datei hinterher wieder auslese erhalte ich noch die Werte vor der Änderung. Erst wenn ich die Datei im Excel öffne und speichere, stimmt's. Die Änderung ist aber nach dem Post da - was spielt's hier?

[marabu]

Die Methode Post() macht deine Änderungen persistent - das ist völlig in Ordnung so. Vorher solltest du garnicht mit Excel auf die Daten zugreifen können, da der Provider nicht multi-user-fähig ist.

marabu

[cltom]

hmm, ok. Wie erreiche ich dann, dass die Änderungen übernommen werden?

Hintergrund: anhand des via Edit und Post geschriebenen Wertes soll innerhalb Excel etwas berechnet werden und das Ergebnis sofort wieder ausgelesen.

[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:

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:

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:

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:

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:

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:

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