Forum OpenACS Development: Re: Minor Error in Survey Package after upgrading

Collapse
Posted by Gustaf Neumann on
Your installation is missing the upgrade script: acs-kernel/sql/postgresql/upgrade/upgrade-5.7.0d1-5.7.0d2.sql

The problem at hand is a pg8/9 incompatibility. pg9 is closer to the standard and does not allow "return" as output column name. The error message from pg is suboptimal.

In case you have still the error.log from the upgrade, i would check, what upgrade scripts were executed and where the upgrade stopped. Then run the missing upgrade scripts manually.

If you don't have the log file anymore, go through the upgrade scripts and check in the database, if these were executed (i.e. pick e.g. a sql function from the file and check, whether you have it in the db).

Collapse
Posted by Cesareo Garci­a Rodicio on
Hi Gustaf

Thanks!, it worked :-) (I run the upgrade function manually).

I've lost error.log (at least I didn't find it) so I'll check this scripts to see if db has all functions in kernel upgrade scripts.

Collapse
Posted by Cesareo Garci­a Rodicio on
Hi Gustaf

I've been checking some upgrade scripts and I'm a bit confused. It seems that what I find in DB it's differect form upgrade script BUT I don't find big errors (only a few).

So, I'm not completely sure what upgrade scripts has been failed. Without that error.log, how can I know that?

Can I do a "manual upgrade" of each file? I suppose BD might be messed up, right?

Collapse
Posted by Gustaf Neumann on
i think, the upgrade process of a package stops when the first upgrade script fails. Therefore, one has to run the later scripts, which were not executed.

In general it is desirable to have scripts that can be run multiple times without doing harm. i hope, that all upgrade scripts of the kernel have this property. so, i would recommend to make a backup first before running the missing upgrade scripts.

Take care to run the upgrade scripts in the right order.

Collapse
Posted by Gustaf Neumann on
it sounds like a good idea to add a table to the database containing the names of every successfully executed upgrade script with timestamps. Then recoveries from broken upgrades would be much easier and more transparent
It might be. Whatever mechanism that allow user to check what function has be upgraded.

Another Idea could be stop (or prevent) upgrade but I think that's why error.log exists :-).

My problem now (as a whatever regular user at this point) is that I'm not completely sure about what upgrade script succeed. So I'll try to do it "manual" in my dev server and check if there is some problem.