shaiaquanature wrote:

This happened with the current checkuser from svn and one from a month or two ago, btw.

Can you check if there's a cu_changes table (without the mw_ prefix) present?

The SQL file looks like it properly lists the prefix, but if it's not taking it in that might explain the behavior.

shaiaquanature wrote:

Nope, not there.

shaiaquanature wrote:

In fact, there was no change to the database. It is exactly the same as before running the script.

Ok, I can reproduce this when I don't have an AdminSettings.php and my default DB user doesn't have CREATE permissions.

The sourcing of the SQL files is failing silently; the actual $db->sourceFile() call is returning an error message like this:

CREATE TABLE ...*snip*... failed with error code "CREATE command denied to user 'wikiuser'@'localhost' for table 'cu_changes' (localhost)

but it's not triggering a fatal exception, as we'd normally expect from the default config. The SQL file sourcing function is overriding the general error handling and forcing it to suppress it... which is IMHO not a good idea, as most (all?) calls to sourceFile() either are not doing *any* error checking on the result, or assume a boolean true is success without checking for string return values.

Probably would be best to remove that error override (or make it optional) and allow it to be enabled case-by-case if a caller needs it.

Shaiaqua, you can probably get it working on your system by setting up an AdminSettings.php listing your privileged MySQL account.

r36211 fixes the error reporting; if you SVN up it should now show you the database error instead of pretending it worked (la la la I CAN'T HEAR YOU :)