Forum OpenACS Development: Re: Minor Error in Calendar after upgrading

3: Re: Minor Error in Calendar after upgrading (response to 2)

Posted by Cesareo Garcia Rodicio on 11/19/13 01:56 PM

Hi Gustaf!

Apparently, I've thought so 😊 but upgrade scripts didn't load. Now I have just run them manually and it worked

It seems to be same problem.

Thanks Again

4: Re: Minor Error in Calendar after upgrading (response to 3)

Posted by Gustaf Neumann on 11/19/13 02:06 PM

Good.... but still wondering, what version you see in /acs-admin/apm/ for acs-events?

Once again, it would have been nice to have a log in the database, what upgrade scripts were running correctly, and which are still outstanding.

-g

5: Re: Minor Error in Calendar after upgrading (response to 4)

Posted by Cesareo Garcia Rodicio on 11/20/13 11:03 AM

acs-events Events 0.6d5 (I'd already download last version).

Yes, as you have summarized a log audit of upgrade process would be great. Problem (at least for me) is to make sure that upgrade process goes in right order. As I understand, once it stops, it stops (don't load later versions of upgrade scripts)

Good news is that the solution is easy and working well: upgrade manual (psql -f) and IN ORDER. As I understand, I can upgrade several times so it doesn't happen anything wrong if I "repeat" some upgrade

6: Re: Minor Error in Calendar after upgrading (response to 5)

Posted by Gustaf Neumann on 11/21/13 01:28 PM

When one of the upgrade scripts fails, OpenACS should not increase the version number; in your case, you have the most recent version number.

If you would have still an old version number in the database, re-running the sql upgrade scripts in the right order would happen automatically on a second upgrade attempt (in most cases, this is safe).

7: Re: Minor Error in Calendar after upgrading (response to 6)

Posted by Cesareo Garcia Rodicio on 11/21/13 03:14 PM

Something should be wrong with my upgrade process, I didn't mean of any big problem.

Anyway, as we said before, an audit upgrade sript logtable might solve this (perhaps) rare problem