Ghost bug

[Digicoder]

Recently been testing a few things out and everything is working perfect except this one tinny detail.
I've OOPHPed up a query system and it works perfect, I've also constructed a system that will keep track of my users, like when they last moved on the site.

well that works fine too, but the problem I face lies with in the login.
each time you've been off the site, like you get off over night, and you come back, regardless of remember me settings or no, you'll see an error at the bottom of the page.

Warning: mysql_query(): 2 is not a valid MySQL-Link resource in /home/content/i/t/g/itguy45/html/sdfs/includes/functions.php on line 82

Database Error Report:
Error #:
SQL Stated:



Debug info:

#0 dbError() called at [/home/content/i/t/g/itguy45/html/sdfs/includes/functions.php:82]
#1 db->query(UPDATE phpbb_users SET s_online='1200350223' WHERE username='CTB') called at [/home/content/i/t/g/itguy45/html/sdfs/includes/functions.php:193]


Its strange because there is no error info, and on the page the error points to line 82 as the problem, well here is line 82:

public function __construct()
{
$this->host = '';
$this->user = '';
$this->pass = '';
$this->dbase = '';

$this->link_id = mysql_connect($this->host, $this->user, $this->pass) or dbError();
mysql_select_db($this->dbase, $this->link_id) or dbError();
}

public function query($sql, $type=null)
{
// Line 82 of the SQL system.
$this->result = mysql_query($sql, $this->link_id) or dbError();

//. . .


Now I built this system, and I can usually solve all the problems that are produce by it, but this one is just strange.
Its stranger still because the same "link_id" is used for a query on that page just before the actual problem query.
This is the problem query:

public function __destruct()
{
global $db;
$time = time();
if($this->user_id > 1)
$db->query("UPDATE phpbb_users SET s_online='$time' WHERE username='{$this->username}'");
}


So given I have no clue why its doing this, and there is use of the SQL link-id before this query, whats the problem?

EDIT:
BTW, its fine if you refresh the page, it only happens once every new user session.

Thanks for the help guys.

[Fou-Lu]

Within your constructor you are setting the values of your connections to empty strings. Since I don't know what you are doing to generate these values otherwise, this is one of the prime candidates for your problems. The connection itself cannot establish a resource. The better option in this case if you are allowing your constructor to make the connection is to use some parameters to fill in the appropriate fields. As well, I'd recommend before preforming any action that you check the validity of the $this->link_id to ensure that it is not === false.
The second step is to close your connection within your destructor, could be a problem with dead connections that have not been cleaned up but are maxing out your connections, so try that as well. From the looks of it you can remove your global $db call in the destructor as well - there is no real need for it (though it will not cause these problems) - remember that the database in use is connected to the open resource, which you have as your link_id, and likely will never require the use of the $db variable.
Hope that helps!

[Digicoder]

Well first off, I'm not going to openly show you all my sites connection codes and passwords... I worked to hard on the security of my site to do something as stupid as that. They were removed for safety reasons.

Thats just the thing I failed to state. The destructor comes into play at the near head of the page, and the error should also be reported there.
Since the the error is created it would stop the production of any other content on the page, that is not the case, there are about five other queries carried out after that error is generated, and the query does not reset it self until the page is refreshed, and does not close till content is loaded.

Th global $db variable allows me to use the query system inside the function, these are two different classes, mind you.

As for the use of the === false, thats worth a shot. I would have to enable that inside the constructor or the query to allow for proper execution.
Thanks for the help, I'll try your suggestion and see if I can't get some better results.

[Fou-Lu]

Ah ok gotcha, good to remove but I never thought of that, lol, too used to seeing the 'user', 'pass' kinda thing ;)
Hmm, in different files you say too eh? That *may* cause some problems for you. Put a destructor into your sql class as well that specifically closes the connections, that could be the problem there. And 'duh', now I see the use of the $db var in the destructor, completely missed that, lol.
The best part of the OOP environment is the the control you gain. With the SQL in an object model, you can simply close the connection from the destructor and never worry about it again. This means you never need to make a call to the close, which is super great.

Oh, another quick note, I don't think you are doing it but you can serialize connections for your database and place them in cookies. I've seen similar problems arise because of that, where the connection is at first rejected due to the load order of the pages. Its not likely a problem with the serialized connection information (which is wise to not do), but it could be a problem with a load order directive. You may want to consider running via an __autoload function to force the loading of the files if non-existant. Perhaps its attempting to load the 'user' (or whatever the second show object is) before the connection to the database (in which case the destructor may have been called before the creation of the connection). Keep an eye out for that, I've been caught in that trap a few times.

[Digicoder]

Well here is the thing, I work with one brain file, its included on all of the other pages throughout the site, it provides everything that the site needs.
since the "Brain" needs to get stuff from the database, the $db = new db()
is called at the start of this file, along with the session stuff and global initializations.

The files are all included and every thing works just fine after you see the error once.

I don't serialize my connections in cookies, and would never do it for the security risk there.
and my connection is closed by a destructor, but thats not what causes this error, else I'd bee seeing an actual number and SQL statement.

[arnyinc]

Can you test that the query it's attempting to run is valid? Try running: UPDATE phpbb_users SET s_online='1200350223' WHERE username='CTB' in your mysql management tool and try creating a static call to execute it from your webpage.

[Digicoder]

Its difficult to say, this is the first problem like this that I have ever encountered.
It hands out not MySQL error number, or statement.
Once its produced the error, the scripts all continue to run, calling the database at least five times after that error would be produced.

Not only that, but the error is only ever produced once every user session, basically once a day for every user.

Is there and actual way to test for valid Mysql link ID's without having to query the database?
I would love to know that.