DBGRID und Daten laden

[Andy Nightingale]

Hallo Zvoni zwischen durch eine Verständnisfrage. Damit ich nichts falsch mache. Wenn ich per Scroll immer wieder 50 Datensätze lade.- und das von den mindestens ca. 100 Laborassistenten sagen wir 50 auch machen.- ist da die Überlastung nicht schon vorprogrammiert? Weil alle hier sagen: ist doch bescheuert keiner braucht soviel Daten im Frontend.....bei meiner alten Datenbank .-war das aber so.- da die Hauptaufgabe der Arbeit Daten suche ist.-Jetzt meine Frage.-wenn nicht alle Datensätze geladen sind.-wie kann man dann in allen Datensätzen suche?? Vielleicht verstehe ich euch ja nicht richtig.
Ich habe jetzt mal einen Test gemacht.
Wenn ich mit ZQuery in der Eigenschaft SQL folgendes eingebe: SELECT FIRST 100 SKIP 0 * FROM PATIENT ORDER BY PatientID dann ladet die Grid enorm schnell. Dann habe ich einen Button gemacht mit folgender Anweisung:

Code: Alles auswählen

procedure TFPatient.ButtonWeiterClick(Sender: TObject);
var
  OriginalCaption: string;
begin
  // Fenstertitel sichern und ändern
  OriginalCaption := Self.Caption;
  Self.Caption := 'Einen Moment bitte die Daten werden geladen dauert ein paar Sekunden :-)...';
  Application.ProcessMessages; // Sofort anzeigen

  // Query ausführen
  zQueryPatient.Close;
  zQueryPatient.SQL.Text := 'SELECT FIRST 1000000 SKIP 100 * FROM PATIENT ORDER BY PatientID';
  zQueryPatient.Open;

  // Fenstertitel zurücksetzen
  Self.Caption := OriginalCaption;
end;    

....dann ladet es alle Daten und ich kann .--wie es die Leute wollen.-- nach allem suchen und in der Zwischenzeit ist nichts mehr blockiert. Verstehe ich das so richtig? Weil jedes Grid (Tabelle) hat oben an die 10 Suche Buttons die aber in allen Daten suchen müssen.- das ist das wichtigste für meinen Kunden.

[Andy Nightingale]

charlytango post_id=154842 time=1773388193 user_id=4352

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.



Hallo Charly Tango,
in meiner letzten integrierten Datenbank Software ist aber genau dies der Fall. Es geht meinem Kunden genau darum aus "Allen"Daten suchen zu können und nicht nur Häppchenweise. Wie kann man in einer Datenbank komplett suchen wenn nicht alle Daten vorhanden sind. In meinem letzten Tool konnte mein Kunde genau das. (Siehe meine jetzige Lösung an Zvoni ).- vielleicht verstehe ich ja die Suchoption bei Lazarus falsch....was wahrscheinlich ist.-aber wie geht es dann???

[Zvoni]

Dir ist aber klar, dass in deinem zweiten Query, die ersten 100 Sätze fehlen?

Und was verstehst du mit "Suchen"?
geben die Leute in einem Textfeld ein Suchkriterium ein?

Zum Verständnis:
Ein DBGrid ist per se zum Anzeigen (!!) des darunterliegenden DataSets.
In einem DBGrid wird aber nicht gesucht, sondern im darunterliegenden DataSet.

Test:
1) Setze PacketRecords auf 100
2) Führe dein SELECT aus OHNE EINSCHRÄNKUNGEN!! --> SELECT * FROM Tabelle ORDER BY Irgendwas (Kein FIRST, kein SKIP)
Und nein: SELECT * FROM werde ich nicht mehr diskutieren.
3) Führe eine "Suche" auf das Dataset aus, und zwar mit einem Suchkriterium, wo du genau weisst, dass es erst bei Satz 500 auftaucht
Siehe hierzu auch "Locate"-Funktion des Dataset
4) Wird der Satz gefunden? Ja/Nein

[af0815]

Gesucht wird immer über die WHERE Klausel.

Beispiel "SELECT Datum1, DatenFeld1, DatenFeld2 FROM Tabelle WHERE Datenfeld1 like '%was%ich%suche' ORDER BY Datum1 ASC"

Bei höheren Firebird Versionen gibt es IMHO schon die Möglichkeit mit RegEx ähnlichen zu suchen (SIMILAR TO https://www.firebirdsql.org/refdocs/lan ... ar-to.html )

Die meisten großen Serverhersteller haben da so ihre Möglichkeiten eingebaut, natürlich jeder mit einer komplett anderen Syntax
Bsp: https://www.mssqltips.com/sqlservertip/ ... ql-server/

Like ist natürlich auch eine Geschwindigkeitsbremse am Server, daher ist es günstig die where Klausel soweit wie möglich Einschränkend zu verwenden.

[Andy Nightingale]

Test:
1) Setze PacketRecords auf 100
2) Führe dein SELECT aus OHNE EINSCHRÄNKUNGEN!! --> SELECT * FROM Tabelle ORDER BY Irgendwas (Kein FIRST, kein SKIP)
Und nein: SELECT * FROM werde ich nicht mehr diskutieren.
3) Führe eine "Suche" auf das Dataset aus, und zwar mit einem Suchkriterium, wo du genau weisst, dass es erst bei Satz 500 auftaucht
Siehe hierzu auch "Locate"-Funktion des Dataset
4) Wird der Satz gefunden? Ja/Nein
[/quote]

Hallo Zvoni,
komme einfach nicht voran. Es gibt einfach kein Beispiel mit dem Bufdataset....das mit dem was ich ja schon mein Grid und meine Datenbank verbinde zeigt wie das geht...Ich habe beim ZQuery das mit der ZConnection verbunden ist...dann hab ich Datasource das mit ZQuery verbunden ist....und dann hab ich das Grid das mit der Datasource verbunden ist. Das Bufdataset kann ich mit nichts verbinden.-kann zwar PacketRecords auf 100 setzen...aber ist ja mit nichts verbunden. Ich finde das ist der größte Nachteil von Lazarus.-einfach keine umfangreiche Dokumentation und nur sehr wenig Beispiele.. Man verbringt die meiste ZEit eigentlich mit "Ausprobieren". Kannst du mir sagen wie das geht? Grüße

[af0815]

Ich finde das ist der größte Nachteil von Lazarus.-einfach keine umfangreiche Dokumentation und nur sehr wenig Beispiele.. Man verbringt die meiste ZEit eigentlich mit "Ausprobieren".

Ich vermute anhand deiner Schnippsel, das du ZEOS verwendest. ZEOS ist nicht Lazarus, sondern ein extra eigenständiges Projekt. Die Doku findet man u.a. hier https://sourceforge.net/projects/zeosli ... f/download
Falls meine Annahme richtig ist, würde es auch schön sein, zu wissen ob SQLdb oder ZEOS. Die beiden Produkte unterscheiden sich optisch nicht besonders, dafür aber in der Tiefe.

Nur so nebenbei, wenn man nach Doku sucht. Auch die Lazarus Wiki ist genaugenommen ein wüster Schatz an Information, auch zu Empfehlen.

[af0815]

Weil alle hier sagen: ist doch bescheuert keiner braucht soviel Daten im Frontend.....bei meiner alten Datenbank .-war das aber so.- da die Hauptaufgabe der Arbeit Daten suche ist.-Jetzt meine Frage.-wenn nicht alle Datensätze geladen sind.-wie kann man dann in allen Datensätzen suche?? Vielleicht verstehe ich euch ja nicht richtig.

Eine Frage die sich mir stellt - wie wird was gesucht ?

Normalerweise fragt man den User in welchen Feld er suchen will und was er sucht. Damit habe ich 2 Sachen erreicht - Der User sagt mir in welchen Feld in der Datenbank er suchen will und auch was er erwartet zu finden. Vielleicht auch noch einen Zeitraum wo gesucht wird. Weil oft sind die Daten vom vorigen Jahr (oder Monat / Quartal) ja "Schnee von gestern".

Weil man kann auf viele Arten in unterschiedlichen Datentype suchen.

[charlytango]

Es geht meinem Kunden genau darum aus "Allen"Daten suchen zu können und nicht nur Häppchenweise. Wie kann man in einer Datenbank komplett suchen wenn nicht alle Daten vorhanden sind. In meinem letzten Tool konnte mein Kunde genau das.

Möglicherweise liegt das ein Konzeptproblem oder Verständnisproblem vor.
Kann es sein dass dein letztes Tool eine Flat-File Datenbank wie ein dBase Derivat zugrunde liegen hat?
Sollte das der Fall sein, haben womöglich auch deine Kunden eine Flat-File Denkweise, die bei Server-gestützten Datenbanken kaum Sinn macht.

Natürlich arbeiten deine Kunden IMMER mit der "ganzen" Datenbank.
Aber sie "sehen sich" nur immer den Teil davon an, den sie gerade brauchen.
Das ist einfach eine andere Art effizient mit großen Datenmengen umzugehen.

Egal, ob es eine Kundendatenbank ist, oder eine Patientendatenbank.
Man sucht immer zuerst den Teil der Daten mit denen man gerade arbeiten will.
zb einen bestimmten Kunden, eine bestimmte Rechnung einen bestimmten Patienten. -- um dann ausgehend von diesen Teil der Daten andere Elemente wie Rechnung, Behandlungen, Kosten, Schemata etc nachzuladen.

Einen Anwender durch eine wie immer geartete Liste von 50 tausend Zeilen zu jagen ist einfach ineffizient.
Daher sind intelligent ausgefeilte "Suchmasken" für mich der Schlüssel zur Zufriedenheit der Anwender.
hier zum Beispiel zwei Masken aus meinen Programmen

kundensuche.png (9.49 KiB) 149 mal betrachtet

kurssuche.png (12.98 KiB) 149 mal betrachtet

Die Suchmasken erzeugen im Hintergrund on the fly die passenden WHERE-Klauseln.
Die Strategie dabei ist es von einer präzise granulierten Abfrage zu unspezifischeren Anwendungsfällen alles abdecken zu könnne

Fall 1: der Anwender weiß zb eine Kundennummer, oder Patientennummer dann findet man einen einzigen Datensatz und gut ists.

Fall 2: der Anwender weiß nur unscharfe Daten -- Namensteile, Teileder Patentennummer oder Sozialversicherungsnummer, oder andere Daten oder Teildaten.
Dann wird es tricky und das (mein) Ziel ist es dem Anwnder eine kurze Liste mit passenden Ergebnissen anzuzeigen aus dennen er quasi analog den passenden Datensatz auswählt um damit weiter arbeiten zu können.

Alles so ausgefeilt dass der Anwender kaum merkt was da alles im Hintergrund passiert. Solche Anwendungsfälle sind dann auf Effizienz und Geschwindigkeit optimiert.

Solche Suchmasken können hochkomplex sein, dass zb schon bei drei Buchstaben gesucht wird. oder im Hintergrund auch phonetische SOUNDEX Suchen ablaufen um dem Anwender möglichst schnell ein sinnvolles Ergebnis zu geben.

Wie gesagt, der Anwender soll aus dem von ihm eingeschränkten Ergebnis dann analog auswählen und je treffsicherer seine Abfrage, desto kleiner das Ergebnis zur Auswahl.

Da man auch nach Teilen von Informationen suchen kann findest sich fast immer schnell der richtige Datensatz - Pareto-Regel -- in 80% der Fälle geht es blitzschnell, aber der Anwender kann damit auch eine Tiefensuche ausführen, die dann auch gefühlt länger dauern darf.

In einigen Fällen erlaube ich auch dass man gar keine Suchparameter eingibt und auf "Suchen" drückt. Dann erscheint nochmal eindialog der abfragt ob man diese (lang dauernde) Suche dann überhaupt möchte.
Dann gibt es auch kein Problem mit den Anwendern.

[Zvoni]

Gesucht wird immer über die WHERE Klausel.

Beispiel "SELECT Datum1, DatenFeld1, DatenFeld2 FROM Tabelle WHERE Datenfeld1 like '%was%ich%suche' ORDER BY Datum1 ASC"

Ein klares "Jein" hierzu.

Statt bei jedem "OnChange" des Suchkriteriums ein neues SELECT abzufeuern, würde ich eher über die "Filter/Filtered/FilterOptions"-Eigenschaften gehen, die vom Prinzip wie eine WHERE-Klausel funktioniert, aber kein neues SELECT abfeuert

https://www.freepascal.org/docs-html/fc ... ilter.html

Was ich jetzt aber auch nicht weiss, ist wie es sich im Zusammenspiel mit PacketRecords verhält.

Beispiel: Frisch aufgerufen sind die ersten 50 Sätze vorhanden, und dann werden die Filter gesetzt.
Ist das Dataset jetzt so schlau, den Filter auch auf den "Rest" anzuwenden?
Weil falls Nein, dann hat af0815 recht: Muss per WHERE-Klausel ein neues SELECT abgefeuert werden.

[Andy Nightingale]

Test:
1) Setze PacketRecords auf 100
2) Führe dein SELECT aus OHNE EINSCHRÄNKUNGEN!! --> SELECT * FROM Tabelle ORDER BY Irgendwas (Kein FIRST, kein SKIP)
Und nein: SELECT * FROM werde ich nicht mehr diskutieren.
3) Führe eine "Suche" auf das Dataset aus, und zwar mit einem Suchkriterium, wo du genau weisst, dass es erst bei Satz 500 auftaucht
Siehe hierzu auch "Locate"-Funktion des Dataset
4) Wird der Satz gefunden? Ja/Nein
[/quote]

Hallo Zvoni,
komme einfach nicht voran. Es gibt einfach kein Beispiel mit dem Bufdataset....das mit dem was ich ja schon mein Grid und meine Datenbank verbinde zeigt wie das geht...Ich habe beim ZQuery das mit der ZConnection verbunden ist...dann hab ich Datasource das mit ZQuery verbunden ist....und dann hab ich das Grid das mit der Datasource verbunden ist. Das Bufdataset kann ich mit nichts verbinden.-kann zwar PacketRecords auf 100 setzen...aber ist ja mit nichts verbunden. Hast du da ein Beispiel wie man das handhabt? Grüße

[Zvoni]

Test:
1) Setze PacketRecords auf 100
2) Führe dein SELECT aus OHNE EINSCHRÄNKUNGEN!! --> SELECT * FROM Tabelle ORDER BY Irgendwas (Kein FIRST, kein SKIP)
Und nein: SELECT * FROM werde ich nicht mehr diskutieren.
3) Führe eine "Suche" auf das Dataset aus, und zwar mit einem Suchkriterium, wo du genau weisst, dass es erst bei Satz 500 auftaucht
Siehe hierzu auch "Locate"-Funktion des Dataset
4) Wird der Satz gefunden? Ja/Nein

Hallo Zvoni,
komme einfach nicht voran. Es gibt einfach kein Beispiel mit dem Bufdataset....das mit dem was ich ja schon mein Grid und meine Datenbank verbinde zeigt wie das geht...Ich habe beim ZQuery das mit der ZConnection verbunden ist...dann hab ich Datasource das mit ZQuery verbunden ist....und dann hab ich das Grid das mit der Datasource verbunden ist. Das Bufdataset kann ich mit nichts verbinden.-kann zwar PacketRecords auf 100 setzen...aber ist ja mit nichts verbunden. Hast du da ein Beispiel wie man das handhabt? Grüße

1) Du nutzt ZEOS --> Hab ich null Erfahrung mit (noch nie gebraucht, geschweige denn, dass ich woanderst hin müsste wegen Dokumentation). sqldb reicht mir vollkommen
2) Das Dataset von dem ich rede sitzt unterhalb von "DataSource", welches mit dem DBGrid verbunden sein sollte
also irgendwas in der Art

MyGrid.DataSource.Dataset.... --> und eben hier mit locate bzw. Filter-Eigenschaft testen

[Andy Nightingale]

Gesucht wird immer über die WHERE Klausel.

Beispiel "SELECT Datum1, DatenFeld1, DatenFeld2 FROM Tabelle WHERE Datenfeld1 like '%was%ich%suche' ORDER BY Datum1 ASC"

Bei höheren Firebird Versionen gibt es IMHO schon die Möglichkeit mit RegEx ähnlichen zu suchen (SIMILAR TO https://www.firebirdsql.org/refdocs/lan ... ar-to.html )

Die meisten großen Serverhersteller haben da so ihre Möglichkeiten eingebaut, natürlich jeder mit einer komplett anderen Syntax
Bsp: https://www.mssqltips.com/sqlservertip/ ... ql-server/

Like ist natürlich auch eine Geschwindigkeitsbremse am Server, daher ist es günstig die where Klausel soweit wie möglich Einschränkend zu verwenden.

Danke 0815

[Andy Nightingale]

1) Du nutzt ZEOS --> Hab ich null Erfahrung mit (noch nie gebraucht, geschweige denn, dass ich woanderst hin müsste wegen Dokumentation). sqldb reicht mir vollkommen
2) Das Dataset von dem ich rede sitzt unterhalb von "DataSource", welches mit dem DBGrid verbunden sein sollte
also irgendwas in der Art

MyGrid.DataSource.Dataset.... --> und eben hier mit locate bzw. Filter-Eigenschaft testen
[/quote]

Hallo Zvoni.-versteh.-danke dir trotzdem

[af0815]

Ich habe mich kurz mit dem Locate herumgespielt. Naja optimal ist das nicht, weil es keine Wildcards und somit keine Teile innerhalb eines Strings suchen kann.
Das Projekt ist ohne Datenbank und erzeugt die Daten im einem BufDataset selbst, nur für den Test mit Locate. Damit gehen sich nicht die Spielereien die man auf einem SQL-Server machen kann. Sondern das arbeitet in dem Buffer von dem Zvoni gesprochen hat.

Aber wie gesagt, ohne Serveranbindung, weil ich will mir auf meinem System keinen fremden Server einschleppen.

Wenn man was mit Server testen wollte, so wäre SQLite eine Alternative.

[Joh]

Wenn man was mit Server testen wollte, so wäre SQLite eine Alternative.

oder Firebird als Embedded Version.

Aber da bist du ja gar kein Freund von; ich finds super...