MyDac Erfahrung

[Edelfix]

Hallo,

hat jemand die MyDac Komponente im Einsatz?
Die Komponente setze ich aktuell zum ersten mal ein aber es kommt in unterschiedlichsten Situationen zu der gleichen Fehlermeldung:

"Lost connection to MySQL server during query".

Die Fehlermeldung scheint beliebig oft in unterschiedlichsten Situationen zu feuern.
Zum Beispiel:
Bei "Locate" mit einer TMYTable oder TMYQuery. Aber nicht jedes mal. Ein Haltepunkt hilft nicht da die Fehlermeldung nicht jedes mal kommt.

Oder bei "Close" mit TMYTable oder TMYQuery.
Oder bei "Disconnect" mit der TMYConnection. Eigentlich jedes mal.

Die Datenbank liegt auf unserem Server im Büro. Also Intranet.
Devart meinte dazu das ich die Stellen mit try except einklammern soll und auf den Fehlertype: EMySqlException einfach nicht reagieren soll.
Das klingt für mich nicht ausgereift.

Hat jemand ähnliche Erfahrungen?

[Bbommel]

Wir nutzen nicht MyDAC, sondern UniDAC, aber ich würde mal vermuten, dass dort "unter der Haube" im Falle einer Anbindung an MySQL/MariaDB ziemlich viel ähnliches passiert. Den "MySQL"-Teil von UniDAC nutzen wir seit gut fünf Jahren für eine interne Anwendung und das läuft bisher völlig stabil und zuverlässig. Exceptions der von dir beschriebenen Art habe ich so im Alltag nicht.

Insofern kann ich dir bei deinem konkreten Problem leider nicht helfen, aber die Rückmeldung geben, dass ich nicht den Eindruck habe, dass das unausgereift ist.

[Alfredo]

Ich nutze aus Lizenzgründen nicht MySQL sondern MariaDB(10.9.4) und damit läuft
MyDac völlig ohne Probleme.

Domänen-Client mit Windows 10 und Zugriff auf Windows Server(PDC).

[Bernhard Geyer]

Welchen Verbindungstyp nutzt du?
Native ohne irgendwelche libmysql.dll's?

Und nutzt du "serverseitige Curser"?
Das dürfte MariaDB wie MySQL nicht können und wir das mit einem "Trick" simuliert.

[Edelfix]

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.

Jetzt kann der Hinweis das man mit SQL Arbeiten soll und LIMIT verwenden.

Jetzt habe ich aber festgestellt das der Befehl "Locate" nur in der im Client befindlichen Menge sucht.
Wenn ich "LIMIT 100" einstelle dann findet "Locate" nur etwas in den 100. Wenn der Datensatz gerade nicht dabei ist dann wird auch nichts gefunden.
Die Daten haben Lücken und unterschiedliche Nummernkreise. Sie sind nicht einfach fortlaufend.

Der Vorschlag von ChatGPT ist eine drei Stufen Lösung.
1. Mit einer separaten Query nach dem Datensatz suchen.
2. Weitere 100 holen mit dem "Offset" auf die gefundene ID damit im DBGrid nicht nur der gefundene Datensatz erscheint.
3. Jetzt mit "Locate" auf den gesuchten Datensatz im Grid positionieren.

Das kommt mir aber sehr umständlich vor. Das müsste auch anders gehen.

[fred.ahrens]

Zitat:

Zitat von Edelfix (Beitrag 1547646)

Hallo,

... "Lost connection to MySQL server during query". ...

Hat jemand ähnliche Erfahrungen?

Das kann leider viele Ursachen haben. Oft kann man dazu aber auf dem Server im Log gute Hinweise zur Ursache bekommen.

Wir hatten das oft im Zusammenhang mit Tabellen, in denen wir BLOBs verwendet haben. Da ist schnell mal der Speicher voll, wenn man in der Konfiguration nicht die Blockgrößen angepasst hat. Ähnlich bei Tabellen mit prall gefüllten Memofeldern.
Ab und zu hatten wir das auch, wenn Serverversion und Version der Client-DLL nicht gut zueinander passten.

[Bernhard Geyer]

Zitat:

Zitat von Edelfix (Beitrag 1547656)

Das kommt mir aber sehr umständlich vor. Das müsste auch anders gehen.

Nö. Du kannst nicht alles haben.
Und wenn du eine DBMS nutzt, da z.B. keine Serverseitigen Curser hat (mit den Nachteilen, wenn man diese Nutzt), dann musst du halt "drumherum" arbeiten.

Aber auch wenn man diese hat. Wer schaut sich schon am Client Mio. Datensätze in einem Grid an.

Selbst haben wir ein 2stufige Logik um Grid mit "mehr als 5 Einträgen" hin zu bekommen
1, Hole alle Primärschlüssel
2, Beim Anzeigen im Grid hole Rest für diesen Datensatz

Zusätzlich gibt es ein Limit wie viele Primärschlüssel geholt werden dürfen/sollen.

[fred.ahrens]

Zitat:

Zitat von Edelfix (Beitrag 1547656)

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.

[Frickler]

In MySQL gibt es noch so einen obskuren Zugriffsmodus namens "Handler". Der funktioniert wohl ähnlich wie beim guten alten dBase mit "Tabelle öffnen", "Index setzen", "nächsten Datensatz anfahren" usw. Soll angeblich deutlich schneller sein als per "Select". Man kann ihn in "MyTable" mit der Option "UseHandler" einschalten.
Siehe https://docs.devart.com/mydac/devart...usehandler.htm
Vielleicht bringt das ja was.

[Olli73]

Zum Glück hatte ich mich damals mit Firebird als Datenbank durchgesetzt. Wir haben nämlich, von der BDE kommend, sehr viele Table Komponenten im Einsatz. Mit Firebird kann man Server-Cursor mit Filter und Locate etc. nutzen. Zumindest mit FireDAC wird das dann alles am Server ausgeführt.