mariovaldez.net

I'm sure this has been covered elsewhere however i could not find anything directly referencing this.

When modifying large numbers of products and you have to stop for a moment, when you return and try to save the changes, two things happen.

1: The product does not save, or upload image.
2: Disconnected from server, takes 3 tries to reconnect.



may not be really a bug, but is there a way to keep the SQL server alive regardless of how long the client idles?

I can deal with it, but it would be nice to either stay connected, or have the client continue to retry searching, modifying, or uploading an image regardless of its connection status, even if it has to create a new session.

just some idea's

Thanks,
David.

_________________
http://www.shadow.net

David:

> I'm sure this has been covered elsewhere however
> i could not find anything directly referencing this.
> When modifying large numbers of products and you
> have to stop for a moment, when you return and try
> to save the changes, two things happen.
> 1: The product does not save, or upload image.
> 2: Disconnected from server, takes 3 tries to reconnect.
> may not be really a bug, but is there a way to keep the
> SQL server alive regardless of how long the client idles?
> I can deal with it, but it would be nice to either stay
> connected, or have the client continue to retry searching,
> modifying, or uploading an image regardless of its
> connection status, even if it has to create a new session.

The errors "Lost connection to server during query" and "MySQL server has gone away" mean that the connection to the MySQL server has been closed before or during the transmission of data.

By default, MySQL closes the connection after 28800 seconds (8 hours). However, you can check your server's setting by reading the wait_timeout variable (using phpmyadmin, for example). So, if you leave the application running idle for 8 hours, the server will close its connection.

But you are right, the application is not handling the disconnections gracefuly. Actually, if it checks and the connection is lost it just ignore any operation. Most of the time this checking reports OK because the only reliable check is to send data, and when that happens it just show the error dialog window, reconnects and keep sending more data to the server. The problem in this scenario is that the SQL statement triggering the error is lost.

The solution is to reconnect after this kind of errors a couple of times and, if succesful, resend the SQL data; if unsuccesful, give up (completely).

Another problem I've seen is that the mysql 4.0 driver (the one included with the application) fails sometimes with these kind of errors. So, if you get these errors too often, changing the protocol version may help.


Thanks for the bug report. It's in the bugtrack now.


Regards,

Mario A. Valdez-Ramirez.