Realtime stats mysql error

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

I'm getting the following errors with the realtime stats block.
The first one is because the block is not picking up the correct
database user name. The DB user name is eldrberry_mberry.
Looks like the block is truncating that at the underscore. I
suspect fixing that will fix the rest of them.

Warning: mysql_select_db(): Access denied for user: 'eldrberr@localhost' (Using password: NO) in /home/eldrberr/public_html/modules/realtime-stats/index.php on line 46

Warning: mysql_select_db(): A link to the server could not be established in /home/eldrberr/public_html/modules/realtime-stats/index.php on line 46

Warning: Cannot modify header information - headers already sent by (output started at /home/eldrberr/public_html/modules/realtime-stats/index.php:46) in /home/eldrberr/public_html/modules/realtime-stats/index.php on line 48

Raven · Posted: Sat Oct 04, 2003 10:35 am

That error implies that your dbuser does not have permission to access that database/table. The headers error usually implies that you need to set output_buffering to on. I don't believe there is anything wrong with the block. It's been around too long and too many people are using it.

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

Well, not trying to be argumentative here but if the user didn't have access to the DB then Nuke itself wouldn't run, right? Everything else except this module seems to work fine.

Raven · Posted: Sat Oct 04, 2003 10:53 am

Do you have output_buffering set to on?

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

Beats me. Server is at my hosting co.

Raven · Posted: Sat Oct 04, 2003 10:59 am

Save this code to a file and call it server.php

Code:

<?
phpinfo();
?>

Then ftp it to your web root and run it. Find output_buffering and let me know what the local and global values are.

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

output_buffering no value no value

Raven · Posted: Sat Oct 04, 2003 11:03 am

This block just uses what is in your config.php file. Please verify that your $dbuser is spelled correctly.

Raven · Posted: Sat Oct 04, 2003 11:04 am

You need to add a line to your .htaccess file (assuming you are on Apache)

PHP_FLAG output_buffering On

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

Yep, just looked at the config file and it's correct. As I said above, if it wasn't I doubt anything would be working.

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

Ok, I'll try that...hang on.

Raven · Posted: Sat Oct 04, 2003 11:10 am

Elderberry wrote:

Yep, just looked at the config file and it's correct. As I said above, if it wasn't I doubt anything would be working.

Nuke would come up but the modules and blocks wouldn't work correctly.

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

Well, adding that to the .htaccess kills everything. Generates an
internal server error when I try to access the site.

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

Raven wrote:

Elderberry wrote:

Yep, just looked at the config file and it's correct. As I said above, if it wasn't I doubt anything would be working.

Nuke would come up but the modules and blocks wouldn't work correctly.

Well, since rest of the modules and blocks work I would assume the DB user is correct.

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

Just for the heck of it I ran the server.php on another site of mine and the output_buffering on it is also no value and realtime stats runs fine on it. Strange ain't it. Very Happy

Raven · Posted: Sat Oct 04, 2003 11:27 am

Elderberry wrote:

Well, adding that to the .htaccess kills everything. Generates an
internal server error when I try to access the site.

Your host doesn't allow user directives for PHP in Apache. You will need them to change output_buffering to On. The only thing I could suggest is re-ftp'ing the files. I assume you didn't make any modifications. The block is standard php nomanclature. It just takes the values from the config and uses them.

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

Raven wrote:

Elderberry wrote:

Well, adding that to the .htaccess kills everything. Generates an
internal server error when I try to access the site.

Your host doesn't allow user directives for PHP in Apache. You will need them to change output_buffering to On. The only thing I could suggest is re-ftp'ing the files. I assume you didn't make any modifications. The block is standard php nomanclature. It just takes the values from the config and uses them.

I already redownloaded it from here and reftp'd it before I started this thread. I'm not gonna ask them to change anything as I don't think that's the problem since it works on another site that has output_buffering set the same way. No, I have not modified them in any way. Only thing I changed was the admin name variable as instructed. As you said, the module works on many sites so it wouldn't seem to be the code. It's got me stumped. Guess I'll just not use it on this site.

Raven · Posted: Sat Oct 04, 2003 11:38 am

I agree about the output_buffering in relation to this problem, but usually the forums won't work correctly without output_buffering. Very strange indeed.

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

As a last ditch effort I hardcoded the DB name and DB user name & password in the module and I still got the same error.

I give up.

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

Ok, I found it. It is in the module code. You have the following two lines:

mysql_select_db($dbname);
$db = mysql_pconnect($dbhost, $dbuname, $dbpass) or die('<br />MySQL said '.mysql_error());

They should be reversed like this:
$db = mysql_pconnect($dbhost, $dbuname, $dbpass) or die('<br />MySQL said '.mysql_error());
mysql_select_db($dbname);

My other two sites were really not working correctly. They were just showing the ip addresses without the other info as to guest/user/admin etc and warnings must be turned off so that I wasn't seeing the errors.

After reversing the order of those lines everything is hunky dorry.

Raven · Posted: Sat Oct 04, 2003 1:08 pm

That would be correct. As your see though, all instalations before this have worked correctly or I would have heard. There must be something in the way the defaults are working. Are the versions of Nuke the same in the 2 sites that you are working with?

Elderberry · New Member Joined: Aug 13, 2002 Posts: 20

Raven wrote:

That would be correct. As your see though, all instalations before this have worked correctly or I would have heard. There must be something in the way the defaults are working. Are the versions of Nuke the same in the 2 sites that you are working with?

No, one is 6.7 and the one that started all this is 6.9.
I'll bet there have been others that didn't work but
they weren't as persistent as I am. Very Happy

Raven · Posted: Sat Oct 04, 2003 1:17 pm

But I've had ZERO complaints. I have run and am running it on all versions since 6.5. Anyway, I will reverse the lines and test it and issue an update. Thanks!

Raven · Posted: Sat Oct 04, 2003 3:57 pm

The update has been released. Thanks.

PHrEEkie · Subject Matter Expert Joined: Feb 23, 2004 Posts: 358

Don't mean to drag up an old subject, but this is still an issue, and thought I'd share what I did to fix it.

I needed to set up a new site for a friend, so I downloaded Rav's Nuke 7 bundle. I created a sub-domain on my site and uploaded everything to have a look around... everything looked great! I then went into my reseller panel and created this person's own webspace account. I uploaded the exact same package and suddenly had all sorts of issues. The two biggest were that the security graphics weren't showing up (red x's in the image placeholder) and the 'Headers already sent' error in the realtime stats block.

Now keep in mind that his webspace is on the same server as mine and is controlled by the same php.ini, etc etc.. everything was identical, but one worked and the other didn't. I spent the last two days trying code changes, re-uploading files, and nothing fixed it.

Finally, out of ideas and extremely code-weary, I terminated the webspace account, re-created the webspace from scratch, and re-uploaded the package. Built the database, pulled the site up and BAM! we now had security graphics AND the realtime stats block was no longer throwing the error.

So, to conclude, if you are 100% -sure- that your php.ini config is correct and none of Rav's advice in this thread has helped you, you might just need to get drastic. I'd start with a complete webdocs wipe and a re-upload of the Nuke package. If that doesn't fix it, have your webhost wipe your webdocs, kill your account and re-build it. Sometimes when these CPanel auto-scripts do their thing, shite can happen...