DBGRID und Daten laden

[Andy Nightingale]

Hallo Leute,
bin gerade an meiner C/S Anwendung. Die Daten vom DBGRID werden über einen Windows Server und Firebird geladen. Bis das Fenster erscheint dauert es ca. 7 Sekunden.-aalso eine Ewigkeit. Es sind ca. 10.000 Daten in der Tabelle. Das sind noch nicht viel. Die meisten Tabellen der Datenbank haben bis zu 500000 Daten. Jetzt meine Frage. Wie kann ich es machen das die Form sich sofort zeigt, aber die Daten dann erst geladen werden...also wenn die Form...und das DBGrid zu sehen sind erst geladen wird...vielleicht mit einem Ladebalken. Hat hier jemand Ideen? Grüße

[kralle]

Moin.
Nur so eine Idee: Kannst Du nicht einfach nur den ersten Datensatz laden, damit sich das Grid aufbaut und dann den Rest?

Gruß Kralle

[af0815]

Die Daten vom DBGRID werden über einen Windows Server und Firebird geladen. Bis das Fenster erscheint dauert es ca. 7 Sekunden.-aalso eine Ewigkeit. Es sind ca. 10.000 Daten in der Tabelle. Das sind noch nicht viel. Die meisten Tabellen der Datenbank haben bis zu 500000 Daten.

Und 500.000 Datensätze sind für mich nicht wirklich viel.

Was haben 10.000 Daten im Grid verloren -> normalerweise Designfehler. Wenn es mehr als 100 SInd, schaut sich das kein Schwein an. Wozu auch. Damit brauche ich nicht soviel im Grid. Und ins Grid laden und dann verarbeiten ist auch nicht unbedingt so schlau. Meistens können die DB-Server die Vorverarbeitung sehr gut machen. Und besonders schlau ist dann auch ein "SELECT * FROM" SCNR

[Andy Nightingale]

Moin.
Nur so eine Idee: Kannst Du nicht einfach nur den ersten Datensatz laden, damit sich das Grid aufbaut und dann den Rest?

Gruß Kralle

Hallo Kralle,
ja das dachte ich auch...mit SELECT FIRST 1000 SKIP 0 * FROM PATIENTEN ORDER BY PATIENTID ...zeigt es die ersten 1000 an.-aber wie mache ich es das es die weiteren anzeigt

[Andy Nightingale]

Und 500.000 Datensätze sind für mich nicht wirklich viel.
Was haben 10.000 Daten im Grid verloren -> normalerweise Designfehler. Wenn es mehr als 100 SInd, schaut sich das kein Schwein an. Wozu auch. Damit brauche ich nicht soviel im Grid. Und ins Grid laden und dann verarbeiten ist auch nicht unbedingt so schlau. Meistens können die DB-Server die Vorverarbeitung sehr gut machen. Und besonders schlau ist dann auch ein "SELECT * FROM" SCNR

Hallo 0815,
ok wie machst du das denn? Mein Kunde schaut sich immer ca. 10.000 Daten im Grid an. Warum? Ist mir egal.-die möchten das so.-und wie lade ich dann die nächsten 10.000? Wie machst du das denn?.- und was soll da SELECT* FROM??? das mache ich ja.- ich selektiere auch 1000 Stück ...und dann????

[af0815]

Hallo 0815,
ok wie machst du das denn? Mein Kunde schaut sich immer ca. 10.000 Daten im Grid an. Warum? Ist mir egal.

Ich habe meinem Kunden (Managment) gefragt für was sie die vielen Daten brauchen -> die ANtwort war, das ganze in Excel zu importieren und dort ein paar (verzeih) blöde Grafiken daraus zu machen. Die haben dann die Grafiken gleich direkt bekommen, noch dazu soviele Variationsmöglichkeiten und das ohne Excel, gleich im Web, das sie sich das auch am WC zu Hause ansehen können. Eine Ruhe war.

Wenn es wirklich für eigene AUswertungen haben, will, so lade ich das nicht in ein Grid, sondern in ein Array, List oder Collection . Aus dieser kann man sich dann die Daten wenn gewünscht in ein Grid Portionsweise laden.
Wichtig ist, das die Datenmenge zwischen Server und Client so kompakt wie möglich ist. Also alles raus aus dem Datensatz was nicht absolut gebraucht wird. Das heisst die Spalten die übertragen werden genau benennen und KEINE Wildcard (* !!!!!!) verwenden.

Die Schwierigkeit ist meistens, den Kunden ins Boot zu holen und auch zu hinterfragen ob und für was er es wirklich braucht. Findet man eine Lösung für seine Anforderung, kann man die Datenmengen sinnvoll begrenzen. Ansonsten kann man es versuchen mit Blöcken zu machen, zb. für einen definiereten Zeitraum. Da kann ich mir die Top 100 nehmen, dann das Datum merken und wieder eine neue Abfrage , die ab dem Datum erst wieder greift. So kann man sich das notfalls in Stücken holen.

[Soner]

Die Zeit hat mit Dbgrid nichts zu tun, Dbgrid zeigt nur sichtbare Zeilen, meistens 10-30 Datenzeilen, also je nach Größe des Dbgrids. Es hat mit deine Sql-Abfrage zu tun, sind die wichtigen Felder in where oder on Klauseln indiziert?
SQL richtig aufbauen und Indizierung der wichtigen Felder bringt viel. Ich musste einmal mein Urlaub abbrechen weil ich vergessen hatte ein wichtiges Feld zu indizieren.

[charlytango]

Was haben 10.000 Daten im Grid verloren -> normalerweise Designfehler. Wenn es mehr als 100 SInd, schaut sich das kein Schwein an. Wozu auch.

Um Patienten zu verwalten braucht niemand in einem Grid x-tsd Daten.
Das ist und bleibt ein Designfehler, egal was der Kunde glaubt, zu brauchen.
Solche Mengen gehören nicht in ein Frontend.

Die Aufgabe eines Experten ist es auch, seinen Kunden auf mögliche Problemfelder und Fallgruben hinzuweisen. Und wenn nötig nachzugraben was der wirkliche Grund für die unvernünftige Anforderung ist, um eine perfekte Lösung anzubieten. siehe -->

-> die ANtwort war, das ganze in Excel zu importieren und dort ein paar (verzeih) blöde Grafiken daraus zu machen.

Und von solchen Situationen kann ich ganze Bibliotheken füllen.
Das Hauptproblem dabei ist ja nicht dass man dem Kunden das nicht hinstellen könnte, aber das hat Folgen die er nicht kennt.
zB dass die ganze Datenbank während einer solchen Abfrage schnell mal überlastet ist und streikt. Und dafür wird er dich später verantwortlich machen. Denn als DB-Frontend-Entwickler bist du für die ganze Kette zuständig, also auch den DB-Server.
Und den performant zu halten gehört auch dazu.

und was soll da SELECT* FROM??? das mache ich ja.-

Genau das sollst du eben nicht machen -- nur das allernötigsten Felder abfragen. Im Zweifelsfall dann mit einer Detailabfrage in Folge.
Ich halte "SELECT * " in JEDEM Programm für einen Kunstfehler.
Mit solchen Blödheiten haben sorglose Entwickler in Verbindung mit einem natural Join schon mal die Allianz DB Server in die Knie gezwungen.
Die kamen dann schnell mal in Erklärungsnotstand weil die Datenbank dann quasi still stand.

Es hat mit deine Sql-Abfrage zu tun, sind die wichtigen Felder in where oder on Klauseln indiziert?
SQL richtig aufbauen und Indizierung der wichtigen Felder bringt viel.

BTW:
Zeit lässt du bei einer DB Abfrage liegen bei:

Schlecht formulierter Abfrage in Verbindung mit fehlenden oder unbrauchbaren (von der DB nicht verwendeten) Indizes.

Nicht optimierte Abfragen bei großen Datenmengen. Ich bin kein Firebird Experte, aber EXPLAIN wird es wohl geben und mit fbtracemgr kannst du dem Server zusehen ob er sauber arbeitet und ggfs optimieren.

Aber all das wird noch von der Menge der übertragenen Daten getoppt.
Deswegen macht es auch so gar keinen Sinn große Datenmengen in einem DB Frontend zu übertragen -- und abhängig davon dass sich niemand x-tsd Daten wirklich ansehen kann.

[Zvoni]

Hallo Kralle,
ja das dachte ich auch...mit SELECT FIRST 1000 SKIP 0 * FROM PATIENTEN ORDER BY PATIENTID ...zeigt es die ersten 1000 an.-aber wie mache ich es das es die weiteren anzeigt

Dafür gibts die Eigenschaft PacketRecords:
https://www.freepascal.org/docs-html/fc ... cords.html
Bsp. PacketRecords = 50 --> wird immer "50"-iger-weise abgeholt

Wenn du es "von Hand" machen willst im SELECT:
https://www.firebirdsql.org/refdocs/lan ... first-skip
SELECT FIRST xx SKIP YY Spalte1, Spalte2 blabblablabla

Bsp. SELECT FIRST 100 SKIP 500 Spalte1, Spalte2 FROM EineTabelle ORDER BY Spalte1
"Hole die ersten 100 Sätze ab, nachdem du die ersten 500 übersprungen hast"

Mal nebenbei: Finde die Syntax von Firebird echt grässlich.

Wobei ich jetzt aus dem Stegreif nicht weiss, ob man Parameter bei LIMIT verwenden kann bzw. bei Firebird, ob man FIRST und SKIP Parametrieren kann

Und wie es die anderen mehrfach erwähnt haben: SELECT * FROM ist ein Ressourcen-Fresser
In deiner Tabelle hast du z. B. 30 Spalten, anzeigen kannst du aber nur 10 in deinem Grid.
Die 10 Spalten die du anzeigst, sind Text und Zahlen --> ergibt pro Satz als Hausnummer 500 Bytes, die durch die Leitung müssen.
Mal 10.000 --> 5.000.000 Bytes
Von den 30 Spalten sind es aber 5 Blobs (Bilder, PDF's, was weiss ich), wo du "dicke" Dinger drin hast
Mit einem SELECT * FROM holst du jetzt pro Zeile aber 10MB ab (weil z.B. Fotos in den Blobs sind).
Nimm das mal 10.000, was du dann durch die Leitung quetschen willst, ABER NICHT BRAUCHST.

Faustregel: Hole nur das ab, was du wirklich brauchst.
Und das ist jetzt schon mehrfach gesagt worden.

Da du ein DBGrid verwendest, gehe ich mal von aus, du nutzt auch eine DataSource und die "visuelle" TSQLQuery-Komponente.
Denk dran: Lazarus versucht die InsertSQL, UpdateSQL und DeleteSQL anhand deines SELECT's zu "erraten".
Wird dann mit einem SELECT * FROM natürlich dann "interessant"

Auch die "Komplexität" der Abfrage hat Einfluss auf Performance,
als auch verwendte/vorhandene Indizes
Wie schon erwähnt:
Falls du ORDER BY hast: Index auf Sortierfeld
Falls du JOINs hast: Index auf die Verknüpfungsfelder
Falls du WHERE-Klausel hast: Index auf Filter-Spalten

[charlytango]

Auch die "Komplexität" der Abfrage hat Einfluss auf Performance,
als auch verwendte/vorhandene Indizes
Wie schon erwähnt:
Falls du ORDER BY hast: Index auf Sortierfeld
Falls du JOINs hast: Index auf die Verknüpfungsfelder
Falls du WHERE-Klausel hast: Index auf Filter-Spalten

völlig richtig, aber auch ohne dass ich schon ein Performance Problem habe, sehe ich mir an, wie die komplexeren Statements von der Datenbank interpretiert und eingesetzt werden. Das gehört als DB-Entwickler einfach dazu.
Und dazu gibt es in jedem SQL Server Möglichkeiten, um die man sich eben kümmern muss.

Auch wenn ich ich wiederhole, solche Datenmengen in einem Frontend sind absolut unbrauchbar. Da muss unbedingt der Geschäftsfall bzw Anwendungsfall und die angedachte Nutzung hinterfragt werden.

Geht es um das Finden von Patienten, braucht es ausgefeilte Suchkriterien, gegebenenfalls auch unscharfe Suchen auch mit Soundex.
Wenn es keine exakten Kriterien zum Suchen gibt (wie zb Patientennnummer oder Sozialversicherungsnummer) dann eben unscharfe Suche mit dem Ziel bis maximal 10 Ergebnisse zu bekommen aus denen der Anwender analog auswählen kann.

Der Rest riecht stark nach Auswertungen, Reports und Datenexport.
Das ist eine völlig andere Schiene, die man auch gerne mal mit Bordmitteln des SQL Servers lösen kann. Das ging auch schon mal so weit dass ich Daten in eine andere Datenbank (des nachts) repliziert habe, die dann mit Report Tools ausgewertet wurde. Alleine nur aus Sicherheitsgründen, damit kein wildgewordenes Tool oder ein wohlmeinender Benutzer nicht schnell mal eine Tabelle löscht. (mit Berechtigungen löse ich so etwas nicht, getrennte Systeme halte ich für sicherer)
So ein Vorgehen hat auch den Vorteil dass man Daten dem Benutzer mittels Views aufbereiten kann und das Reporting nicht die Performance der Hauptdatenbank beeinflusst.

Denn wenn das passiert steht dann wieder eineandere Abteilung vor dir und beschwert sich weil "nix geht"

[Zvoni]

Mal ein Exkurs aus dem wahren Leben:
In der Firma, wo ich arbeite, haben wir ein "Industry-Grade"-ERP-System (Grosshandel mit 800 Mitarbeitern weltweit).
Und nein: Es ist nicht SAP

Alle Fenster, welche ein Grid anbieten ist das Grid selbst auf 30 "sichtbare" Zeilen begrenzt.

Ruft ein User jetzt in so einem Fenster Daten ab, werden IMMER nur die 50 ersten Datensätze gem. seinem Kriterium geladen.
Scrollt der User jetzt nach unten (und somit wandern die Datensätze nach "oben"), werden in dem Moment, wo der 50-ste Datensatz "sichtbar" wird, die NÄCHSTEN 50 Sätze abgeholt usw.
Will ein User explizit das "volle Brett" muss er per bestimmter Tasten-Kombination dieses explizit anfordern.
Aber sogar hier ist bei max. 5000 Sätzen Schluss.

Sollte vielleicht zu denken geben, in wieweit 10.000 Ergebnis-Sätze Sinn ergeben

[Zvoni]

Zur grundsätzlichen Frage aus dem ersten Post:
Es gibt kein "AfterShow" bzw. "AfterPaint"-Ereignis (was du eigentlich bräuchtest).

Das einzige was mir dazu einfällt, wäre im OnShow- oder OnActivate-Ereignis als LETZTE Anweisung einen Timer zu starten, der z.B. nach 2 Sekunden dann deine Abfrage ausführt, und dann das Grid füllt.
Hier muss dann ggfs. eine Sperrvariable benutzt werden, um das wiederholte Ausführen zu verhindern, wenn z.B. auf ein andere Fenster gewechselt wird.

Eine zweite Variante wäre, einen separaten Thread zu starten, der die Abfrage selbst ausführt.
In dem Fall wäre der Aufbau des Fensters von der Abfrage, welche dich derzeit "blockiert" von einander getrennt.
Hier muss man dann auf die Synchronisierung achten

[Andy Nightingale]

Mal ein Exkurs aus dem wahren Leben:
In der Firma, wo ich arbeite, haben wir ein "Industry-Grade"-ERP-System (Grosshandel mit 800 Mitarbeitern weltweit).
Und nein: Es ist nicht SAP

Alle Fenster, welche ein Grid anbieten ist das Grid selbst auf 30 "sichtbare" Zeilen begrenzt.

Ruft ein User jetzt in so einem Fenster Daten ab, werden IMMER nur die 50 ersten Datensätze gem. seinem Kriterium geladen.
Scrollt der User jetzt nach unten (und somit wandern die Datensätze nach "oben"), werden in dem Moment, wo der 50-ste Datensatz "sichtbar" wird, die NÄCHSTEN 50 Sätze abgeholt usw.

Hallo Zvoni, jipiii ja genau das: Ruft ein User jetzt in so einem Fenster Daten ab, werden IMMER nur die 50 ersten Datensätze gem. seinem Kriterium geladen.
Scrollt der User jetzt nach unten (und somit wandern die Datensätze nach "oben"), werden in dem Moment, wo der 50-ste Datensatz "sichtbar" wird, die NÄCHSTEN 50 Sätze abgeholt Wie geht das denn ganz genau.-hast du da ein Beispiel? Supi

[Zvoni]

Mal ein Exkurs aus dem wahren Leben:
In der Firma, wo ich arbeite, haben wir ein "Industry-Grade"-ERP-System (Grosshandel mit 800 Mitarbeitern weltweit).
Und nein: Es ist nicht SAP

Alle Fenster, welche ein Grid anbieten ist das Grid selbst auf 30 "sichtbare" Zeilen begrenzt.

Ruft ein User jetzt in so einem Fenster Daten ab, werden IMMER nur die 50 ersten Datensätze gem. seinem Kriterium geladen.
Scrollt der User jetzt nach unten (und somit wandern die Datensätze nach "oben"), werden in dem Moment, wo der 50-ste Datensatz "sichtbar" wird, die NÄCHSTEN 50 Sätze abgeholt usw.

Hallo Zvoni, jipiii ja genau das: Ruft ein User jetzt in so einem Fenster Daten ab, werden IMMER nur die 50 ersten Datensätze gem. seinem Kriterium geladen.
Scrollt der User jetzt nach unten (und somit wandern die Datensätze nach "oben"), werden in dem Moment, wo der 50-ste Datensatz "sichtbar" wird, die NÄCHSTEN 50 Sätze abgeholt Wie geht das denn ganz genau.-hast du da ein Beispiel? Supi

Hatte ich doch geschrieben....

Dafür gibts die Eigenschaft PacketRecords:
https://www.freepascal.org/docs-html/fc ... cords.html
Bsp. PacketRecords = 50 --> wird immer "50"-iger-weise abgeholt

Wenn du es "von Hand" machen willst im SELECT:
https://www.firebirdsql.org/refdocs/lan ... first-skip
SELECT FIRST xx SKIP YY Spalte1, Spalte2 blabblablabla

Bsp. SELECT FIRST 50 SKIP x*50 Spalte1, Spalte2 FROM EineTabelle ORDER BY Spalte1
"Hole die ersten 50 Sätze ab, nachdem du die ersten x*50 übersprungen hast"

und "x" ist für die ersten 50 halt "0", die nächsten 50 ist X=1 usw.
Von Hand ist es halt deutlich komplizierter, weil man sich da mit FIRST und SKIP gewaltig vertun kann

Bsp. erster Aufruf
SELECT FIRST 50 SKIP 0 Spalten... From tabelle
Holt die ersten 50 Sätze ab

Jetzt rufst du aber neu auf
SELECT FIRST 50 SKIP 50 Spalten...FROM Tabelle ab
Da gehen die ersten 50 über Bord! Die sind dann nicht mehr da!

Stattdessen:
SELECT FIRST 100 SKIP 0 Spalten...FROM Tabelle
Damit bekommst du die ersten 100..... und laufst irgendwann in dein Problem rein, dass du mit einer Abfrage das ganze Brett haben willst.

Lange Rede, gar kein Sinn: PacketRecords austesten, bevor man überhaupt auch nur dran denkt, das von Hand zu machen

[Andy Nightingale]

Lange Rede, gar kein Sinn: PacketRecords austesten, bevor man überhaupt auch nur dran denkt, das von Hand zu machen

Hallo Zvoni,
verstehe....danke dir werde es mal austesten gebe dir bescheid....Grüße