Fellow monks, as you can wel see above, I had stated to have fixed the problem. I did not - The server now has less interest in taking a strawl, then before, but still it has not lost it appetite completely.

Altough I have changed my table definition to meet my requirments (now way overkill, since the data I pass in has not grown beyond 1.7Kb so far). The problem kept occuring.

After reading a lot of documents, and mailing lists (and google of course) I came to the conclusion that it sometimes serve you better not to do:

my $dbq = $dbh->query("UPDATE table WHERE column='value'");
[download]

but:
For some odd reason, loading a result-less query object into a local var, can make the SQL server wander off again...

I now have adapted my code in such a manner that I will not be asking the server to answer. (iow: $dbq = $dbh->query($SQL) only for SELECT statements).

Allas : Problem still here in contradiction to the MySQL server.
Okay - time for some hard debugging rules to be implemented. Before every query i added a warn("Question #1\n"); and after the query I added a warn("Answer #1\n"); (the #1 increments of course).

After some intensive research I found that playing around with your SQL statements, tend to increase the amount of 'Server has gone away' (eg INSERT INTO instead of INSERT. VALUES('val1','val2') instead of VALUES ('val1', 'val2') (which puzzles me big time...)).

Further more; the message it self is useless. In most cases it just seems to mean: 'Hey - your query has no results...'. This is not bad (unless you are definitly expecting some).

It seems to be very satisfying to do $Mysql::QUIET = -1 right before the query that may give you a server is off shopping message. (be nice and set it back to 0 (NULL) when done...)

Hoping to be off help to all those troubles Mysql(.pm) & mod_perl developers.

Sinister.
"Field experience is something you don't get until just after you need it."