Wikimedia Bugzilla is closed!

It sounds like you need to run the update.php script.  If you still have a problem after running that script, please reopen this bug and provide the version you're upgrading from.

Please reread the first line: "after running the upgrade script". Thank you.

"and provide the version you're upgrading from."

Thank /you/.

closing until we find out the version being upgraded.

same problem here, upgrading from 1.16b3 to 1.17.0. After upgrading and running the update.php script for each subdomain (wiki farm), I get the same error:

Database returned error "1146: Table 'wikidb.en_iwlinks' doesn't exist (localhost)".

I actually reported this from the MW support desk where two users had the problem.

Is there some way to check that the update.php script actually ran? Where is the schema for the iwlinks table and would it work to just manually create the table?

I think I have the same problem. I upgraded from 1.16.5 to 1.17. At the last step in the web upgrade process, I got an error page from my browser:

/!\ Content Encoding Error
----
The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.
----
* Please contact the website owners to inform them of this problem.
[Try Again]

My wiki displays fine, but whenever I edit a page I get the error message about iwlinks does not exist.

I have tried to restore my backup and repeat the process, and the same thing happens.

If a wiki developer is interested in taking a look, I can provide a dump of parts of my database prior to the upgrade.

Please everyone also include which db type you are using (mysql, postgress, etc)


When running the updater did the message:

Creating iwlinks table...
ok


appear?


re: comment 7 - the patch file is in maintenance/archive/patch-iwlinks.sql (for mysql, other db's are elsewhere in maintenance directory. Applying manually is fine, just be careful if you use table prefixes)


for comment 8: Don't know whats happening there, but check your apache and php error logs after the installer fails to upgrade. In your situation I would recommend trying the cli installer if possible.

I have just upgraded to 1.17.0 and am experiencing this, too. I am using MySQL 5.5.15

Running php update.php as root fails to complete with the following message:

Creating iwlinks table...A database query syntax error has occurred.
The last attempted database query was:
"CREATE TABLE `iwlinks` (
 iwl_from int unsigned NOT NULL default 0,
 iwl_prefix varbinary(20) NOT NULL default '',
 iwl_title varchar(255) binary NOT NULL default ''
 ) TYPE=InnoDB
"
from within function "DatabaseBase::sourceFile( /var/www/html/w/maintenance/archives/patch-iwlinks.sql )".
Database returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=InnoDB' at line 5 (localhost)"

When I run the web update from /mw-config/ it seems to run fine, producing the following output from the same point:

Creating iwlinks table...ok
Adding iwl_prefix_title_from key to table iwlinks... ok
...have ul_value field in updatelog table.
...have iw_api field in interwiki table.
...iwl_prefix key doesn't exist.
...iwl_prefix_from_title key doesn't exist.
...have cl_collation field in categorylinks table.
...categorylinks up-to-date.
...collations up-to-date.
Creating msg_resource table...ok
Creating module_deps table...ok
...ar_page_revid key doesn't exist.
...ar_revid key already set on archive table.
...ll_lang is up-to-date.
Purging caches...done.
Checking site_stats row...done.

However, when I next try to delete a page, for example, mediawiki produces this error in the browser, suggesting that the update script didn't work properly.

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 "DatabaseBase::delete". Database returned error "1146: Table 'wikidb.iwlinks' doesn't exist (localhost)".

I then executed the patch SQL directly (maintenance/archive/patch-iwlinks.sql) and it created the new table and allowed me to delete the page. 

I then ran the update.php script again and it produced the following:

Creating msg_resource table...A database query syntax error has occurred.
The last attempted database query was:
"CREATE TABLE `msg_resource` (
 mr_resource varbinary(255) NOT NULL,
 mr_lang varbinary(32) NOT NULL,
 mr_blob mediumblob NOT NULL,
 mr_timestamp binary(14) NOT NULL
 ) TYPE=InnoDB
"
from within function "DatabaseBase::sourceFile( /var/www/html/w/maintenance/archives/patch-msg_resource.sql )".
Database returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=InnoDB' at line 6 (localhost)"

So, I executed the patch-msg_resource.sql script directly and it created two new tables. 

I ran update.php again and the same error happened for:

Creating module_deps table...A database query syntax error has occurred.
The last attempted database query was:
"CREATE TABLE `module_deps` (
 md_module varbinary(255) NOT NULL,
 md_skin varbinary(32) NOT NULL,
 md_deps mediumblob NOT NULL
 ) TYPE=InnoDB
"
from within function "DatabaseBase::sourceFile( /var/www/html/w/maintenance/archives/patch-module_deps.sql )".
Database returned error "1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=InnoDB' at line 5 (localhost)"

So I ran patch-module_deps.sql and it created a new table.

Finally, I ran update.php again and everything went fine :-)

Adding Chad to cc list since this is possibly new-installer related.

Guys, could you elaborate how you updated: using old LocalSettings or generating a new one?

I used my existing LocalSettings file.

More reports, bumping severity.

I've been unable to replicate this thus far.

(In reply to comment #10)
> I have just upgraded to 1.17.0 and am experiencing this, too. I am using MySQL
> 5.5.15
>[...]
> I then executed the patch SQL directly (maintenance/archive/patch-iwlinks.sql)
>[...]
> So, I executed the patch-msg_resource.sql script directly
>[...]
> So I ran patch-module_deps.sql and it created a new table.



If you use a prefix for your DB table names, before executing those three .sql files, you will need to edit them and make the following changes:

1.  Change all "/*_*/" to your DB table name prefix.  In my case, my table names are mkvgtiwiki_XXX, so I changed the "/*_*/" to "mkvgtiwiki_".
2. Change all "/*i*/" to "<table name>_".  For example, in patch-iwlinks.sql, change "/*i*/" to "iwlinks_".


Here are the diffs of one of those scripts of mine:

diff -w patch-msg_resource.sql.orig patch-msg_resource.sql
2c2
< CREATE TABLE /*_*/msg_resource (
---
> CREATE TABLE mkvgtiwiki_msg_resource (
12c12
< CREATE UNIQUE INDEX /*i*/mr_resource_lang ON /*_*/msg_resource(mr_resource, mr_lang);
---
> CREATE UNIQUE INDEX msg_resource_mr_resource_lang ON mkvgtiwiki_msg_resource(mr_resource, mr_lang);
15c15
< CREATE TABLE /*_*/msg_resource_links (
---
> CREATE TABLE mkvgtiwiki_msg_resource_links (
20c20
< CREATE UNIQUE INDEX /*i*/mrl_message_resource ON /*_*/msg_resource_links (mrl_message, mrl_resource);
---
> CREATE UNIQUE INDEX msg_resource_mrl_message_resource ON mkvgtiwiki_msg_resource_links (mrl_message, mrl_resource);



Finally, edit maintenance/archives/patch-categorylinks-better-collation.sql and change "/*$wgDBprefix*/" to your DB table name prefix:

diff -w patch-categorylinks-better-collation.sql.orig patch-categorylinks-better-collation.sql
11c11
< ALTER TABLE /*$wgDBprefix*/categorylinks
---
> ALTER TABLE mkvgtiwiki_categorylinks
19c19
< INSERT IGNORE INTO /*$wgDBprefix*/updatelog (ul_key) VALUES ('cl_fields_update');
---
> INSERT IGNORE INTO mkvgtiwiki_updatelog (ul_key) VALUES ('cl_fields_update');

(In reply to comment #16)
You need to run the last script (maintenance/archives/patch-categorylinks-better-collation.sql) else uploads will fail.

TYPE no longer works in MySQL 5.5.  Many people's LocalSettings.php files will still have $wgDBTableOptions set to "TYPE=InnoDB", which would produce the 1064 error Joss had (I'm not positive about everybody else's problems).  The updater should probably check for this.

See http://www.mediawiki.org/wiki/Thread:Project:Support_desk/MySQL_5.5_and_MW_17_-_ENGINE_vs_TYPE

Adding 1.18 blocker per comment 18

*** Bug 31898 has been marked as a duplicate of this bug. ***

(In reply to comment #18)
> TYPE no longer works in MySQL 5.5.  Many people's LocalSettings.php files will
> still have $wgDBTableOptions set to "TYPE=InnoDB", which would produce the 1064
> error Joss had (I'm not positive about everybody else's problems).  The updater
> should probably check for this.

Tarball release notes should probably mention this if we don't fix the updater.

I agree.

The hacky fix, I suppose, is to s/TYPE/ENGINE/ on $wgDBTableOptions before usage

Certainly having the updaters report this.. On the CLI one this would be less obvious, unless postponed to the bottom of the list, so people see it

Using the Installer is more obvious...

(In reply to comment #23)
> The hacky fix, I suppose, is to s/TYPE/ENGINE/ on $wgDBTableOptions before
> usage
> 
> Certainly having the updaters report this.. On the CLI one this would be less
> obvious, unless postponed to the bottom of the list, so people see it
> 
> Using the Installer is more obvious...

r101451 does this for the moment, pending a better fix.

Should be removed later when we push min version of mysql to >= 5.1

Certainly needs something putting into the updaters somehow...

Gonna close this since Reedy's fix fixes it and isn't meant to live beyond mysql 5.1 as minimum.  Hopfully it gets back-ported or another fix created.