DBGRID und Daten laden

Für Fragen von Einsteigern und Programmieranfängern...
Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 7216
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: DBGRID und Daten laden

Beitrag von af0815 »

Joh hat geschrieben: Mo 16. Mär 2026, 18:19
af0815 hat geschrieben: Mo 16. Mär 2026, 15:57 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...
Ich habe MS-SQL (auch unter Linux) im Programm und dort auch etliche (Admin und Programmier) Kurse von M$ oder SQLite aus Hobby. Und ich will mir das System nicht mit ungewollten Servern (und den Libs und configs) vollstopfen. Mit Firebird (bzw. damals Interbase) habe ich vor Jahren mal herumgekämpft (zusammen mit Delphi), aber beschlossen das wir nicht besonders gute Freunde werden.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Andy Nightingale
Beiträge: 388
Registriert: Mo 13. Jan 2025, 12:11

Re: DBGRID und Daten laden

Beitrag von Andy Nightingale »

charlytango hat geschrieben: Mo 16. Mär 2026, 10:49

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.
Danke Charlytango.- ich verstehe was du meinst.-Danke für die tolle Erklärung.-muß mir das alles durch den Kopf gehen lassen 8)

Andy Nightingale
Beiträge: 388
Registriert: Mo 13. Jan 2025, 12:11

Re: DBGRID und Daten laden

Beitrag von Andy Nightingale »

Joh hat geschrieben: Mo 16. Mär 2026, 18:19
af0815 hat geschrieben: Mo 16. Mär 2026, 15:57 Wenn man was mit Server testen wollte, so wäre SQLite eine Alternative.
oder Firebird als Embedded Version.

Hallo Joh,
ja ich habe damit angefangen und ich finde es bis jetzt auch sehr gut. Soweit ich das überhaupt beurteilen kann.-aber bis jetzt kann ich nichts negatives sagen. Was ich dich fragen wollte.-wie kann man denn die Tabellen Namen ändern.-bei mir wird das immer automatisch in Großbuchstaben gemacht.-das ist so das einzige was nervt...Grüße

Andy Nightingale
Beiträge: 388
Registriert: Mo 13. Jan 2025, 12:11

Re: DBGRID und Daten laden

Beitrag von Andy Nightingale »

af0815 hat geschrieben: Mo 16. Mär 2026, 15:57 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.

Wenn man was mit Server testen wollte, so wäre SQLite eine Alternative.
Hallo 0815.- super.-Danke dir für das tolle Beispiel. :D

Benutzeravatar
Zvoni
Beiträge: 601
Registriert: Fr 5. Jul 2024, 08:26
OS, Lazarus, FPC: Windoof 10 Pro (Laz/FPC fixes)
CPU-Target: 64Bit
Wohnort: BW

Re: DBGRID und Daten laden

Beitrag von Zvoni »

af0815 hat geschrieben: Mo 16. Mär 2026, 15:57 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.
Wie kommst du denn auf das dünne Brett???!?!??!
https://www.freepascal.org/docs-html/fc ... ocate.html
https://www.freepascal.org/docs-html/fc ... tions.html

Code: Alles auswählen

 public function TDataSet.Locate(
  const KeyFields: string;
  const KeyValues: Variant;
  Options: TLocateOptions  //<---!!
):Boolean; virtual;

type TLocateOptions = set of (
  loCaseInsensitive,  //Perform a case-insensitive search
  loPartialKey  //Accept partial key matches for string fields

);
Ein System sie alle zu knechten, ein Code sie alle zu finden,
Eine IDE sie ins Dunkel zu treiben, und an das Framework ewig zu binden,
Im Lande Redmond, wo die Windows drohn.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 7216
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: DBGRID und Daten laden

Beitrag von af0815 »

Zvoni hat geschrieben: Di 17. Mär 2026, 08:10
af0815 hat geschrieben: Mo 16. Mär 2026, 15:57 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.
Wie kommst du denn auf das dünne Brett???!?!??!
Teste es mit dem Beispiel mal aus, genau deswegen habe ich es erstellt. Da ist keine SQL-DB im Hintergrund. Damit arbeitet nur das nackte Locate und es wird nichts über einen Treiber in Hintergrund vielleicht gemacht. Da geht es IMHO nicht. Oder ich habe irgendwas sehr falsch gemacht (was ja nicht sein kann :-) ).

Einfach starten , dann die Daten initialisieren und "101" im Suchfeld eingeben, dann sollte er zu den Daten wo 101 drinnenstehen hinspringen. Macht er nicht. Er akzeptiert schon einen Teil des Keys, ABER immer nur vom Begin des Strings an, nicht aus der Mitte heraus. Und Wildcards gibt es hier nicht. Steht auch nichts in der Doku (und auch nichts im Quelltext).
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Benutzeravatar
Zvoni
Beiträge: 601
Registriert: Fr 5. Jul 2024, 08:26
OS, Lazarus, FPC: Windoof 10 Pro (Laz/FPC fixes)
CPU-Target: 64Bit
Wohnort: BW

Re: DBGRID und Daten laden

Beitrag von Zvoni »

af0815 hat geschrieben: Di 17. Mär 2026, 08:17
Zvoni hat geschrieben: Di 17. Mär 2026, 08:10
af0815 hat geschrieben: Mo 16. Mär 2026, 15:57 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.
Wie kommst du denn auf das dünne Brett???!?!??!
Teste es mit dem Beispiel mal aus, genau deswegen habe ich es erstellt. Da ist keine SQL-DB im Hintergrund. Damit arbeitet nur das nackte Locate und es wird nichts über einen Treiber in Hintergrund vielleicht gemacht. Da geht es IMHO nicht. Oder ich habe irgendwas sehr falsch gemacht (was ja nicht sein kann :-) ).

Einfach starten , dann die Daten initialisieren und "101" im Suchfeld eingeben, dann sollte er zu den Daten wo 101 drinnenstehen hinspringen. Macht er nicht. Er akzeptiert schon einen Teil des Keys, ABER immer nur vom Begin des Strings an, nicht aus der Mitte heraus. Und Wildcards gibt es hier nicht. Steht auch nichts in der Doku (und auch nichts im Quelltext).
Hmmm.....könntest recht haben.
Hab mal tief in die Source geschaut.

Dann halt über "Filter/Filtered/FilterOptions".
Da weiss ich dass es geht, da ich es schon selbst verwendet habe.
Und "Filter" akzeptiert SQL-ähnliche Syntax.
aber: z.B. LIKE mag es nicht, kann man aber mit u.g. Syntax "umgehen"
aus meinem eigenen Code

Code: Alles auswählen

grdOverviewEmployees.DataSource.Dataset.Filter:='FullName=''*'+txtFilter.Text+'*''';
grdOverviewEmployees.DataSource.Dataset.FilterOptions:=[foCaseInsensitive];
grdOverviewEmployees.DataSource.Dataset.Filtered:=True;            
Ein System sie alle zu knechten, ein Code sie alle zu finden,
Eine IDE sie ins Dunkel zu treiben, und an das Framework ewig zu binden,
Im Lande Redmond, wo die Windows drohn.

Joh
Lazarusforum e. V.
Beiträge: 345
Registriert: Sa 26. Mai 2012, 17:31
OS, Lazarus, FPC: Win 10 (L 2.2.6 x64 FPC 3.2.2)
CPU-Target: 64Bit

Re: DBGRID und Daten laden

Beitrag von Joh »

Zvoni hat geschrieben: Di 17. Mär 2026, 08:45 Dann halt über "Filter/Filtered/FilterOptions".
Da weiss ich dass es geht, da ich es schon selbst verwendet habe.
Und "Filter" akzeptiert SQL-ähnliche Syntax.
aber: z.B. LIKE mag es nicht, kann man aber mit u.g. Syntax "umgehen"
aus meinem eigenen Code
wenn mich meine Erinnerung nicht täuscht:
nimm statt Filter ServerFilter/ServerFiltered; da geht auch LIKE; und das wird dann (dem Namen nach) auch nicht lokal als Filter ausgeführt, sondern auf dem DB-Server...
just my two Beer

Benutzeravatar
Zvoni
Beiträge: 601
Registriert: Fr 5. Jul 2024, 08:26
OS, Lazarus, FPC: Windoof 10 Pro (Laz/FPC fixes)
CPU-Target: 64Bit
Wohnort: BW

Re: DBGRID und Daten laden

Beitrag von Zvoni »

Joh hat geschrieben: Di 17. Mär 2026, 08:57
Zvoni hat geschrieben: Di 17. Mär 2026, 08:45 Dann halt über "Filter/Filtered/FilterOptions".
Da weiss ich dass es geht, da ich es schon selbst verwendet habe.
Und "Filter" akzeptiert SQL-ähnliche Syntax.
aber: z.B. LIKE mag es nicht, kann man aber mit u.g. Syntax "umgehen"
aus meinem eigenen Code
wenn mich meine Erinnerung nicht täuscht:
nimm statt Filter ServerFilter/ServerFiltered; da geht auch LIKE; und das wird dann (dem Namen nach) auch nicht lokal als Filter ausgeführt, sondern auf dem DB-Server...
BINGO!!!
https://www.freepascal.org/docs-html/fc ... ilter.html
If the dataset is active and ServerFiltered is set to true, then changing this property will re-fetch the data from the server.
Gute Erinnerung!
Ein System sie alle zu knechten, ein Code sie alle zu finden,
Eine IDE sie ins Dunkel zu treiben, und an das Framework ewig zu binden,
Im Lande Redmond, wo die Windows drohn.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 7216
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: DBGRID und Daten laden

Beitrag von af0815 »

Das Server Filtered geht hier ja nicht, weil IMHO nicht vom Server gefetched wird (bzw. werden soll), siehe auch die ersten Post hier im Thread !!. Damit wird es ja auf den Server zurückgereicht und ursprünglich war die Idee ja, das vom Server in Chunks zu holen und Lokal zu suchen. Was somit nicht wirklich geht.
In dem Moment wo du einen Server dahinter hast, wird das ganze in Where mit ev. Like im SQL-Statement gemapped und das wurde ja vorgeschlagen zu vermeiden, weil der Kunde ja nicht weis, was er suchen will, sondern alles haben will.

Das es mit Server geht, wenn man ungefähr weis, was man will, war ja nie in Diskussion.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Benutzeravatar
Zvoni
Beiträge: 601
Registriert: Fr 5. Jul 2024, 08:26
OS, Lazarus, FPC: Windoof 10 Pro (Laz/FPC fixes)
CPU-Target: 64Bit
Wohnort: BW

Re: DBGRID und Daten laden

Beitrag von Zvoni »

af0815 hat geschrieben: Di 17. Mär 2026, 09:27 Das Server Filtered geht hier ja nicht, weil IMHO nicht vom Server gefetched wird (bzw. werden soll), siehe auch die ersten Post hier im Thread !!. Damit wird es ja auf den Server zurückgereicht und ursprünglich war die Idee ja, das vom Server in Chunks zu holen und Lokal zu suchen. Was somit nicht wirklich geht.
In dem Moment wo du einen Server dahinter hast, wird das ganze in Where mit ev. Like im SQL-Statement gemapped und das wurde ja vorgeschlagen zu vermeiden, weil der Kunde ja nicht weis, was er suchen will, sondern alles haben will.

Das es mit Server geht, wenn man ungefähr weis, was man will, war ja nie in Diskussion.
Doch. Genau um das gehts.
Andy holt die ersten 50 oder 100 Sätze ab, ohne Filter.
Nicht das ganze Brett

Kunde fangt an einen Suchbegriff einzugeben. (Sagen wir: Erster Treffer ist eben nicht in den ersten 100 Sätzen, sondern erst bei Satz 3000)
ServerFilter würde jetzt anhand des Filters NEU die ersten 50 oder 100 Sätze abholen, die dem Kriterium entsprechen.

Es ist unbestritten, dass "Traffic" entsteht, aber bedingt durch das PacketRecord bzw. SELECT FIRST 100 blablabla
halt dann doch nicht so viel
Ein System sie alle zu knechten, ein Code sie alle zu finden,
Eine IDE sie ins Dunkel zu treiben, und an das Framework ewig zu binden,
Im Lande Redmond, wo die Windows drohn.

charlytango
Beiträge: 1250
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: DBGRID und Daten laden

Beitrag von charlytango »

af0815 hat geschrieben: Di 17. Mär 2026, 09:27 weil der Kunde ja nicht weis, was er suchen will, sondern alles haben will.
Sorry, das geht über meinen Verstand.
Wenn der Anwender nicht weiß mit welchem Teil der Daten er arbeiten will dann ist das so als ob ich bei Kastner & Öhler (einem bekannten Kaufhaus) anrufe und denen sage sie sollen mit aus dem Sortiment irgend etwas schicken worüber ich mich sicher freue ;-)

Entweder ich arbeite in einer Datenbank mit einer begrenzten Zahl von Objekten oder ich mache Auswertungen irgend einer Art und Dimension. (aber auch da sollte man wissen was man auswerten will)
Welcher Anwender wünscht sich bei jeder Suche 50k Records am Schirm durchzusuchen?

Da steht ein Kunde vor mir und ich muss erst die 50k Liste durchsuchen?

Ich würde sagen die haben ihre Geschäftsprozesse nicht im Griff - egal ob das eine Lehreinrichtung ist oder nicht.

Kompliment an @af0815 -- du scheinst ein gerüttelt Maß an Langmut aufgebaut zu haben ;-)

Andy Nightingale
Beiträge: 388
Registriert: Mo 13. Jan 2025, 12:11

Re: DBGRID und Daten laden

Beitrag von Andy Nightingale »

charlytango hat geschrieben: Di 17. Mär 2026, 14:46
af0815 hat geschrieben: Di 17. Mär 2026, 09:27 weil der Kunde ja nicht weis, was er suchen will, sondern alles haben will.
Welcher Anwender wünscht sich bei jeder Suche 50k Records am Schirm durchzusuchen?

Da steht ein Kunde vor mir und ich muss erst die 50k Liste durchsuchen?


Ich würde sagen die haben ihre Geschäftsprozesse nicht im Griff - egal ob das eine Lehreinrichtung ist oder nicht.

Kompliment an @af0815 -- du scheinst ein gerüttelt Maß an Langmut aufgebaut zu haben ;-)
Hallo Charlytango, so war es nicht gemeint. Der Anwender "Die Lehreinrichtung" hat bei meiner alten Datenbank Software sogar eine halbe Million Records auf dem Schirm. .-und natürlich sucht er nicht alle einzeln durch.-sondern ich hatte oben bei der Tabelle ca. 20 Suchbuttons für verschiedene Szenarien. Der Professor oder die Mitarbeiter im Labor mußten dann einfach den Button mit der richtigen Suche anklicken und in Sekunden waren dann alle Datensätze da die gesucht wurden..-So ähnlich muß ich es mit Lazarus umsetzen.-egal was ihr selbst nun darüber denkt.-das Szenario ist so wie ich es gesagt habe. Punkt. Es ist nicht dein Szenario oder dein Kunde sondern diese Software lief und lauft seit jetzt über 15 Jahre. Genau das muß ich nun umsetzen.-das ist alles und dafür suche ich eben Hilfe hier. Und die blöden AUssagen wie: Ich würde sagen die haben ihre Geschäftsprozesse nicht im Griff - egal ob das eine Lehreinrichtung ist oder nicht. Ist einfach nur Unwissenheit und nicht angebracht.-weil du mich dann hier als Dumm hinstellst.

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 7216
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: DBGRID und Daten laden

Beitrag von af0815 »

Das heißt einfach 20 Varianten der Wurde Klausel hinterlegen, hinter den Buttons. OK die Erklärung jetzt war brauchbar und erklärt vieles. Somit ist die Mächtigkeit der Daten eingeschränkt.

Nur wäre die Info so viel früher sinnvoll gewesen. Bei einer Desktop Datenbank hast du natürlich die ganzen Datensätze einmal lokal und schränkst dann er ein. Bei Server willst du gar nicht noch alles haben, sonder nur das was bereits Eingeschränkt ist.

Es ist eine grundlegend andere Denkweise. Du hast die Landkarte in zB. Hessen vor dir gehabt und wir von Bayern. Deswegen ist aneinander vorbei diskutiert worden. Ach ja, Norden sollte auch überall oben sein, dann passt es.

Und ja, wenn ein Kunde nicht sagen kann, was er sucht und es immer schon so gemacht hat, dann muss man wirklich genauer Hinterfragen. Ich habe ein gewachsenes Management System auf Datenbank umstellen dürfen, es gibt nichts, was es nicht gibt. Seither glaube ich keinen Bericht mehr. Nicht einmal denen, die selbst erstellt habe. Weil Manager oft keine Realität wollen, sondern nur erfolgreiche Ziele lt. Ihren Zielvereinbarungen und keine Tatsachen.
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

charlytango
Beiträge: 1250
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: DBGRID und Daten laden

Beitrag von charlytango »

Andy Nightingale hat geschrieben: Di 17. Mär 2026, 15:45 weil du mich dann hier als Dumm hinstellst.
Das ist eine üble Unterstellung -- du hast uns hier im Kreis laufen lassen mit einem Bruchteil der nötigen Informationen.
Schon ein Screenshot deiner alten Umgebung zu Beginn deines Posts hätte diesen in eine ganz andere Richtung gelenkt.

Allerdings wundere ich mich stark warum du da nicht in meiner Antwort hellhörig geworden bist.
Ob du nun Buttons zur Einschränkung des Suchergebnisses verwendest oder freie Eingabefelder ist für das Erstellen der jeweiligen WHERE Klauseln egal. Das Prinzip ist immer das gleiche.
Andy Nightingale hat geschrieben: Di 17. Mär 2026, 15:45 Der Anwender "Die Lehreinrichtung" hat bei meiner alten Datenbank Software sogar eine halbe Million Records auf dem Schirm.
Genau diese Aussage hat uns alle nach
af0815 hat geschrieben: Di 17. Mär 2026, 22:38Bayern.
geführt. Denn deine Anwender hatten und haben immer nur den sichtbaren Bereich im Grid auf dem Schirm -- der Rest wird (hoffentlich) dynamisch nachgeladen. Auch bei einer Desktop Datenbank wie bei dBase Derivaten und Konsorten.

Vermutung: Du hattest wohl zuerst einen Teil der Daten am Schirm angezeigt und der Benutzer konnte "einschränken". Jetzt wäre es einfach umgekehrt -- der Benutzer sieht erstmal keine Daten und eine "Einschränkung" (also ein Klick auf erwähnte Buttons) bringt das Ergebnis in den Grid.

Hier habe ich das ohnehin schon erklärt - und ob es Suchmasken oder Buttons sind ist für die Programmlogik egal:
charlytango hat geschrieben: Mo 16. Mär 2026, 10:49 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
Wenn du mit Buttons arbeitest, ist die Navigation für den Benutzer in den Möglichkeiten eingeschränkter, für dich in der Programmlogik einfacher.
Arbeitest du mit Eingabefeldern wird es einfach komplexer im Programm.
Irgendwann landet man bei einem Objekt das einem die SELECT Statements dynamisch On The Fly zusammen baut.

Ein Klick auf einen deiner Suchbuttons verändert einfach die WHERE Klausel in deinem SELECT und schickt es an die Datenbank.

Wenn du dabei Hilfe brauchst, zeig uns einen Screenshot der alten Maske.

Ich habe eine banale Frage - und bekomm sie bitte nicht wieder in den falschen Hals .
Wielange hast du deinen Anwendern zugesehen wie sie dein Programm benutzt haben?

Nach Abgabe eines Programms (nur die großen - von 100 Manntagen aufwärts) habe ich mich immer mindestens einen halben Tag hinter Anwender gesetzt und zugesehen wie sie das Programm bedienten und ermittelt wo die Flaschenhälse im Ablauf waren. Habe auch hinterfragt warum sie irgend einen Arbeitschritt genaus so gemacht haben, wenn er mir unlogisch oder ineffizient schien. Danach habe ich das Programm angepasst.

Meine Erfahrung ist ähnlich wie die von af0815 :
af0815 hat geschrieben: Di 17. Mär 2026, 22:38 Und ja, wenn ein Kunde nicht sagen kann, was er sucht und es immer schon so gemacht hat, dann muss man wirklich genauer Hinterfragen.
Der Kunde weiß in den seltensten Fällen was er wirklich braucht, denn verständlicherweise hat er ja keine Ahnung von den bestehenden Möglichkeiten.

Nur ein Beispiel von unzähligen: Verwaltungsprogramm für einen Verlag. Der Anzeigenverkäufer hat versucht sich seine Daten die er in einem Gespräch mit dem Kunden braucht, aus dem Verwaltungsprogramm heraus zu suchen. Das hat er immer so gemacht. Das dauert, deswegen hat er uns genervt warum einzelne Teile der Suche (die für völlig andere Zwecke optimiert war) so kompliziert sind. Bis ich mal vor Ort war und ihm bei der Arbeit zusah. Danach haben wir eine spezielle Tabelle mit redundanten Daten automatisch in der Datenbank erzeugen lassen und ihm die nötigen Daten mit einem Click in unter einer Sekunde auf den Schirm gestellt. Mit Interaktivität einer Pivot Tabelle.
Seine Kunden am Telefon waren ab dann erstaunt wieso er sich all diese Zahlen merken konnte ;-)

Antworten