Inoffizielles deutsches Xbase-Forum

Angenommen, man hat einige Workareas mit jeweils SELECT-Befehl in cSelect und Aliasname in cQueryAlias wie folgt generiert: Nun irgendwann kommen Datensätze dazu und man will eins dieser Workareas auffrischen, also den dazugehörigen SELECT-Befehl wieder ausführen.
Gibt es einen eleganten Weg, dies zu machen?

So weit ich sehen kann, müsste man: und dann das Workarea wie oben neu erzeugen.
Wirklich schlimm ist das nicht, nur etwas klotzig weil man pro Workarea entweder cSelect oder oStmt1 merken müsste.
Also, meine Frage ist, gibt es vielleicht irgendwo Folgendes, das ich übersehen habe? Entweder:

1. (Am Allerbesten) Eine eingebaute Auffrischungsfunktion für ein SELECT-basiertes Workarea, oder
2. eine Möglichkeit, den unterliegenden SELECT-Befehl bzw. SqlStatement-Objekt eines solchen Workareas herauszulesen?

Danke erstmal Hans-Peter!

Das spricht dafür, lieber das jeweilige SqlStatement-Objekt als den SELECT-Befehl für jedes solche Workarea zu speichern: Das kann man direkt nutzen, und man kann mit :asString() den SELECT-Befehl rauskriegen falls irgendwann nötig. Aber so weit ich sehe löst es nicht das Problem, dass diese Speicherung immernoch nötig wäre: Ich habe noch keinen Weg gefunden, das SqlStatement-Objekt für das aktuelle Workarea herauszukriegen.

Mmh. oStmt:Execute() erzeugt doch erst das Ergebnis in einer Workarea, alles andere ist nur Statement-Bauen. Wozu brauchst Du das SELECT aus dem Statement? Du kannst doch einfach das Execute noch einmal abfeuern, und dann müsste die Workarea aktualisiert sein.

Hallo Tom!

Richtig, ich brauche nicht den SELECT-Befehl wenn ich das Statement habe.
Habe ich aber nicht (mehr), müsste ich pro Workarea speichern, und habe gehofft, dass dies schon irgendwo existiert.
Oder besser, dass man so ein Workarea einfach auffrischen könnte.

Kann man, mit DbRefresh(). Aber ich glaube nicht, dass das den Cursor aktualisiert. Ich habe in der PGDBE gerade ein Problem mit Scopes auf Tabellen mit aktiven Descending-Indexen, da aktualisiert sich die Workarea nach einem DbAppend() leider nicht, wenn ich das richtig sehe. Und DbRefresh() hat auch keine Wirkung. (DbGotop() und die anderen Kandidaten, die bei dem gleichen Problem ohne Descend vorher geholfen haben, helfen auch nicht.)

Stimmt, DbRefresh() kannte ich nicht, das wäre genau das was ich suche wenn es in diesem Fall so gehen würde.

Aber nachdem ich ein Append an die Originaltabelle mache, bleibt auch nach DbRefresh() der COUNT im SELECT-basierten Workarea gleich, obwohl der neue Datensatz die Bedingungen im SELECT...WHERE erfüllt, also können wir doch davon ausgehen, dass DbRefresh() den SELECT-Befehl nicht wieder ausführt.

Also, es wäre ganz nett wenn Alaska DbRefresh() so erweitern könnten, aber ich möchte sie gerade jetzt nicht belästigen, ich warte gespannt auf dem aktuellen Update, also werde ich erstmal doch die SqlStatement-Objekte speichern...

Ja, die allgemeine Probleme nach DbAppend() kommen mir auch bekannt vor. Bei Descending klingelt mir auch etwas, aber leider nur ganz vage und lange her... Auch eine Suche nach "desc" in meinem GIT-Repository hat nichts gebracht. Ich nehme an, Du hast schon DbGoBottom() versucht, aber das halte ich auch nicht für vielversprechend. Sorry, es fällt mir nichts Weiteres im Moment ein.