[mythtv] [mythtv-commits] Ticket #1147: permissions problem -> coredump

[Dag Nygren]

> On Tuesday 31 January 2006 16:27, Dag Nygren wrote:

> > If you are not checking if you have a connection after initializing
> > it you do assume that everything is OK.
> > And why would you check for this condition in other subs then?
> 
> It doesn't need to be checked, since you get the exact same result by checking 
> the status of the query.

You should, but with a lot of code executed where the result is not really well
defined.
Better give up if you don't get a connection.

> >
> > Where is that documented? Cannot find it in the API for Qt.
> > If that is  the fact, I apologize very much for bringing up this example.
> 
> Well, it's really more the mysql client library.  Qt tells it to reconnect on 
> disconnects.  I don't know where that's documented offhand, but, it's 
> certainly how it works.

I guess you refer to this from the MySQL deocumentation:
===================
To connect to the server, call mysql_init() to initialize a connection 
handler, then call mysql_real_connect() with that handler (along with other 
information such as the hostname, username, and password). Upon connection, 
mysql_real_connect() sets the reconnect flag (part of the MYSQL structure) to 
a value of 1 in versions of the API older than 5.0.3, or 0 in newer versions. 
A value of 1 for this flag indicates that if a statement cannot be performed 
because of a lost connection, to try reconnecting to the server before giving 
up. As of MySQL 5.0.13, you can use the MYSQL_OPT_RECONNECT option to 
mysql_options() to control reconnection behavior. When you are done with the 
connection, call mysql_close() to terminate it.
===================

This could of course explain why the code doesn't seem
to work that well here in my box as I am using Mysql 5.0.15
at the moment.

See, perhaps we did get something fruitful out of this discussion :-)

I will check if I can change the default reconnect behaviour in my.cnf.

Dag