paged query im Eigenbau?

[Namenloser]

Sorry für den möglicherweise dummen Beitrag, aber kann man das, was du da machst, nicht möglicherweise mit dem LIMIT -Befehl einfacher lösen? Der ist doch eigentlich genau für „paged queries“ gedacht.

[bernhard_LA]

LIMIT geht leider nicht für MSSQL

[Blup]

Halte ich beides nicht für sinnvoll, bei einer Query werden doch normalerweise nur so viele Datensätze geholt, wie mit Next auch angefordert?

[Uwe Raabe]

Bei MSSQL gibt es OFFSET und FETCH in der ORDER BY Klausel.

[Dejan Vu]

Ab SQL-Server 2012 geht das so:

SQL-Code:

SELECT * from Tabelle 
ORDER BY PrimaryKeyPreferablyWithAClusteredIndex
OFFSET @page*@windowSize ROWS 
FETCH NEXT @windowSize ROWS ONLY

[himitsu]

Arbeiten ordentliche DBMS mit passenden SQL-Komponenten nicht eh schon stückchenweise?
(auch entsprechend der Antwort von Blup)

z.B. pgDAC und Co. und (bestimmt) auch DBX/DataSnap laden die Datensätze nur stückchenweise nach, es sei denn man aktiviert eine Option, um die Daten alle sofort laden zu lassen.

Auch ordentliche DBGrids haben einen Modus, um möglichst nur die angezeigten Datensätze zu laden und nicht gleich alles in den eigenen Cache zu kopieren. (nur gibt es dann natürlich oftmals keine Sortierung oder Filterung mehr)

[Dejan Vu]

Zitat von himitsu:

Arbeiten ordentliche DBMS mit passenden SQL-Komponenten nicht eh schon stückchenweise?
(auch entsprechend der Antwort von Blup)

Nope. Und selbst wenn. Die Kleinigkeit kann man nun wirklich selbst bauen.

Zitat:

Auch ordentliche DBGrids haben einen Modus, um möglichst nur die angezeigten Datensätze zu laden und nicht gleich alles in den eigenen Cache zu kopieren. (nur gibt es dann natürlich oftmals keine Sortierung oder Filterung mehr)

Wozu das Grid, wenn die Daten doch eh nur geladen werden sollen?

Delphi-Quellcode:

Type
  TVirtualQuery<T> = class
  private 
    fTopIndex, fWindowSize : Integer;
    Procedure LoadWindow (page : Integer);
  public
    property Row[index : Integer] : T read GetRow; default;
  end;

...
Function TVirtualQuery<T>.GetRow (index : Integer) : T;
Begin
  Assert ((index>0) and (index < totalRows));

  if (index<fTopIndex) or (index>fTopIndex+fWindowSize-1) then 
    LoadWindow(index div PageSize);

  result := fData[index - fTopIndex];
End;

Procedure TVirtualQuery<T>.LoadWindow (page : Integer);
Begin
  fData := LoadPageFromSQLServer (page, windowSize); // mit dem SQL-Befehl von Uwe 
  fTopIndex := page*windowSize;
End;

Das ist die Logik. Den Rest kann man wuppdiwupp einfach selbst programmieren.

Wenn man ein wenig nachdenkt, braucht man kein 'totalrows', sondern läd einfach solange, bis der Server 'Error' meldet bzw. die Ergebnismenge leer ist. Ich weiss jetzt nicht genau, was der Server macht, wenn man eine Seite anfordert, die es gar nicht gibt...

[himitsu]

Der Vorteil, wenn es DBMS+Querykomponente das machen, daß dann die Daten konsistent bleiben, egal wie lange man drin rumscrollt, es bleibt immer in dem Zustand, wie zum Zeitpunkt der Abfrage.
Denn dort bleibt das Result-Set auf dem Server erhalten und das Query holt die Daten nur noch dort raus.

Bei den Aufteilen über einzelne Anfragen, könnte es ein Problem geben, wenn sich die Daten in der Tabelle zwischenzeitlich ändern.