Embedded SQL Cursor updaten

[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