positionieren im Resultset

[Klabautermann]

Hallo,

Ich werde die Varaiante mit dem Blockfetch ausprobieren. Ich gebe bescheid, welche lösung am Performantesten ist.

@andreaspr@aon.at: Der Cursor bleibt offen. Das Problem ist, dass der "Fetch relative 3451244" zu viel performance frisst.

@K_Tippi: Auf Klassischem wege wäre das kein Problem. Dann könnte ich mir eine logische erstelle und mit SetLl/ReadE arbeiten. Leider ist das keine Option

Viele Grüße

[Fuerchau]

Es besteht kein Grund, den Cursor offen zu halten, da man mit einer korrekten Where-Klausel auf dem Schlüssel ja positionieren kann.
Um die Anzahl der Datensätze zu beschränken kann man ja "fetch first n rows only" verwenden.
Nach dem Laden der Sätze in die Subfile und beim Weiterblättern setzt man entsprechend neu auf.

Für das Rückwärtsblättern nimmt man dann einen 2. Cursor mit absteigender Sortierung und füllt die Subfile dann rückwärts (geht mit SFLINZ(nn) und entsprechenden Chain/Update).

Dies ist allemal performanter als mit so großen Resultsets zu arbeiten und man bekommt auch noch aktuellere Daten.
Wenn entsprechende Indizees vorligen ist das auch noch schnell, da die ODP's ja offen bleiben (nicht die Cursor).

[Klabautermann]

Hallo zusammen,

ich habe es nun folgendermaßen gelöst:

Ich habe 2 Arrays erstellt.
1 Statisches mit DIM(1000) und ein dynamisches, in dem sich das statische befindet.

Ich arbeite nun beim Blättern das statische Array ab. Sobald ich das letzte Element erreicht habe hole ich mir die nächsten 1000 Sätze per Blockfetch in mein Dynamisches Array.

Möchte der Anwender nun Positionieren, Beginne ich im 1. Element des Dynamischen Arrays und prüfe das letzte Element des Statischen Arrays ab. Ist dies größer(entsprechend Sortierung) als die Eingabe des Anwenders, befinde ich mich im korrekten Element des Dynamischen Arrays. Ist es kleiner(entsprechend Sortierung) prüfe ich das nächste Element ab.

Sobald ich mich im richtigen Element des Dynamischen Arrays befinde, prüfe ich das Statische Array ab.

Hierzu prüfe ich zuerst das mittlere Element ab, ob es größer als die Eingabe ist. Ist dies der Fall fange ich ab Position 1 an, ansonsten ab Position 500 und prüfe jedes Element ab.



Diese Lösung braucht zum Aufbau des Resultsets ca. 5 sek. Beim 1. Positionieren (bis das komplette Resultset im Array ist) ca. 7 sek.
Ab dann positioniere ich innerhalb weniger sekunden.


PS: Da ich in meinem Array nur die Keyfelder habe und mir erst beim füllen des Subfile die weiteren inforamtionen hole, habe ich auch immer aktuelle Daten. Ausnahme ist natürlich wenn ein Satz hinzugefügt wird. Hier muss der Anwender via F5 aktualisieren. Sollte ein Satz gelöscht werden wird dies mit einer meldung (*GELÖSCHT*) gekennzeichnet.


Ich danke euch allen fürs mitdenken und für die hilfe

Schönen Gruß

[BenderD]

Hallo zusammen,

ich habe es nun folgendermaßen gelöst:

Diese Lösung braucht zum Aufbau des Resultsets ca. 5 sek. Beim 1. Positionieren (bis das komplette Resultset im Array ist) ca. 7 sek.
Ab dann positioniere ich innerhalb weniger sekunden.
Schönen Gruß

... das sind völlig unzureichende Antwortzeiten, beschreibe dochmal genau, was der Anwender haben will, was er eingibt und was er dann bekommen soll. Ich bin sicher, dass es da was wesentlich schnelleres geben muss!!!

D*B

[Fuerchau]

Da bin ich aber auch der Meinung, dass das inakzeptabel ist.
Wie gesagt, bei korrekter Erstellung eines Index für die Where/OrderBy-Klausel sollte der Zugriff erheblich schneller sein.
Außerdem macht es keinen Sinn, die Daten selber noch mal in einem Array zu halten, da doch die Subfile bereits im Speicher (der DSPF) liegt.

[andreaspr@aon.at]

@andreaspr@aon.at: Der Cursor bleibt offen. Das Problem ist, dass der "Fetch relative 3451244" zu viel performance frisst.

Weist du zufällig was das zirka in Zahlen heist?
Das ein User beim Laden und Blättern ein paar Sekunden warten muss ist auch nicht ideal.
Da ich bis jetzt noch kein Resultset hatte, das über mehrere Mio Sätze ging (zumindest nicht für eine Ausgabe am Bildschirm), würde mich das interessieren.

[Klabautermann]

Hallo,

für den "Fetch relative 3451244" hat er ca. 40 sekunden gebraucht.

Und das bei jedem positionieren ist zu lange.