You are not logged in. Please login or register.
Active topics Unanswered topics
Search options
I've been having the same issue Justice had on SQLite but hadn't debugged it.
It does look like you can do the same conversion in native PHP, though, with the long2ip() function. I changed the query in line 334 of fancy_stop_spam.inc.php to just be:
'SELECT' => 'fl.activity_type, fl.ip AS ip, fl.activity_time, fl.user_id, fl.comment, u.username'
and then after the while in line 348:
$cur_act['ip'] = long2ip($cur_act['ip']);
and it seems to work fine. And suddenly I realize there's a lot of logging that I've never seen before. 
That may certainly be the case, although it's my understanding that SQLite should really be pretty good for sites that are in the thousands to tens-of-thousands hits a day range.
At any rate, setting that aside: if I did want to migrate the forum to MySQL, what would be the best way to manage it?
While I don't want to be the guy who keeps bumping his own topic up, has nobody else seen this before?
There's a couple places in the Akismet extension -- lines 256 and 268 of manifest.xml are the ones I've found -- where the code is written as:
'WHERE' => 's.is_spam = \'1\' && topic_id='.$topic_id,
That "&&" there should be "and" -- using "&&" is nonstandard SQL. It works on MySQL, but not all of us are running PunBB on MySQL.
I've very recently put up a PunBB 1.4 forum and, for simplicity's sake, I'm using SQLite3 as the database back end. (I'm running on a fairly limited VPS and trying to be as minimalist as possible.) I've noticed over the last 24 hours that I'm occasionally getting messages like this in the web server error logs:
FastCGI sent in stderr: "PHP message: PHP Warning: SQLite3::query(): Unable to prepare statement: 5, database is locked in /opt/nginx/sites/gc/include/dblayer/sqlite3.php on line 96" while reading response header from upstream
I know that SQLite3 locks the entire database when it's writing, but I'm wondering if this a sign of an actual problem I need to investigate, or if it's something that I can safely ignore -- is the query being retried so from the forum visitor's point of view everything is fine, or is data potentially being lost here? If I need to switch to a different database engine, I should think about it now, so I can follow up this message with "what's the best way to migrate between database engines."
Posts found: 5