Quick Repair: Differences found between database and vardefs

Hi, something a bit strange has happened to my CRM over the past week and I’m not sure what to do.

Upon doing Quick Repair and Rebuild I now get: “Differences found between database and vardefs”, which doesn’t resolve itself if I choose “EXECUTE”.

I get a database failure notification. Upon checking the logs, I get:

Sun Jul 4 21:27:31 2021 [760266][640b0415-4c43-2baa-1012-5f42dc145c6c][FATAL] Executing repair query: Query Failed: ALTER TABLE users DROP INDEX idx_user_name, ADD INDEX idx_user_name (user_name,is_group,status,last_name,first_name,id): MySQL error 1071: Specified key was too long; max key length is 1000 bytes
Sun Jul 4 21:27:31 2021 [760266][640b0415-4c43-2baa-1012-5f42dc145c6c][FATAL] Exception handling in /home/district/public_html/CRM/include/MVC/Controller/SugarController.php:409
Sun Jul 4 21:27:31 2021 [760266][640b0415-4c43-2baa-1012-5f42dc145c6c][FATAL] Exception in Controller: Database failure. Please refer to suitecrm.log for details.

When running Quick Repair & Rebuild again, I can see the same differences are unresolved.

possible useful info:
The CRM got upgraded to v.7.11.18 to v.7.11.20 recently.
Apparently around the same time something changed on the server because the Cron stopped working and my Webhosting service had to correct the execution path of the Cron job to get that working again.

I’ve resolved this now - I think I had made a mistake when adding a new custom Scheduler files to the custom/Extension/modules/Schedulers/Ext/ folder, which upset the database somehow.

A backup restore to a version prior to this change has made the issue go away.

I spoke too soon!

Immediately after posting the above, I checked again to find the error had returned (without my customisations mentioned…)

This makes me suspect that the repair of the Cron has triggered some Scheduler that perhaps has not run before and that has caused the problem… will keep looking.

I would check the PHP versions of both the web server PHP and the CLI PHP (which is what cron uses).

And search these forums for your error, this is a known issue, to some extent. The only thing surprising here is the fact that it’s happening with a new version - it should be fixed by now.


Thanks @pgr, the search really helped.

Particularly the below post, and it’s link to the tutorial on How to Convert MyISAM to InnoDB:

I went into the database and just changed the Users table to InnoDB and it resolved the problem.

1 Like