Hi i am having problems upgrading my Geeklog. As I undertand it you overwrite the the old files with new new ones (after backign up the tweak files) and then restoring them. Then run the install script and choose upgrade? I have doen this and chose the option in the drop down box that my current version is 1.3.7 and then click next. I am then presented with an error: 1060: Duplicate column name \'is_default\' Any help is greatly appreciated.

Are you sure you only ran the upgrade script (i.e. the install script in upgrade mode) once? 'is_default' has only been introduced in 1.3.8, so it shouldn't exist in a 1.3.7 database ...

bye, Dirk

I had this problem as well.. it was my own dumb fault, and the upgrade instructions were somewhat confusing... but thats kj... if you did read the instructions, you should have made a backup of your orignal GL 1.3.7sr2db. if so, restore that DB and attempt to run the http://www.yourdomain.com/admin/install/install.php, makesure you select upgrade, and select 1.3.7 on step #2. if you tried opening and running mysql_1.3.7_to_1.3.8.php, you don\'t need to, the upgrade script will do it for you. please correct me if im wrong.

---

-- destr0yr
"I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams

Could you elaborate on that? If nobody tells us, we can\'t fix it ... bye, Dirk

It looks like you manually updated your 1.3.7 database, and THEN ran the install script. The problem is, the install script tries to update your database by adding the updates you apparently added manually. So when the script attempted to add the \"is_default\" field to a table, the field was already there. If you have a back up of the DB, restore it, then run the install script, choosing to update from \"1.3.7\" (even if you have 1.3.7sr2). If you don\'t have a backup, then you are going to have to check the sql script that updates from 1.3.7 to 1.3.8 and make sure each table that it updates is already properly updated in your installation. In other words, if the sql script adds a field name \"is_default\" to the table \"topics\", then you need to go check your topic table to see if the field is already there, etc. Things will be much easier if you have a backup, though. (Dirk, some people will likely think the \"update\" instructions require you to first update the databases manually and then run the install script. Some folks will probably go through steps 1-5 in the update, and since those instructions claim that the rest of the install is exactly like a new install, they may try to follow the new install instructions from step 6 to the end.)

I see. I\'ll try to make that clearer, thanks. bye, Dirk

Here\'s a heads-up for others so you won\'t repeat the same mistake I just did... Instead of unpacking the new Geeklog archive over the top of my current installation, I moved the old directory from /pathto/geeklog to /pathto/geeklog-old. I then unpacked the 1.3.8sr2 archive and moved it to /pathto/geeklog. I thought I was better off doing a \'clean upgrade\', but it didn\'t work out so well. The upgrade seemed to be going fine at first, but choked because it couldn\'t find all the plugins I\'d installed (and moved). Even though I moved all the plugin subdirectories back to where they were supposed to be, it still lead to the \'is_default\' error as noted above because the upgrade script had already run. Anyway, I just wasted a whole bunch of time restoring the entire database and manually restoring every plugin. I\'m sure it would have gone much smoother if I\'d paid attention and unpacked the new files over the top of the current ones as the documentation states.

I found it!

I really took time and compared the script (update from 1.3.7 to 1.3.8) and followed step by step with my sql database, here are results:

topics - went fine
userprefs, users, usercomments - all fine

trouble start with creating a new database (speedlimit)

SQL does not like the syntax $_SQL[] = " and asks you to revise the command

that where installation really stops, so when some people re-run it again, they get an error about duplicates, but that only because update script starts again from topics table, where everything is fine and obviously it would be a duplicate record

ran it manually, code was this (assuming you use gl_speedlimit name for the table):

CREATE TABLE `gl_speedlimit` (
`id` INT( 10 ) UNSIGNED NOT NULL AUTO_INCREMENT ,
`ipaddress` VARCHAR( 15 ) DEFAULT '\'\'' NOT NULL ,
`date` INT( 10 ) UNSIGNED,
`type` VARCHAR( 30 ) DEFAULT 'submit' NOT NULL ,
PRIMARY KEY ( `id` )
) TYPE = MYISAM ;

Would you care to explain that, please? MySQL won't see the $_SQL[] at all, since that's only the declaration of a PHP array. The install script reads that and then forwards the content of that array entry (i.e. the bit between the double quotes) to MySQL.

And, if that were a general problem, nobody would have been able to update their database from 1.3.7 to 1.3.8 ...

Yes, some people seem to have a problem here, but it is not clear yet what that problem is/was.

bye, Dirk

Then I dropped 2 other tables as it was advised:

gl_commentspeedlimit and gl_submitspeedlimit

but site still can't get up

<<An SQL error has occured. Please see error.log for details. >>

I ran check.php, got several permissions errors, so I had to move logs folder inside public_html as I had no rights to write to it from outside the web root

Once I cleaned permissions, i had an error.log, which is saying:
Sat Nov 8 03:53:58 2003 -
1054: Unknown column 'sp_php' in 'field list'.
SQL in question: SELECT sp_id,sp_content,sp_title,sp_format,sp_php FROM
gl_staticpage WHERE (sp_centerblock = 1) AND (sp_where = 0) AND ((sp_tid =
'none' OR (sp_tid = 'all') AND (perm_anon >= 2) ORDER BY sp_id

Now the question is to fix this sp_php thing

What I get there is what I said, it may be not related clearly to SQL as a lanquage, and may be related only to particular versions, but for me as a user, I get this error and those brackets [] are highlighted red - I am using phpMyAdmin and it may its own interpretation for error codes too, who knows

But besides of this, whether brackets are the reason or something else - one thing is clear though:

UPDATE SCRIPT stops at the step of creating new table, and I understand, some people may have it done fine, so it is a dialect problem of mysql or php or something else, but looks like "I am not the only one" who meets it, so I was just glad to deliver what I found so far

Which makes me feel it is a place for problem, yet it may be somewhere else. As I am working on it right this moment, I made the database manually, but this did not help much, then permissions were not in order, fixed it, still something is on the way (site worked fine under 1.3.7)

Now question i have, where is <<Unknown column 'sp_php' in 'field list'.>> to find

Just to make it more clear for those who track the error, I ran info.php, my settings are:

apache 1.3.28
mysql 3.23.49
php 4.3.2

I run it on provider's hosting, so I can not change anything in installations, in case "updates" will be suggested as a solution, I can only work with what I have

Are you saying that you used phpMyAdmin to do the updates? You shouldn't - the install script (in upgrade mode) will handle that for you.

bye, Dirk

Added manually to gl_staticpages

ALTER TABLE gl_staticpage ADD COLUMN sp_php tinyint(1) unsigned DEFAULT '0' NOT NULL;

error changed, now we are missing sp_centerblock

I found then a GREAT page:
http://bschollnick.phpwebhosting.com/digital/backups/geeklog_db_backup_2003_08_26.sql

from where I learned, that my gl_staticpages table is missing more than a half of entries mentioned there!

Spent another 20 minutes manually entering them into ...

And it is working now!

What a night, I am glad I won over it, hope this little research will help others. Main thing learned - to enable logs first, so you have a chance to read errors and then search google (not just his site) for possible references, and final lesson - do not ever give up!

No-no-no, I was doing updates as supposed, through install.php, but it went to nowhere after the second step.

Only after that, trying to fix it manually, I loaded SQL code from /sql folder updates into phpmyadmin, and there I received the same error I hade after legitimate step2, PLUS explanations on the code, where those brackets [ ] were highlighted red

IMPORTANT, correct your old lib-database.php !

look for my other threat here
http://www.geeklog.net/forum/viewtopic.php?forum=1&showtopic=26738

There are 2 tables you have to remove and 2 to add in order to have it done right, I found it, when after update comments stopped working, thanks Dirk was able to identify the root of the problem

I'm pretty sure the lib-database.php in the full 1.3.8 tarballs is complete and correct.

When upgrading from 1.3.7 to 1.3.8, you should use the complete 1.3.8-1sr2 tarball - and that one comes with a working lib-database.php.

bye, Dirk