Last modified: 2010-05-15 15:38:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5111 - Database query syntax error
Database query syntax error
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.5.x
PC Windows XP
: Normal critical (vote)
: ---
Assigned To: Nobody - You can work on this!
http://www.superbuddies.net/sbwiki
:
: 5112 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-27 02:28 UTC by Matt Austin
Modified: 2010-05-15 15:38 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Matt Austin 2006-02-27 02:28:30 UTC
Greetings,

I'm fairly certain my situation is going to require a re-install, but I'm hodling out 
hope that someone here can lend a novice a hand.  I have a wiki at the above location 
that only has two users for the moment - a friend and me.  My friend alerted me to 
the following problem that appears on every article:

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 "MediaWikiBagOStuff:_doquery". MySQL returned error "1030: Got 
error -1 from table handler (localhost)".

I do not have command line access to the server, but I do have access to phpMyAdmin.  
Any time I attempt a repair, I receive the following:

error    : The handler for the table doesn't support repair

On all but three tables (_searchindex, _trackbacks, _user_netwalk).

Is there something I can try before blowing everything away and starting over, and 
how do I keep this from happening again?

Thanks in advance,
Matt
Comment 1 Matt Austin 2006-02-27 02:31:18 UTC
*** Bug 5112 has been marked as a duplicate of this bug. ***
Comment 2 Matt Austin 2006-02-27 02:44:13 UTC
**UPDATE**

Data is still there. I can search for a page I know to exist and receive the above 
mentioned error string. I can edit and even preview, but any attempt to save 
yields the 1030/-1 error string.
Comment 3 ABCD 2006-02-27 05:26:48 UTC
*** Bug 5112 has been marked as a duplicate of this bug. ***
Comment 4 Rob Church 2006-02-27 10:13:25 UTC
If the tables are damaged but the data is still accessible, back up the data as
soon as possible and see if it works ok on a new database. If it's not possible
to back up, consider using something like phpShell and the dumping script to
produce an XML file for import later.
Comment 5 Matt Austin 2006-02-27 14:15:54 UTC
Forgive my n00bness, but how do I get the wiki to point/pull from a new DB?
Comment 6 Rob Church 2006-02-27 15:34:51 UTC
The simplest method if you're not totally comfortable with it is to rename your
old LocalSettings.php - keep the file extension, so no-one can steal connection
info - something like LocalSettings.old.php will do, then run through the
installer again by browsing to the wiki. Tell the installer to use the new
database, containing the restored tables and data, and it will check the schema
(shouldn't need to do much) and then write out a new LocalSettings.php as before.
Comment 7 Matt Austin 2006-02-27 19:17:25 UTC
Okay, started from scratch with a fresh database.  Still getting the following:

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 "MediaWikiBagOStuff:_doquery". MySQL returned error "1030: Got error -1 from table 
handler (localhost)".

Could there be an operability issue with the version of PHP or MySQL?

My PHP version is: 4.4.2
My MySQL version is: 4.0.25-standard
Comment 8 Matt Austin 2006-02-27 21:37:48 UTC
More info for the above...

I tried one more time.  Here is the result:

Checking environment...
PHP 4.4.2: ok 
Warning: PHP's register_globals option is enabled. MediaWiki will work correctly, but this setting increases 
your exposure to potential security vulnerabilities in PHP-based software running on your server. You should 
disable it if you are able. 
PHP server API is apache; ok, using pretty URLs (index.php/Page_Title) 
Have XML / Latin1-UTF-8 conversion support. 
PHP is configured with no memory_limit. 
Have zlib support; enabling output compression. 
Neither Turck MMCache nor eAccelerator are installed, can't use object caching functions 
Found GNU diff3: /usr/bin/diff3.
Found ImageMagick: /usr/local/bin/convert; image thumbnailing will be enabled if you enable uploads. 
Found GD graphics library built-in. 
Installation directory: /home/jsuperbu/public_html/sbwiki 
Script URI path: /sbwiki 
PHP is linked with old MySQL client libraries. If you are using a MySQL 4.1 server and have problems connecting 
to the database, see http://dev.mysql.com/doc/mysql/en/old-client.html for help. 
Connecting to jsuperbu_sbwiki2 on localhost as jsuperbu_wikiadm...success. 
Connected to 4.0.25-standard; using enhancements for mySQL 4.
Database jsuperbu_sbwiki2 exists 
There are already MediaWiki tables in this database. Checking if updates are needed... 
...hitcounter table already exists.
...querycache table already exists.
...objectcache table already exists.
...categorylinks table already exists.
...logging table already exists.
...validate table already exists.
...user_newtalk table already exists.
...transcache table already exists.
...trackbacks table already exists.
...have ipb_id field in ipblocks table.
...have ipb_expiry field in ipblocks table.
...have rc_type field in recentchanges table.
...have rc_ip field in recentchanges table.
...have rc_id field in recentchanges table.
...have rc_patrolled field in recentchanges table.
...have user_real_name field in user table.
...have user_token field in user table.
...have user_email_token field in user table.
...have log_params field in logging table.
...have ar_rev_id field in archive table.
...have ar_text_id field in archive table.
...have page_len field in page table.
...have rev_deleted field in revision table.
...have img_width field in image table.
...have img_metadata field in image table.
...have img_media_type field in image table.
...have val_ip field in validate table.
...have ss_total_pages field in site_stats table.
...have iw_trans field in interwiki table.
...already have interwiki table
...indexes seem up to 20031107 standards
Already have pagelinks; skipping old links table updates.
...image primary key already set.
The watchlist table is already set up for email notification.
...user table does not contain old email authentication field.
Logging table has correct title encoding.
...page table already exists.
revision timestamp indexes already up to 2005-03-13
...rev_text_id already in place.
...page_namespace is already a full int (int(11)).
...ar_namespace is already a full int (int(11)).
...rc_namespace is already a full int (int(11)).
...wl_namespace is already a full int (int(11)).
...qc_namespace is already a full int (int(11)).
...log_namespace is already a full int (int(11)).
...already have pagelinks table.
No img_type field in image table; Good.
Already have unique user_name index.
...user_groups table already exists.
...user_groups is in current format.
Initialising "MediaWiki" namespace...
A database error has occurred
Query: INSERT  INTO `sbw_page` 
(page_id,page_namespace,page_title,page_counter,page_restrictions,page_is_redirect,page_is_new,page_random,page_
touched,page_latest,page_len) VALUES 
(NULL,'8','1movedto2','0','sysop','0','1','0.661250159304','20060227213352','0','0')
Function: Article::insertOn
Error: 1030 Got error -1 from table handler (localhost)

Backtrace:
GlobalFunctions.php line 451 calls wfbacktrace()
Database.php line 397 calls wfdebugdiebacktrace()
Database.php line 347 calls databasemysql::reportqueryerror()
Database.php line 937 calls databasemysql::query()
Article.php line 946 calls databasemysql::insert()
InitialiseMessages.inc line 192 calls article::inserton()
InitialiseMessages.inc line 72 calls initialisemessagesreal()
updaters.inc line 670 calls initialisemessages()
index.php line 606 calls do_all_updates()

That is where the installation stops.

I installed version 1.4.14 and it had no problems at all.
Comment 9 CJSoft UK 2006-06-01 11:19:27 UTC
I wold get the latest MW installation and latest MySQL and latest PHP.
MW: v1.6.3
MySQL: v5.1.22
PHP: v5.3

Give that a run for its money and report back.  I am using that combination fine.
Comment 10 Andrew Garrett 2006-11-05 22:06:55 UTC
Decreasing severity. No activity in four months on this, which is essentially a
support request (with no debugging information provided that could indicate a
software issue). Resolving INVALID.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links