Fatal error while upgrading from 4.5.2 to 4.6.0

This comment is non-sense?! You need to update the 4.5.x database to be 4.6.0 compatible before you can do much else.

Running the update.php script doesn't do much but give the above error.

--
www.gadgetspy.co.uk

I ran into the exact same problem, and following ddiego's suggestion cleared things up completely.

Since for some reason the update.php couldn't figure out which updates I needed (defaulting to "All"), I tried exactly what you suggested on a 4.5.2 database. Multiple times, starting from a stable 4.5.2 mysqldump each time. It fails:

2004-10-31: first update since Drupal 4.5.0 release

user error: Table 'search_total' already exists
query: CREATE TABLE search_total (
word varchar(50) NOT NULL default '',
count int(10) unsigned default NULL,
PRIMARY KEY word (word)
) TYPE=MyISAM in /home/foo/testing/includes/database.mysql.inc on line 66.

Fatal error: Unknown column 'severity' in 'field list'
query: INSERT INTO watchdog (uid, type, message, severity, link, location, hostname, timestamp) VALUES (0, 'php', 'Table \'search_total\' already exists
query: CREATE TABLE search_total (
word varchar(50) NOT NULL default \'\',
count int(10) unsigned default NULL,
PRIMARY KEY word (word)
) TYPE=MyISAM in /home/foo/testing/includes/database.mysql.inc on line 66.', 2, '', '/update.php?op=update', '65.114.8.9', 1114099043) in

The simpler way is to just move one date forward in the update script and try again -- the likely reason you're getting an error is because you don't need the update you're trying to run, so you can probably skip it. After a few dates past the first 4.5 update, you'll hit the one where the severity column gets added, and then errors will be handled correctly. The script should then run to the end.

How do you move one date forward in the update script exactly?

Thanks it helped. Finaly I had to got until 2004-12-05 because I hadn't had the queue table in my database.

severity is in the 2005-01-07 update:

ALTER TABLE {watchdog} ADD severity tinyint(3) unsigned NOT NULL default '0'

--
Webdesign from Sweden http://jeenaparadies.net

I used the 10/31/4 update script on my 4.5.2 installation I did in January.

I assume that, unlike the contributed modules, which get micro-upgraded on a continual basis (which I believe should be noted as 4.x.x.foo releases, so admins can actually know if they're up to date), Drupal core tarball is not updated continuously, so anyone who has not run patches on the Drupal core should run the script for whatever version of Drupal they are running.

Yes?
--
mediagirl.org

I had problems in upgrading from 4.52 installed in beginning of March.
I regret having read only the Installation directions and not this topic :(

1) Automatic detection of the version did not work.
2) I decided to start with a version which was apparently close to mine (I tried 124) but I got mistakes

In the end I started with 110 and it worked. Idid it on my remotely hosted website in a separate test directory and separate database.
(You said:
If you're the belt-and-suspenders type like me, run #110 (2004-10-31). It will probably fail and crash the script. so I was cxoncerned but it was OK).

I did it twice always from scratch to be sure.

Then I upgraded to the production website.

Only problem now solved: the blocks administration page did show the new look (the nice one with bold titles for "Left sidebar" and so on and indentedt rows for the blocks...), while in the production site it did not and it was still the 4.5.2 look.

I compared directory and databases and they were the same. So I did nothing, and after some enter-exit manouvre the new look appeared also in the production site.

Does someone know why?

Riccardo

Ok now I come slowly to the solution:
I enter example:

http://localhost/drupal-4-6/update.php?op=update_115
// then select the date:
"2005-01-14"
// and click:
"Update"

And now where can I find the number (date) of my drupal version?
In the admin interface or in the CHANGELOG.txt (Drupal 4.5.2, 2005-01-15) ?

I suggest dropping the tables, reinserting your database from your backup, and then run update again, this time choosing the earliest update for the version you're running. (The later dates are only if you were running patches on the Drupal core since you last installed/upgraded.)

That should do it.

--
mediagirl.org

You're right, but it's not easy upgrading a CMS with over 100 contributed modules. You can't just create an upgrade script, one size fits all. The comments here can get you through that.

If you're unwilling, you can wait for CivicSpace to finish its follow-up update incorporating Drupal 4.6. But you'll still have to wait. They've been at it six weeks, and still have yet to have that stable release with a one-click install. And you can be sure they know precisely what they're doing.

Or you can get webhosting with Fantastico and get Drupal installed with one click.

Or you could get WordPress -- if all you want to do is blog, Drupal is overkill, really.

Or you could go pay money for a system where they cater to the consumer who needs things easy. This is open source. It's like a crowd of people that has a general intention of walking in a certain direction. If you want lock step or dress code or tight formations that are easy to understand and appreciate, well, a crowd just isn't going to do that.

Eight months ago I didn't know a stitch of PHP or MySQL. As a designer, I didn't have much of a computer programming background, unless one term of Pascal counts. But I managed to muddle through this process. No it's not ideal, but it's what we have. And the nature of the beast is live with it or help improve it.

As for the update, keep trying the alternative dates on the update script. The scripts are non-destructive, and once it runs without error, you should be in business (as far as the core goes).

I guess you caught me on an ornery night. I really should be much more amiable on a 3-day weekend. Sorry about that. :) Good luck with the upgrade (or migration).

.:| Laura • pingV |:.

This is how to make a drupal update work if you are running postgresql and the www-data user is not priveleged:

0. Backup. Backup backup backup. Use 'pg_dump database > dumpfile', and then if you screw things up you can drop all the tables and use 'psql < dumpfile' to restore the old tables.

1. Manually update the watchdog table with the new severity field; if you don't do this, you will fail and you will be upset.

2. Pester your host admin or another superuser to change the ownership of all the tables to the www-data user (or equivalent) with this command: alter table * owner to "www-data".

3. Run the update.php script. This should work now. There will be a failure on update 115 because that's where it alters the watchdog table you've already manually altered. Bad drupal; bad!

4. Pester your host admin to change the ownership of all the tables back to you.

5. Profit?

My admin says:

<Admin> ideally the drupal authors would have separated the actual upgrade from the UI, enabling one to run the upgrade from the commandline instead
<Admin> In general drupal doesn't appear to have contemplated the possibility that the www-data user is unpriveleged

So there!

No, that's not true. If you pick the suggested update, 110 (a number that occurs before 115), and any kind of error occurs, the script attempts to log the error into a field of the watchdog table that doesn't exist until update 115 creates it, resulting in a fatal error. This is because of bad planning on the part of the update developer, not user error. To successfully run the update from the suggested and correct starting place, the user has to manually manipulate the database with various commands that the user shouldn't have to learn in order to do a simple update, assuming that all they know how to do is click on links to update a database.

My particular problem ran a little deeper, starting with the assumption that the www-data user is privileged on my host's postgresql database system. Personally, I don't think it's a good idea to do that. All it would take is someone uploading a malicious script into a writeable folder and executing it from the browser to wipe out my entire database. It is better to err on the side of paranoia when one is dealing with data on the web. Therefore, *I* own my tables. It would be a good idea for update developers to separate the form from the function, as one learns early on in programming classes, and make it possible to execute an update from the commandline, while retaining the ability to run it from the web for those who like having their database tables owned by www-data.

Lastly, I'd like to suggest that before one blames users for problems, one should test the issue to confirm the suspicion.