Upgrade from Fabrik 3.8.1 to 3.9.2 fails

[railer]

Greetings!

I am attempting to upgrade a Joomla 3.9.19 site from Fabrik 3.8.1 to 3.9.2. PHP is 7.3.23. MySQL 5.6.47.

When updating the component via Extensions/Updates I get the following error in the backend:

JInstaller: :Install: Error SQL Unknown column 'table_id' in '#__fabrik_joins'
Extension Update: SQL error processing query: DB function failed with error number 1054
Unknown column 'table_id' in '#__fabrik_joins'
SQL =

ALTER TABLE `#__fabrik_joins` CHANGE `table_id` `list_id` INT( 6 ) NOT NULL;

Trying to install the package file also fails.

The extensions update list still displays the component but the versions are both 3.9.2.

I read in other forums, the following:
1. Fabrik could be trying to install an old SQL file.
2. Fabrik 3.0 to 3.5 was a major upgrade (is 3.8.1 to 3.9.2 considered a major upgrade?)

How do I resolve this? I tried to run the alter table query above and it failed because the table doesn't exist.
Should I do the upgrades of all the other modules and plugins? (The original installation was the Kitchen Sink version.)

 

[troester]

I assume your #_fabrik_joins already has the column list_id and "1. Fabrik could be trying to install an old SQL file" is the reason.
Can you check this (from http://fabrikar.com/forums/index.php?threads/error-installing-fabrik-3-8.48155/#post-250403)

in #__extensions: if there's an entry with name = com_fabrik,
in #__schemas: an entry with the extension_id of ^^, if yes, which version_id

I think there was no change in database structure between 3.8 and 3.9.
So a GitHub update should do (+ the post-GitHub steps so the correct versions are shown)

 

[railer]

I assume your #_fabrik_joins already has the column list_id and "1. Fabrik could be trying to install an old SQL file" is the reason.
Can you check this (from http://fabrikar.com/forums/index.php?threads/error-installing-fabrik-3-8.48155/#post-250403)

Thanks for your reply troester.

I can confirm that #__fabrik_joins does have a column "list_id" (three records, all "0"). Also confirm that there is a record for "com_fabrik" in #__extensions table, but no extension_id of ^^ in #__schemas table.

Additionally, after I updated the Job Listings in the Fabrik database don't display on the front end. It's a jobs listing site and all but four listings seem aren't displaying so maybe the expiry dates may have been affected (not confirmed).)

I'm presently having my host restore the site from a backup since I did a partial update before I thought about backing up. Going back to square one before re-diagnosing. Anyway, you are suggesting I update through GitHub? (Never done that.)

 

[troester]

Maybe the ^^ (thought as "see above") was misleading:
#__schemas.extension_id should show the #__extensions.extension_id of the com_fabrik record (not extension_id= ^^).
IF there's such an entry and showing e.g. a version 3.0.x you may replace it with 3.6.1 and try a new Joomla update.

For GithubUpdate see my signiture.

 

[railer]

Hi Troester -- the #__extensions.extension_id of com_fabrik is 844, and the #__schemas table does not have a record for 844. (I found the github instructions page in the wiki.)

 

[troester]

Ok, out of interest I tried with my test installation.
I can replicate the error when re-installing the Fabrik3.9.2 package (should be the same as a Joomla update)

if there's an entry in #_schemas with version_id like 3.0
or
if there's no entry at all.​

The installation/update is then obviously running 3.0.1.sql

After uninstalling Fabrik (which shouldn't be done if there's any data) the #_schemas entry is cleared.

A new installation is running without error and creating an #_schemas entry with version_id 3.6.1 (sic! I assume Joomla is taking the last sql file name).
No idea why you don't have such an entry. Maybe some issue with old Joomla installers or because of the kitchen sink...

No warranty, but you can try to add this entry (extension_id 844, version_id 3.6.1) and then try an other update.

But backup before!

 

[railer]

Okay, thanks Troester! Waiting for a restore from our host which took an ungodly 20 hours to get started and I am told it has finally started. I will definitely backup this time, and then try your suggestion. The current version of Joomla is 3.9.19. I suppose I should upgrade Joomla first to 3.9.22. Then check the schemas entry and add it as directed if needed, then do the Fabrik update from 3.8.1 to 3.9.2.

 

[railer]

Following up: Looks like the problems I'm experiencing are due to a more complicated history of this site, which was extracted out of a Joomla Multisite back in June of this year.

Suffice it to say that while Joomla was connecting to a new site database, Fabrik was still connecting to the Fabrik tables back on the old multisite's database which was the obvious cause of the problems I had.

Things were complicated on the multisite because in addition to the database tables for the master site, each slave site had it's own database, but because we were sharing the users from all of the sites, there was an additional "users" site with it's own database. When I extracted this specific site, I checked and deleted unnecessary tables from the new site database, however I'd forgotten that Fabrik had it's own connection settings and did not update them and move the various Fabrik specific tables into the new site database.

While Fabrik's capability to have it's own database connections, and also specify which tables each form connects to in the database can make it very versatile, I think problems like this could be avoided if Fabrik defaulted to the site's Joomla database connection — with an option to modify to connect to other databases.

After this experience, it seems obvious that it's important to work out a naming convention beforehand whereby the names of the tables you create in the form should match the overall site's database prefix.

For instance, consider the following:

In my case my Joomla table prefix is something like: slave01_ so my tables might be named slave01_fabrik_xxx. I also worked out a naming convention for identifying elements which are part of a group. Such as slave01_fabrik_jobdetails_publish_date where jobdetails is an abbreviation of the element group name.

I can't remember if it was me or Fabrik, but in the multisite I ended up with some tables which used the above prefix in the table names as above, and others which had no prefix, as in fabrik_xxx_xxx. So I had both types of table names making it very confusing to determine which tables required by Fabrik to migrate over and which ones to delete.

I realize this is a non-typical situation. But worth considering some way of standardizing naming, perhaps?