i think i found the problem...
<start geek mode response>
triggers.inc.php is blatantly calling mysql_affected_rows with no handle, so according to the php.net it will use the last connection if not supplied.
it should really be calling $dbh->affected_rows() instead
also, the routine: affected_rows, should be using $this->dbh as well... in it's internal call to mysql_affected_rows().. should be: mysql_affected_rows($this->dbh)
function affected_rows() {
return mysql_affected_rows($this->dbh);
}
is proper implementation!
now
Mitch, why would your PMs be staggered by 3 hours?
simple, there are two boards running on the same server. 1 board is EST and the other board is PST (3 hours apart) and the mysql_affected_rows() call is just bailing in triggers.. so you'll get 2 birthday emails.. and it will all 'look right' when you run Rick's query.. but it really ain't right
imagine if a server has even MORE installs with differing time zones and i think you'd see even more 'funky' results..
files that use mysql_affected_rows (direct mysql call) are: triggers.inc.php and delete.inc.php
files that attempt to do it right, but STILL will fail are inline_moderation.inc.php, where the $sth parameter is passed in..
also, this will work MOST of the time, since there usually (i'm assuming) are only 1 install of ubbthreads per server or even if there ARE more, they all have the same time zone..
</end geek mode response>
that could get REAL funky there!!
ps: if there are other similar 'direct calls' to mysql, instead of using the sql class, you might also see funky stuff with other things.. ie.. multiple notifications on the same new user or whatever... it should be grep'd and made sure that you have properly abstracted the sql class everywhere..
pps: this also prolly catches the incorrect PM notification 'bug' too, since delete.inc.php uses that..
ppps:
Mitch, i will make those changes on your board and we can watch what happens, but i'm 99% sure this is what is your symptom / fix..
