CiviCRM Community Forums (archive)

Hiya...

I've put this topic in upgrading because that is the issue I am trying to address longer term although this may not be directly related....

We're on 3.2.1 and were unable to upgrade to 3.2.2; the errors are all very weird and I wanted to walk through it all on my localhost to work out what the problem is - now I have problems getting civicrm working on my local host with our data.

I have followed the procedure for moving an existing installation to a new server posted on the WiKi - I have successfully installed a clean version of 3.2.1, dumped the live data wihtout the cached tables, then uploaded the dump into the new database on my local host.

I can verify through direct queries that tables have been populated by the data and should I go to the groups page (localhost) for instance it lists all the groups that were in the live installation.

Whenever I go to a contacts page (select contacts in a group for instance)

I get the following error: Database Error Code: Unknown column 'is_tagset' in 'where clause', 1054

The where clause pertains to the civicrm_tag table, which I can confirm does not have an is_tagset column.

We originally upgraded from 3.1.1 to 3.2.1 with some difficulty and my guess is that the database is only partially upgraded. - although I did do a completely clean install of 3.1.1 and moved our data into it, ran dbtools and corrected all and any issues prior to the upgrade and it appeared that the upgrade was successful.

There does not appear to be a version of dbtools for 3.2 schema

It is a long time and many many records later since we upgraded and even if the backups are still available users would do their nuts if we were to revert to 3.1.1

Any idea how I can list discrepancies between our database and the schema?

Or is this some other issue altogether that may have a really simple explanation?

Thanks for reading this.

Myles

reverting to 3.1.1 means reverting to a database that is several months old - the upgrade appeared to be successful and so we have been merrily using it through the busiest period of the year - users will not accept having all that work wiped out

- is there any other way of checking the integrity of the database against the schema and manually working through t eh problems?