Embedded SQL Cursor updaten

[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