Issues upgrading from 2.13.2 to 2.36.0

[corpitaslj]

We are upgrading Jethron from 2.13.2 to 2.39.0 for s customer.

One SQL script generated an error. On line 46 of 2017-upgrade-to-2.19.sql, we see:

UPDATE _person SET congregationid = NULL WHERE (congregationid = '' OR congregationid = '0');

I changed this to:

UPDATE _person SET congregationid = NULL WHERE (congregationid = 0);

and then restarted the whole upgrade procedure.

Is this fix correct?

All the scripts now seem to run. However, when I login as an administrator and list all persons I get an empty list. If I put % in the search, all the persons do seem to appear. Also, there is no longer an include/exclude archived persons option. What do I need to do to make default list all reports
be not empty?

Thanks,

Simon

[corpitaslj]

Additionally, the reports appear to come in a random order, not by given or family name.

[jefft]

UPDATE _person SET congregationid = NULL WHERE (congregationid = '' OR congregationid = '0');

That SQL looks incorrect. _person.congregationid has been an int, not a string, since the first github commit in 2014. So I think your fixed SQL is correct.

All the scripts now seem to run. However, when I login as an administrator and list all persons I get an empty list. If I put % in the search, all the persons do seem to appear. Also, there is no longer an include/exclude archived persons option. What do I need to do to make default list all reports
be not empty?

Aside from that line of SQL, did the upgrade SQL run completely successfully? If so, you'll have to examine the logs, where you will probably see errors. The log location depends on your environment. On my server, PHP errors go to the Apache ErrorLog (e.g. /var/log/apache2/<vhost>/error.log).

[tbar0970]

UPDATE _person SET congregationid = NULL WHERE (congregationid = '' OR congregationid = '0');

That SQL looks incorrect. _person.congregationid has been an int, not a string, since the first github commit in 2014. So I think your fixed SQL is correct.

You're right that it was always an int column. I think that odd SQL was part of a wider drive to clean up blank strings etc. But I just ran that query on my system and it didn't provoke any errors. So I think it's a red herring for the current issue and it was more likely something around it that was erroring.

It would be good to run the upgrade again from scratch and send us full details of the error that you're getting.