Embedded SQL Cursor updaten

[Tschabo]

Hallo,

ich habe eine Subfile bei der man einen Satz zum Ändern auswählen kann. Nach erfolgter Änderung wird der geänderte Wert dann sofort in der Subfile angezeigt. Ich setze hier eine einseitige Subfile ein.

Nun habe ich die Geschichte mit Embedded SQL gemacht, aber ich habe keinen Plan (außer natürlich den Cursor neu füllen) wie ich den geänderten Satz sofort anzeigen kann..

Kann mir hier jemand weiterhelfen.

[andreaspr@aon.at]

Du kannst den Cursor SENSITIVE definieren.
Dadurch bekommst du bei jedem FETCH die aktuellen Daten, auch wenn diese erst nach dem OPEN geändert wurden.

lg Andreas

[Tschabo]

Wie kann ich denn in dem CURSOR positionieren, damit eine neuer FETCH gemachr werden kann?

[andreaspr@aon.at]

Mit dem Schlüsselwort SCROLL kannst du den Cursor "scroll-fähig".
Beim Fetch kannst du dann den Cursor positionieren wo du willst.

Exec Sql Fetch Current From c1 into :Ds;

oder

Exec Sql Fetch Prior From c1 into :Ds;

uvm.

In der SQL Referenz (im Kapitel FETCH) findest du die komplette Doku darüber.

[Fuerchau]

Das ist da eher der falsche Weg, denn beim sensitiven Cursor bekommst du auch neue Sätze mit, die du noch nicht in der SFL hattest.
Da ja nun mal zu jedem SFL-Satz ein eindeutiger Schlüssel gehört, solltest du den Cursor nur zum Füllen der SFL nehmen. Da du zum Update ja eine Where-Klausel hast, kannst du auch direkt einen "Select ... into ... from ... where ..." für einen einzelnen Satz ausführen.
Mit dem Cursor kannst du nur "releativ" positionieren und das ist nun mal mühsamer.

[B.Hauser]

Schau Dir mal die Erweiterungen LIMIT und OFFSET an.
Wenn Du seitenweise füllst, setzt Du immer mit dem OFFSET (z.B. Satz 350 aus dem gesamten Result Set) auf und liest die mit LIMIT angegebene Anzahl an Datensätze in deine Subfile.
Da Du bei jedem Füllen einen Open (multiple row) FETCH und einen Close machst, bekommst Du auch immer die aktuellen Daten.
Offset Clause

Birgitta

[Fuerchau]

Also das mit dem Offset/Limit wird ja gerne schon beim SQL-Server für Paging von Web-Seiten propagiert.
Man sollte sich das allerdings gut überlegen, da die Positionierung mittels Offset immer langsamer wird, je weiter man sich nach hinten bewegt. Immerhin kann auch SQL hier nichts anderes tun als die Offset-Sätze zu überlesen. D.h., je komplexer ein SQL ist, um so schlimmer wird das nämlich, da nun mal alle Daten vor dem Offset ermittelt werden müssen um sie anschließend zu verwerfen.
Sowas sollte man tunlichst bei z.B. UDF's, Group by oder Partition/OLAP-Funktionen vermeiden.

Offset/Limit ist nämlich eine Funktion des Select's und nicht des Cursors.
Ein statischer (insensitive) Scrollcursor ist da effektiver da man mittels "Fetch releative +/- N" eben positionieren kann und der SQL nicht noch mal neu berechnet wird.
Möchte man aktualisierte Daten, kann man den Cursor dann eben schließen und neu öffnen.

Für das SFL-Problem gibts daher 2 Möglichkeiten:
Nach der Änderung die Subfile clearen, neu füllen und auf die gemerkte relative SFL-Position positionieren.
Hier bekommt man alle Änderungen der Daten mit (also auch Veränderungen der nicht bearbeiteten Position), oder eben nur den einfachen SQL wie oben beschrieben.

[B.Hauser]

Schön, dass Du wie immer genau Bescheid weißt, was im Untergrund abläuft.

Was beim SQL Server schief läuft muss noch lange nicht bei der DB2 for i schieflaufen.

Ob ich einen (scroll) Cursor geöffnet habe und immer wieder den nächsten Block nachladen muss bis ich zu den gewünschten Daten komme, bzw. bei sensitiven Cursorn immer alles nachladen muss, oder ob ich einen Cursor basierend auf Limit und Offset habe, bei dem gezielt nur die angeforderten Daten geladen werden, ist m.E. nicht egal!

Über die Techniken, die im Untergrund implementiert sind, müssen die Daten beim LIMIT und OFFSET eben NICHT alle geladen werden, sondern der Zugriff erfolgt (über Pointer und andere effiziente Methoden) direkt auf die angeforderten Daten. Zuerst wird die Start-Position bestimmt und dann auf die Daten zugegriffen.

Birgitta

[Fuerchau]

Ich habe diesbezüglich nun doch schon einiges ausprobiert.
Bei kleinen Datenmengen und simplen Abfragen ist das ja alles gut und schön.
Spätestens aber schon bei der Where-Klausel, die ja heute schon den Optimizer vor diverse Probleme stellt, ist das Verarbeiten und anschließende Verwerfen von Daten nicht gerade Performancesteigernd.
Wenn z.B. per "Offset 1001 Limit 20" also 1000 Aufrufe der UDF vergebens sind sollte ich mir wirklich Gedanken über den Sinn hier machen.
Auch bei "Group by ... having ... order by ..." besteht keine "Optimierung" außer eben der, die Berechnungen, Joins, Gruppierung und Sortierung durchzuführen um anschließend die ersten 1000 Ergebnisse weg zu schmeißen.

Was da im Untergrund abläuft ist mir da letztlich wurscht, für mich zählt das Ergebnis.
Man kann per STRSQL oder auch per QMQRY im Dialog ja sehr schön die Statususgabe betrachten und (wenn man dem Glauben schenken darf) durchaus mehrere Millionen Zugriffe angezeigt werden um wenige 100 Sätze zu bekommen.
Im Diagnose-Modus per ODBC kann man dann durchaus verfolgen, dass dann manchmal weniger als 100 Sätze/Sekunde von der AS/400 bereitgestellt werden und man sich dann fragt, was der Optimizer da mal wieder gemacht hat.
Und immer wieder tritt das z.B. beim Wechsel von V6 nach V7 auf da der Optimizer mal wieder optimiert wurde.

[BenderD]

... irgendwie versteh ich die Argumentationen nicht. Der OP schrieb von einem Subfile und dem Update eines Subfilesatzes, da scheiden doch schon mal group by und Co aus. Wenn ein update aus einem Subfile möglich sein soll, muss dieser Satz doch einen Key haben und den Inhalt kenne ich doch auch, da kann ich doch die Anzeige im Subfile gerade rücken.
Wenn ich denn eine Seite eines Subfiles neu aufbauen will, hilft mir doch weder offset und limit, noch ein scrollable Cursor, da ich doch in dem Subfile dirty Daten habe, die nicht vor konkurrierenden Änderungen, inklusive insert und delete, geschützt sind. Da kann ich doch nur beim ersten Satz mit einer passenden where clause aufsetzen und eine Seite neu lesen. Wo ist denn da ein Problem, außer dass die where clause je nach Sortierung nicht ganz trivial ist, wenn man über mehrere Felder sortieren will - aber gehen tut das auch elementar.

D*B

[Fuerchau]

@D*B

"Für das SFL-Problem gibts daher 2 Möglichkeiten:
Nach der Änderung die Subfile clearen, neu füllen und auf die gemerkte relative SFL-Position positionieren.
Hier bekommt man alle Änderungen der Daten mit (also auch Veränderungen der nicht bearbeiteten Position), oder eben nur den einfachen SQL wie oben beschrieben."

Danke für die Bestätigung.

[BenderD]

... warum soll ich da noch mal lesen müssen? Mein DAO (Datenzugriffs Modul) kennt den Inhalt des Subfiles (bei einem Bockfetch, der für dirty reads sinnvoll ist, brauche ich doch eh eine DS mit DIM - und warum soll ich die vor dem nächsten lesen löschen) und den veränderten Satz!

D*B