InMemTable und Datensteuerung

[mafi01]

Hi Folks,

ich habe das Problem, das bei einer TTable und einer SQL-Datenbank das Scrollen nach einem Edit-Post bzw. Edit-Cancel-Scroll zu lange dauert (ca. 3 Minuten für ca. 50000 Records). Deshalb habe ich vor, eine abgeleitete InMemTable zu verwenden die nur einen einzigen Datensatz enthält. Über einen TQuery werden die Daten in die Tabelle geschrieben. Das Ändern, Zufügen und Löschen wird in SQL-Befehle umgesetzt (Select, Insert, Delete und Update).
First, Prior, Next, Last wird über den PrimaryKey der Tabelle realisiert, (zb. First=Select Min(PK) from Table, Next=Select Min(PK) from Table where PK > OldPK, ..)

Welche Methoden muss ich unbedingt überschreiben, damit ich unter anderem auch den Navigator verwenden kann (First, Prior, Next, Last-Buttons), da die InMemTable nur einen einzigen Datensatz enthält.

Gibt es andere und vielleicht schneller oder einfacher zu realisierende Möglichkeiten?

Viele Grüße von
Manfred

[Andreas Kosch]

Hallo,

ich würde diese Idee noch einmal gründlich überschlafen :-)

>Gibt es andere und vielleicht schneller oder einfacher zu realisierende Möglichkeiten?

Selbstverständlich. Wenn die SELECT-Abfrage eine geeigente WHERE-Einschränkung verwendet, muss TQuery niemals derart grosse Ergebnismengen verwalten, so dass es nicht zu diesen zeitlichen Verzögerungen beim Kopieren der Ergebnismenge vom SQL-Server zum Client-Rechner kommt.

Eine SQL-Datenbank ist <b>mengenorientiert</b>, daher gibt es dort kein Konzept "<i>vorheriger bzw. nächster Datensatz</i>". Die Position eines bestimmten Datensatzes in der Ergebnismenge hängt ausschließlich von der SELECT-Abfrage ab (WHERE- und ORDER BY-Anweisung).

Wenn TQuery eine SELECT-Abfrage abschickt, die im WHERE-Part nach einem <b>Primärschlüsselwert</b> sucht, kann das Ergebnis maximal aus einem einzigen Datensatz bestehen. Daher ist die InMemory-Tabelle völlig überflüssig.

Wenn der Client aber in jedem Fall durch die vollständige Ergebnismenge navigieren können soll, ohne alle Daten laden zu müssen, steht beim Zugriff über ADO die Einstellung <b>clUseServer</b> zur Verfügung. Der Client erhält somit einen server-seitigen Cursor, mit dem er Datensatz für Datensatz durch die Ergebnismenge scrollen kann (wobei ADO immer nur einen einzigen Datensatzpuffer verwendet)

[S Hoffmann]

Hallo, ich gehe schon länger mit einer ähnlichen Idee schwanger!
Ich will ein Grid asynchron/nach Bedarf füllen. Das Grid soll readonly sein und nur beim Scrollen einen readwrite-Dataset positionieren (mittels PK-Wert).
Das Grid speichert dabei die Daten, welche ich nach Bedarf in Paketen abhole/aktualisiere/lösche.
Bei deiner Lösung empfehle ich die Beschäftigung mit TDataLin