"MySQL Server has gone away" bei Datensatzwechsel

[Codehunter]

Moin!

Wenn ich mit einem TDBEdit einen Feldinhalt ändere und dann der Datensatz gewechselt wird ohne die Änderung per ApplyUpdates zu committen, dann rummst es mit der Fehlermeldung "MySQL Server has gone away". Diese Fehlermeldung/Exception kann ich insofern ignorieren, wenn ich gleich danach noch ein ApplyUpdates nachschiebe.

Jetzt ist die Frage: Ist das jetzt nur eine ziemlich unpassende Fehlermeldung seitens ZEOS, ist es ein Bug in ZEOS oder sollte ich generell vor einem Datensatzwechsel per ApplyUpdates/CancelUpdates entscheiden was mit Änderungen passieren soll?

Grüße
Cody

[EgonHugeist]

??? Du kannst du mal 'nen Schnipsel zusammenfummeln, um das nachvollziehen zu können? Welche Settings nutzt du hier?

Gruß Michael, ZeosDevTeam

[Bernhard Geyer]

Ich kenn das Problem nur wenn man große Blobdateien übertragen will die größer sind als die Default-Einstellung von 1 MB.

[EgonHugeist]

Nun Bernhard, das sollte sich mit "SET GLOBAL max_allowed_packet=x" z.b. 16*1024*1024 lösen lassen. Zeos bietet hier auch die Option TZConnection.Properties.Values['Chunk_Size'] := xxx; 4096 Bytes default an, um die Pakete dem Network-Speed anzupassen. Macht jedoch nur Sinn, wenn man die TZDataSet.Options := [coPreferePrepared], setzt und somit auf die total buggy MySQL CAPI für PreparedStatments zu greift: http://dev.mysql.com/doc/refman/5.0/...-problems.html

Die haben es seit 4.x und bis heute nicht hinbekommen, das zu mal zu fixen. Außerdem existieren da Funktionen, wie mysql_stmt_param_metadata siehe http://dev.mysql.com/doc/refman/5.1/...-metadata.html die uuuuuunnnnendlich lang existieren, um dem CAPI Problem auf die Sprünge zu helfen, doch NIXXXXXXX da.. MySQL..

Doch ich denke bei CodeHunter läuft da was anderes schief und es wäre schön dem, im Gegensatz zu MySQL, nachkommen zu können.

Gruß Michael

[Bernhard Geyer]

Zitat von EgonHugeist:

Nun Bernhard, das sollte sich mit "SET GLOBAL max_allowed_packet=x" z.b. 16*1024*1024 lösen lassen.

Weiß ich. Und genau ist es ja das der Blob + alles Drum herum (SQL-Statement + sonstiges) maximal dieser Grenze entsprechend dürfen. D.h. das Blob darf evtl. nur 900 kB groß sein bis es kracht.

Zitat von EgonHugeist:

Die haben es seit 4.x und bis heute nicht hinbekommen, das zu mal zu fixen. Außerdem existieren da Funktionen, wie mysql_stmt_param_metadata siehe http://dev.mysql.com/doc/refman/5.1/...-metadata.html die uuuuuunnnnendlich lang existieren, ...

Das ist ja geil
Aber warte - Wir hatten/haben in unserem DB-Modell auch ab und zu Systemfelder definiert die als "zur späteren" Verwendung schon mal angelegt waren aber nie verwendet wurden.

[EgonHugeist]

Zitat von Bernhard Geyer:

Zitat von EgonHugeist:

Nun Bernhard, das sollte sich mit "SET GLOBAL max_allowed_packet=x" z.b. 16*1024*1024 lösen lassen.

Weiß ich. Und genau ist es ja das der Blob + alles Drum herum (SQL-Statement + sonstiges) maximal dieser Grenze entsprechend dürfen. D.h. das Blob darf evtl. nur 900 kB groß sein bis es kracht.

Zitat von EgonHugeist:

Die haben es seit 4.x und bis heute nicht hinbekommen, das zu mal zu fixen. Außerdem existieren da Funktionen, wie mysql_stmt_param_metadata siehe http://dev.mysql.com/doc/refman/5.1/...-metadata.html die uuuuuunnnnendlich lang existieren, ...

Das ist ja geil
Aber warte - Wir hatten/haben in unserem DB-Modell auch ab und zu Systemfelder definiert die als "zur späteren" Verwendung schon mal angelegt waren aber nie verwendet wurden.

Ja seh ich ein. Einziges Problem hier bei MySQL: Es gibt keine weitere Möglichkeit LOB's in Chunks zu senden. Die Größe derer hängt jedoch immer vom Networkspeed ab, um eine optimale Performance zu erreichen. MySQL bietet ja schon noch die Möglichkeit Strings für die PreparedStatements zu verwnden : http://dev.mysql.com/doc/refman/5.0/...tatements.html (fummle ich grade als Alternative bei Zeos rein), dann hat man aber keinen Einfluß mehr auf die Paketgrößen. Die vorher beschriebene "Option" echt nur wegen MySQL vorhanden, else -> Bugreports. Hmpf deren Mailer-Liste sollte schon überlaufen, doch ich geb die Hoffnung langsam Richtung auf, seit MySQL Oracle owned ist.

Grüße Michael

[Bernhard Geyer]

Zitat von EgonHugeist:

..., doch ich geb die Hoffnung langsam Richtung auf, seit MySQL Oracle owned ist.

Ob Oracle überhaupt ein Interesse an ein stabiles MySQL hat? Die verkaufen doch lieber für den 10-100fachen Preis einen Oracle-Server ...

Für ein Produkt ist es immer schlecht wenn in kurzer Zeit 2* ein Verkauf statt gefunden hat (MySQL -> Sun -> Oracle). Da passiert es oft das wichtige Entwickler kündigen und das Prukt erstmal lange zeit vor sich in "gammelt". Die Erfahrung hatte ich vor Jahren mit ERWin welche nach 2 maligen Kauf bei CA gelandet ist und dort innerhalb von 3 Jahren als einziges nennenswertes Feature ein geänderter Startbildschirm eingebaut wurde.

[EgonHugeist]

Da stoßen wir ins gleiche Horn, denke ich. Persönliche Meinung: Niemand wird sich weiter für MySQL entscheiden außer aus kompatibilitäts Gründen. Neue Nutzer bei derzeitiger Preisgestaltung ..... beeeeeep. Keine Neuen Nutzer, kein Geld fürs weiterentwickeln (so würde ich es jedenfalls machen -> klare Trennung der Geschäftsbereiche), deadline is somit schon mal gesetzt. Wollte eigentlich mal vor 2 Wochen auf die FOSDEM, um Monty nach dem Fortschritt zu MariaDB zu befragen (libmariadb.dll is Libmysql 3.2.5 (letzte freie GPL von MySQL)), doch hatte die Zeit nicht gefunden. Hoffen wir Monty legt 'nen Zahn zu und macht es einfach besser.

Edit: Zum Thema zurück, Codehunter, kannst du mir irgendwas zusammenbasteln? Optimal wäre dieser Weg: http://zeos.firmos.at/viewtopic.php?t=3671

[Codehunter]

Bitte denkt nicht dass ich mich zu dem Thema nicht mehr melde. Bin nur grad gesundheitlich etwas out of Order.

Zu meinem Problem aus dem Eröffnungspost: Ich bin noch dabei, das genau nachzustellen. Das Symptom war, dass die Meldung kam wenn ich mehrere Datenmengen gleichzeitig mit einer TZConnection verbunden hatte, eine davon Aktiv war und die zweite Aktiv werden wollte. Ich habe diesen Entwicklungsstand bei meinem Projet fixiert und dort tritt der Fehler auf zuverlässig auf. Allerdings kriege ich bisher kein Testprojekt dazu, den selben Fehler zu produzieren.

In der betreffenden Datenmenge kamen keine BLOB-Felder vor, wohl aber TEXT-Felder, die wohl irgendwo artverwandt sind.

Bzgl. libmariadb ist mein Kenntnisstand, dass die derzeit veröffentlichte DLL (ganz unten) ist auf dem selben Stand wie libmysql 5.5. Als Basis wurde die letzte libmysql 3.x unter der LGPL verwendet. Bisher konnte ich eine aktuelle libmysql und eine aktuelle libmariadb beliebig austauschen und an einem MySQL-Server 5.5 verwenden.

[Bernhard Geyer]

Zitat von Codehunter:

In der betreffenden Datenmenge kamen keine BLOB-Felder vor, wohl aber TEXT-Felder, die wohl irgendwo artverwandt sind.

Die MySQl-Einstellung max_allowed_packet ist hier unabhängig vom Feldtyp. Wenn du sehr "breite" Tabellen hast und der Parameter z.B. auf 5 kByte steht kann es dir auch bei normalen integer/varchar-Felder passieren.