Setze den Cursor dorthin wo...

[hathor]

35. Mai 2008
Du solltest mal den Händler (Deiner Drogen) wechseln!

[Bernhard Geyer]

Es gibt einen RecordNo. Der ist aber ehr DB-Interner Natur.

Für deinen Fall würde ich eher so vorgehen:

Du willst 31 Mai. Dann lade alle Daten vom 30. Mai - 1 Juni.
Scrollt der User dann Richtung Ende 1. Juni, lade den 2 Juni.
Das alles am besten ohne DB-Sensitive Controls.

Wie man so schön sagt: Niemand will durch 1 Mio. Datensätze sehen. Und der Admin wäre auch froh wenn du nicht 1. Mio Datensätze übers Netz bewegen würdest.
Und die Angabe "ich lade immer ja nur Häpchenweise" bringt den DB-Admin zur Weißglut. Denn deine 1 Mio. Datensätze gehen zwar nicht (gleich) übers Netz, aber der DB-Server muss dafür sorgen das diese 1 Mio. Datensätze entsprechende dem Abfragezeitpunkt gültig bereitstehen (also Löschaktion oder Inserts nicht auf diese 1 Mio. Datensätze wirken).

[humbuck]

Naja, wenn du wirklich nach dem 35. Mai suchst, wirste sicherlich verdammt lange und erfolglos suchen müssen.

Solltest du jedoch nach einem realen Datum suchen wollen UND Daten-sensitive Controls verwenden, kannst du dies ja mit der folgenden Funktion versuchen:

function Locate(const KeyFields: string; const KeyValues: Variant; Options: TLocateOptions): Boolean; virtual;

Locate setzt die Cursor-Pos auf den angegeb. Datensatz und von dort kannste dann munter vor- und zurückblättern

zum Bleifisch:

Delphi-Quellcode:

DBGrid1.DataSource.DataSet.DisableControls;
DBGrid1.DataSource.DataSet.Locate('Datum','25.05.2008', [loCaseInsensitive])
DBGrid1.DataSource.DataSet.EnableControls;

Die Suche dauert bei einer Million Datensätzen schlechthin vergleichsweise lange und belastet immer den SQL-Server... ist unvermeidlich...

[Der schöne Günther]

Zitat von Bernhard Geyer:

Und die Angabe "ich lade immer ja nur Häpchenweise" bringt den DB-Admin zur Weißglut. Denn deine 1 Mio. Datensätze gehen zwar nicht (gleich) übers Netz, aber der DB-Server muss dafür sorgen das diese 1 Mio. Datensätze entsprechende dem Abfragezeitpunkt gültig bereitstehen (also Löschaktion oder Inserts nicht auf diese 1 Mio. Datensätze wirken).

Das sehe ich ein. Aber in diesem Fall ist das ok.

Zitat von humbuck:

kannst du dies ja mit der folgenden Funktion versuchen:

function Locate(const KeyFields: string; const KeyValues: Variant; Options: TLocateOptions): Boolean; virtual;

Danke! Das war genau was ich wollte. In meinem konkreten Fall habe ich dadurch nichts gewonnen denn FireDAC ist nach wie vor genauso langsam, die ACE-Komponenten von Sybase schaffen das in Millisekunden, FireDAC braucht mehrere Sekunden. Da liegt wohl die Schuld bei FireDAC.

[humbuck]

wenn du zwingend einen zeitlichen Vorteil benötigst, solltest du sicherlich eine andere Verbindungsschicht einsetzen.

Aber noch mal zu deinem Query:

Zitat:

Beispielhafte Query: SELECT ZEITPUNKT, MESSWERT FROM myTable

Es besteht natürlich auch noch die Möglichkeit, die Datenmenge vom SQL-Server einzugrenzen. Das macht das Paket, das über ein Netzwerk versendet wird deutlich schneller:

Query: SELECT ZEITPUNKT, MESSWERT FROM myTable WHERE ZEITPUNKT BETWEEN '23.04.2014' AND '26.05.2014'
Wenn du die Filter-Funktion deiner Datenkomponente verwendest, musst du allerdings auf BEWTEEN verzichten. Alternativ kannste aber auch logische Vergleichsoperatoren verwenden:
ZEITPUNKT >= '23.04.2014' AND ZEITPUNKT < '27.05.2014'

Das ganze ist immer davon abhängig, wie viele Messungen pro Tag durchgeführt werden. Ggf. musst du dann auch kürzere Intervalle selektieren und die Uhrzeit mit ins Spiel bringen, falls möglich...

[Dejan Vu]

Zitat von Bernhard Geyer:

Und die Angabe "ich lade immer ja nur Häpchenweise" bringt den DB-Admin zur Weißglut. Denn deine 1 Mio. Datensätze gehen zwar nicht (gleich) übers Netz, aber der DB-Server muss dafür sorgen das diese 1 Mio. Datensätze entsprechende dem Abfragezeitpunkt gültig bereitstehen (also Löschaktion oder Inserts nicht auf diese 1 Mio. Datensätze wirken).

Also nee, mittlerweile nicht mehr. Stichwort: Paging Funktionen.
http://en.wikipedia.org/wiki/Select_(SQL) weiter unten bei 'Result limits'
Ist zwar irgendwie auch ein Zugeständnis an die "Ich will alles und immer", aber die Server sind mittlerweile soweit. Wenn sich die Daten mittlerweile ändern, Pech für den Betrachter.

Und, ja: Wenn es keinen Index auf der Ordnungspalte gibt, kotzt der Admin und die Serverprovider reiben sich die Hände, weil noch mehr RAM her muss. Na und der Anwender wartet sich einen Wolf.

Was ganz schlimm ist, und das meinte Bernhard: Wenn ein Provider noch Cursor für das Paging verwendet. Tipp: Schau mal, was der Provider zu deinem SQL-Dings schickt.