Thread:Project:Support desk/Error: 1054 and more/reply

Hard to tell what is happening here. First: There is no (current) MediaWiki version with version number 1.9.23. In december version 1.24 was available and version 1.23, which has long term support, was available. I guess you picked one of these?

For the first MySQL error:

SELECT lc_value FROM `kinowiki_l10n_cache` WHERE lc_lang = 'de' AND lc_key = 'deps' LIMIT 1 Function: LCStore_DB::get" Error: 1054 Unknown column 'lc_lang' in 'where clause' (localhost)

This means that inside the table kinowiki_l10n_cache the column lc_lang is missing. Obviously, this column should be there. You can take the definition of that column from the according files, which are linked on Manual:tables.sql, and manually add it to your table. And you should also add or at least fix the index lc_lang_key, as it will be missing or at least incomplete as well.

The second error,

1060: Duplicate column name 'ss_admins'

means that this column, which the query tries to add to the DB is already there. Basically, this error can be ignored and the wiki basically should work anyway.

Obviously you can manually fix the first error and you could ignore the second one, but this won't fix the reason for these problems. Also you do not know, if there maybe are not other places inside the DB, which are broken as well.

To me it looks like your database somehow got corrupted. I can't tell you how, but these errors should not happen and usually do not happen. Maybe there was an incomplete upgrade, which went through unnoticed. In the worst case: Maybe you have a security problem regarding DB access?

If you have a current backup, which still includes a working state, that would be ideal. I guess this backup must then come from december, from before you did the mentioned upgrade. If not too much has changed in the DB since then, you should take that one and run the update.php script on that undamaged DB again.

If you do not have such a backup or if there were too many changes in between, you can try fixing/ignoring them manually as mentioned above. But in that case you cannot be sure that your DB afterwards will be in an unbroken state - for example the index lc_lang_key will currently be wrong as well, which you had not gotten an error message about.