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.

[Lemmy]

habe mydac mit Lazarus am Laufen unter Linux. Keine Problem, auch beim Verarbeiten großer (also wirklich großer) Datenmengen.

Zitat:

Zitat von Edelfix (Beitrag 1547656)

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.

scnr: Wer mit locate und DBMS arbeitet, hat eh jegliche Kontrolle verloren ;-)

Vergiss es einfach. vergiss irgendwelche Tablekomponenten.

nimm Querykomponenten, nimm spezialisierte SQL, die genau das tun, was du willst, und nur das.

Bitte verzeih, wenn ich das nicht explizit raus suche:
Ich habe mal eine BDE Anwendung auf Postgresql umgebaut und dabei pgDac verwendet. Und natürlich für die Umbauzeit TTable mit TpgTable ersetzt. Aber selbst für die Übergangszeit war das ne "sch****" selbst der Support hat mir damals geschrieben: TxTable Komponenten sind eigentlich nicht für einen wirklichen Einsatz gedacht.

[Medium]

Ich kann ähnliche Erfahrungen bei der Nutzung von *Table Komponenten berichten. Wir haben ein Produkt von Uralt (Paradox + BDE, ganz früher lief das sogar noch unter DOS (ja, TurboPascal) mit dBASE) auf MySQL umgestellt. Erst mit den Zeos-Komponenten. Als dann das Lizenzgeraffel mit MySQL anfing kamen wir zu MyDAC, und haben seit ein paar Jahren auch das DBMS auf MariaDB umgestellt.

Während all dieser Zeit haben wir immer noch hier und da *Table Komponenten mitgeschleppt, die immer wieder zu Problemen diversester Art geführt haben. Der gedankliche Schritt von der alten BDE-like Arbeitsweise hin zu vernünftigen SQL-Queries ist am Anfang ungewohnt, aber es lohnt sich!!

[Frickler]

Zitat:

Zitat von Lemmy (Beitrag 1547667)

scnr: Wer mit locate und DBMS arbeitet, hat eh jegliche Kontrolle verloren ;-)

Vergiss es einfach. vergiss irgendwelche Tablekomponenten.

Und dann ersetzt man

Delphi-Quellcode:

tbl.Tablename := 'Blubb';
tbl.Filter := 'artikelnr = 4711';
tbl.Filtered := true;
tbl.Open;
if tbl.FindFirst then begin
  repeat
    tbl.Edit;
    tbl.FieldByName('bla').AsBoolean := false;
    tbl.Post;
  until not tbl.FindNext;
end;
tbl.Close;

durch

Delphi-Quellcode:

qry.SQL.Text := 'SELECT * FROM Blubb WHERE artikelnr = 4711';
qry.Open;
while not qry.Eof do begin
  qry.Edit;
  qry.FieldByName('bla').AsBoolean := false;
  qry.Post;
  qry.Next;
end;
qry.Close;

...und hat "von Table auf Query umgestellt" :-)

Wer Verschlüsselung nutzen will mit den DevArt-Komponenten, ist sogar gezwungen, das so zu machen...

[Bernhard Geyer]

Zitat:

Zitat von Frickler (Beitrag 1547688)

Delphi-Quellcode:

qry.SQL.Text := 'SELECT * FROM Blubb WHERE artikelnr = 4711';

Und jetzt auch noch parametrisierte perpared Abfragen und man wird schneller und sichererer ...

[fisipjm]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1547696)

Zitat:

Zitat von Frickler (Beitrag 1547688)

Delphi-Quellcode:

qry.SQL.Text := 'SELECT * FROM Blubb WHERE artikelnr = 4711';

Und jetzt auch noch parametrisierte perpared Abfragen und man wird schneller und sichererer ...

Das ist richtig und wichtig!
Also wenns wirklich nur so eine "Billo" Aufgabe ist würde ich das sogar komplett in einen Einzeiler Paken :-D
Sparst dir dadurch das ganze Cursor-Geschubse in gänze.

Delphi-Quellcode:

qry.Execute('UPDATE Blubb SET bla=:bla WHERE artikelnr = :artikelnr',[false,4711]);
...

Solange die SQL Query eine Connection hat, brauchst du dich um nichts mehr kümmern. Außer du brauchst natürlich die SQL danach wieder um die Daten darzustellen, dann würde ich es wahrscheinlich so lösen.

Delphi-Quellcode:

qry.connection.Execute('UPDATE Blubb SET bla=:bla WHERE artikelnr = :artikelnr',[false,4711]);
qry.open('SELECT * FROM Blubb WHERE artikelnr = :artikelnr ',[4711]);

[Lemmy]

Zitat:

Zitat von Frickler (Beitrag 1547688)

...und hat "von Table auf Query umgestellt" :-)

boah ernsthaft? Den Satz habe ich geschrieben, dass man das halt auch nicht mahcen soll, ihn dann aber wieder gelöscht vor dem Post :-)

Zitat:

Zitat von Frickler (Beitrag 1547688)

Wer Verschlüsselung nutzen will mit den DevArt-Komponenten, ist sogar gezwungen, das so zu machen...

wie meinen?

[Edelfix]

Unsere Tabellen Komponenten sind immer mit einem DBGrid verbunden. Das DBGrid liegt auf einer Form aber die Table Komponente auf einem DataModul. Auch wenn die Maske grad nichts anzeigt so ist die Table von überall erreichbar. Es wird von unterschiedlichen Stellen aus ein Locate gemacht dann der Datnsatz (fals gefunden) in ein Record geladen und dann verarbeitet oder im DBGrid angezeigt.
Bis jetzt war das eine Zeile mit Locate. Wir mussten uns nicht darum kümmern ob das Locate dafür da ist ein Datensatz zu holen oder im Grid zu positionieren. Und davon etwas 2.000 mal im Projekt.
Jetzt muss ich mit „LIMIT 100“ für das DBGrid arbeiten und dafür sorgen das der gesucht Datensatz bei den 100 dabei ist um dann im DBGrid darauf zu positionieren oder nur ein Datensatz um dann mit einem Record zu arbeiten.
Der SQL Befehl währe dann:
1. Ich brauche eine separate SQL Komponente um den Datensatz zu suchen.
2. Jetzt der SQL Aufruf mit LIMI 100 und OFFSET (gesuchter Datensatz).
3. Und noch mit Locate im DBGrid auf den Datensatz positionieren.
Das ist mehr als nur eine Zeile.

[Olli73]

Anstatt alle Stellen im Code anzupassen, erstellst du dir eine eigene Komponente TMyTable, abgeleitet von TfdQuery, die du dann überall verwendest. Die erweiterst / überschreibst du dann so, dass du von außen damit arbeitest wie mit einer F(fd)Table Komponente, aber intern eine Query für die benötigten Datensätze verwendet wird. Z.B. überschreibst du das Locate mit der Vorgehensweise wie du sie im letzten Beitrag beschrieben hast.

Oder, wenn möglich, steigst du auf Firebird um (siehe mein vorheriger Beitrag).

[MyRealName]

Falls Du DevExpress noch zusätzlich im Einsatz hast, dann gibt es dort den Servermode. Der sucht auf dem Server und holt sich immer nur durch clevere Queries was er im Grid gerade anzeigt, auch beim Scrollen

[Edelfix]

Die Idee von Olli73 klingt vielversprechend.

Danke.

[Frickler]

Zitat:

Zitat von Lemmy (Beitrag 1547699)

Zitat:

Zitat von Frickler (Beitrag 1547688)

Wer Verschlüsselung nutzen will mit den DevArt-Komponenten, ist sogar gezwungen, das so zu machen...

wie meinen?

Aus einer Frage im DevArt-Forum:

Zitat:

Please note that to encrypt data, you must pass values to the dataset fields.

To insert or modify an encrypted field, use the Append/Insert/Edit... Post methods and set the SQL expression to "SELECT..." (instead of "INSERT/UPDATE") for the TIBCQuery.SQL.Text property.

Da gehts zwar um IBDAC, aber was die Verschlüsslung angeht, verhalten sich bei DevArt alle *DACs gleich.
(siehe https://support.devart.com/portal/en...-tibcencryptor)

...aber wir schweifen ab!

@Edelfix: Was für eine Datenbank habt Ihr denn benutzt, bevor Ihr auf MariaDB gewechselt habt?

[Edelfix]

@Frickler. Wir nutzen die ADS (Advantage Database Server). Ist aber von SAP aufgekauft und eingestampft worden. Zum Glück läuft die DB noch.
Es kommt aber der Tag an dem ein Windows Update dafür sorgen wird das die DB einfach nicht mehr startet. Da müssen wir gegen wirken.

[Sinspin]

Oh ja, same same. So schön wie er ist, der ADS Server. Aber irgendwann geht er nicht mehr. Wir werden wohl auf Postgres wechseln.

[Frickler]

Ein Leidensgenosse!

Wir stellen aktuell alles um auf Firebird. Was etwa Reporting-SQL angeht, erreiche ich z.T. die sechsfache Geschwindigkeit wie bei ADS.

Wir hatten auch NexusDB ins Auge gefasst, weil das ein Server ist, der auch auf Tabellenkomponenten - ganz ohne SQL wenn man will - serverbasierte Cursor erlaubt. Zudem liegt er komplett im Quelltext vor, und man kann ihn mit Plugins erweitern. Dafür gibt es Defizite beim SQL, es geht z.B. kein MERGE oder sowas wie "UPDATE OR INSERT" bei Firebird. Und keine berechneten Indexe.
Wir machen aber relativ wenig mit purem ISAM, praktisch alle Datenbearbeitung, Grids und DBEDits, Reporting usw. basiert bei uns auf von der Datenbank entkoppelten ClientDataSets.

P.S.: Firebird ist vor allem auch einfach zu installieren. Wir bereiten eine sogenannte "ZIP-Installation" vor, die muss beim Kunden nur noch in einen Ordner entpackt werden. Dann noch den Service per CMD Datei installieren, und das wars schon.

[Sinspin]

Wir haben Postgres schon für eine Hardware Schnittstelle laufen. Zugriff via FD (FireDac) ist ganz einfach.
Da wir schon für ADS auf die FD Komponenten umgestiegen sind sollte / müsste ich auch dann keine größere Probleme haben.
Das witzige ist, ADS läuft mit den FD Komponenten schneller als mit den ADS eigenen.

[Olli73]

Zitat:

Zitat von Frickler (Beitrag 1547806)

Ein Leidensgenosse!

Wir stellen aktuell alles um auf Firebird.
...
Wir hatten auch NexusDB ins Auge gefasst, weil das ein Server ist, der auch auf Tabellenkomponenten - ganz ohne SQL wenn man will - serverbasierte Cursor erlaubt.

Kann Firebird doch auch...

[Frickler]

Zitat:

Zitat von Olli73 (Beitrag 1547822)

Zitat:

Zitat von Frickler (Beitrag 1547806)

Wir hatten auch NexusDB ins Auge gefasst, weil das ein Server ist, der auch auf Tabellenkomponenten - ganz ohne SQL wenn man will - serverbasierte Cursor erlaubt.

Kann Firebird doch auch...

ISAM (also Tabelle, nicht Query, mit Filter, Range und Co) mit serverbasiertem Cursor kann Firebird nicht. Die Zugriffskomponenten wie IBDAC, FireDAC etc können das mit allerlei SQL simulieren, aber nativ geht es nicht.

[Edelfix]

Ein Update für alle die auch mit MariaDB und MyDac Probleme haben.

Konnte alle aktuellen Probleme auf einen schlag lösen.
Wenn man möchte das MyDac so mit MariaDB arbeitet wie die ADS Komponenten mit der ADS Datenbank dann nimmt man am besten FireDac Komponenten.

Wir sind auf FireDac gewechselt und haben als erstes festgestellt das FireDac Komponenten in Delphi 10.4 zu alt sind und die entsprechende Fehlermeldung hat uns auch darauf hingewiesen.

Jetzt sind wir auf Delphi 12.3 gewechselt und die FireDac Komponenten arbeiten wunderbar. Wir können die ADS Komponenten eins zu eins austauschen.

[Codehunter]

Zitat:

Zitat von fred.ahrens (Beitrag 1547659)

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.

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.