Since I was finally able to use PHP5 using CGI, I upgraded to MW 1.10.0. Everything looked good, up until I decided to try re-installing the ParserFunctions extension. Then I loaded the homepage and got this error:
Database error
A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
(SQL query hidden)
from within function "Title::loadRestrictions". MySQL returned error "1146: Table '*****_Az01.wf_page_restrictions' doesn't exist (localhost)".
Given that it doesn't mention any files, line numbers, or even the query, I'm stuck as to what to do. I tried looking up this error (or portions of it), and I couldn't find anything. Help? -Azurite
On 28/06/07, Azurite azurite@seventh-star.net wrote:
from within function "Title::loadRestrictions". MySQL returned error "1146: Table '*****_Az01.wf_page_restrictions' doesn't exist (localhost)".
Given that it doesn't mention any files, line numbers, or even the query, I'm stuck as to what to do. I tried looking up this error (or portions of it), and I couldn't find anything.
"Table ...._AZ01.wf_page_restrictions" doesn't exist. Your `page_restrictions` table is missing. The upgrader ought to have created it, assuming the upgrader is correct(!) but if not, it can be created using the appropriate table definition in maintenance/tables.sql.
Rob Church
How would I know whether the upgrader was incorrect or not? It seemed to perform the update just fine, as everything was showing up as Ver. 1.10.0 until I loaded the ParserFunctions extension. I went into maintenance/tables.sql and found this portion:
--- Used for storing page restrictions (i.e. protection levels) CREATE TABLE /*$wgDBprefix*/page_restrictions ( -- Page to apply restrictions to (Foreign Key to page). pr_page int(8) NOT NULL, -- The protection type (edit, move, etc) pr_type varchar(255) NOT NULL, -- The protection level (Sysop, autoconfirmed, etc) pr_level varchar(255) NOT NULL, -- Whether or not to cascade the protection down to pages transcluded. pr_cascade tinyint(4) NOT NULL, -- Field for future support of per-user restriction. pr_user int(8) NULL, -- Field for time-limited protection. pr_expiry char(14) binary NULL, -- Field for an ID for this restrictions row (sort-key for Special:ProtectedPages) pr_id int unsigned NOT NULL auto_increment,
PRIMARY KEY pr_pagetype (pr_page,pr_type),
UNIQUE KEY pr_id (pr_id), KEY pr_page (pr_page), KEY pr_typelevel (pr_type,pr_level), KEY pr_level (pr_level), KEY pr_cascade (pr_cascade) ) /*$wgDBTableOptions*/;
-- vim: sw=2 sts=2 et
But what part of it is unnecessary if I was going to use phpMyAdmin/SQL to run the command? It looks like anything with the -- before it is a comment, but I'm not sure if I should edit those out when I paste the command in, or if I should just leave them in and the system will know that they're comments and not part of the code. I don't want to have commands that would try and create a table twice or anything like that, though. -Azurite
Azurite wrote:
But what part of it is unnecessary if I was going to use phpMyAdmin/SQL to run the command? It looks like anything with the -- before it is a comment, but I'm not sure if I should edit those out when I paste the command in, or if I should just leave them in and the system will know that they're comments and not part of the code. I don't want to have commands that would try and create a table twice or anything like that, though. -Azurite
Yes, -- starting lines are comments. SQL should handle it, so you can leave them (but removing doesn't harm either). If you tried to create a table twice, you'd get an error the second one, don't worry. But as always, you should do a db backup before changing it.
mediawiki-l@lists.wikimedia.org