Das Problem sind nach wie vor die großen Datenmengen. Die Table Komponente kommt damit nicht zu recht.
Mit "FetchAll" true dauert der Open Befehl viel zu lange und mit "FatechAll" false kommen die genannten Fehlermeldungen.
[...]
Das kommt mir aber sehr umständlich vor. Das müsste auch anders gehen.
Das Suchen musst du dem Server überlassen - genau dafür ist er da und optimiert. Sobald du anfängst große Datenmengen vom Server zu holen und dann erst auszuwerten, baust du dir solche Probleme ins Projekt ein.
Wir haben genau die selbe Situation hier gehabt und haben dann schweren Herzens auf Queries umgestellt, die nach Möglichkeit alle Auswertungen auf dem Server ausführen. Am Ende hat es sich aber gelohnt. Der Serverzugriff ist extrem beschleunigt und Probleme durch zu große Ergebnissätze gibt's auch nicht mehr.
Genau so ist es richtig. Die Eingangsfrage beschreibt ja eine Lost Connection. Sowas hatte ich auch mal. Da sind zwei Faktoren zusammen gekommen: Die Konstruktion des Clients führte zu übergroßen Datenabfragen und der
Mysql-Server war mit zu kleinen Caches konfiguriert. Denn bevor sie über
TCP/
IP auf die Reise geschickt werden, müssen die Daten vorher erstmal auf dem Server zusammengestellt werden. Dabei lief ihm ein Puffer über und der Server hat der
TCP-Verbindung einfach die Türe zugeschlagen.
Suchen sollte man niemals clientseitig. Das funktioniert eine Weile, wenn man an der Umgebung nichts ändert. Aber dann kommen vllt. neue Arbeitsplätze dazu, die Serverlast steigt und schon sind die alten Probleme wieder da. In den vorherigen Posts wurde schon beschrieben, wie man mit WHERE-Klauseln und Queries arbeitet. Nachdem ich das Prinzip erstmal verstanden hatte, arbeite ich inzwischen ausschließlich mit Queries und gar nicht mehr mit Table-Komponenten. Locate geht auch auf
Query-Objekten, manchmal macht das Sinn um in Schleifen kein Datenbank-Pingpong zu bauen. Aber immer nur auf eingegrenzten Datenmengen, nie über eine ganze physische Tabelle.