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

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

Gruß Michael, ZeosDevTeam

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

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

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.

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