Loading...
 
Architecture / Installation

Architecture / Installation


SERIOUS ISSUE: Upgrade gives "Unknown column 'version_minor' in 'field list'" error

posts: 4

I am trying to upgrade a 2.1 version of TW to 4.2.

Running the tiki-install upgrade script seems to work successfully and even gives the message "Upgrade operations executed successfully: 4300 SQL queries."

When I try and proceed to log-in however, I receive another error message (below). I did a Google search, hoping to find the answer and received quite a few hits. Unfortunately the matches it found were not solutions to the problem, or even descriptions of the problem, but a large list of publicly accessible sites that *HAVE* the problem - and Google has indexed them.

This is not a good look for TW!

There seems to be no information about this problem anywhere yet a plethora of sites that have the issue. I have the same problem whether I'm trying to upgrade to v4.2 or v5 beta 2

Any ideas from anyone?



The error message is:

" System error.

The following error message was returned:

Unknown column 'version_minor' in 'field list'

The query was:
SELECT `page_id`, `pageName`, `hits`, `description`, `lastModif`, `comment`, `version`, `version_minor`, `user`, `ip`, `flag`, `points`, `votes`, `wiki_cache`, `cache_timestamp`, `pageRank`, `creator`, `page_size`, `lang`, `lockedby`, `is_html`, `created`, `wysiwyg`, `wiki_authors_style`, `comments_enabled` FROM `tiki_pages` WHERE `pageName`=?

Values:

1. HomePage

The built query was likely:
SELECT `page_id`, `pageName`, `hits`, `description`, `lastModif`, `comment`, `version`, `version_minor`, `user`, `ip`, `flag`, `points`, `votes`, `wiki_cache`, `cache_timestamp`, `pageRank`, `creator`, `page_size`, `lang`, `lockedby`, `is_html`, `created`, `wysiwyg`, `wiki_authors_style`, `comments_enabled` FROM `tiki_pages` WHERE `pageName`='HomePage'

posts: 4656 Japan

This was an issue several months ago, but I don't recall the solution. If you don't get a more helpful reply here, try posting the question on the developers mailing list (link is in the top menu). Someone should recall, or if I come across the solution, I'll update this post.

-- Gary


posts: 1817 Catalan Countries

mmm, having a quick look around, it might be that for some (misterious) reason, you are missing this from your database:


`version_minor` int(8) NOT NULL default '0',

just after the column "version", in your mysql table:

tiki_pages

I don't know mysql... but probably you could add that missing column to your db through phpmyadmin or similar...

HTH

P.S: Another story is where in the upgrade scripts this command is missing... (I'll keep searching a bit)


posts: 1817 Catalan Countries

For some reason, this partial sql command didn't work in your case:

Copy to clipboard
alter table tiki_pages add column version_minor int(8) NOT NULL DEFAULT 0;


It did work for me in a test on a 2.0 db (on GNU/Linux), but in case it doesn't work for you (case conflict? most upgrade scripts use upper case commands except this, it seems), you can try with this:

Copy to clipboard
ALTER TABLE `tiki_pages` ADD `version_minor` int(8) NOT NULL default '0' AFTER `version`;

which was my initial patch, until I saw that there was already the previous one in lower case already in

installer/schema/20090808_add_wiki_minor_edits_tiki.sql

Please, report back if the lower case command doesn't work for you.

HTH


posts: 1817 Catalan Countries

aha, the single quotations/ticks... are different (I see that clearer after my own post here.
I'll fix it so that it's included in the next 4.x and 5.0

Thanks again for reporting! and welcome to Tiki community! smile

posts: 4

That sounds more like the real problem as I tried manually adding that column and then started getting multiple other errors. It quickly became clear that the upgrade scripts were not running properly at all.

Strangely though, there were no error messages reported when running tiki-install.php. In fact, it said that all database queries were executed correctly. Sounds like there could also be an error in the error checking of the database migration scripts execution.

Is there anything I can do in the meantime to test this out? e.g., search and replace for certain tick characters in a particular file/sub directory to resolve the problem

posts: 4
Hmmm. Perhaps not. I just checked the file containing the SQL statement and there were no ticks at all in the statement. That does still suggest to me that the script(s) may not be running at all.