autoload tables not created when enabling the module: Table 'mydomain1_live.autoload_registry_file' doesn't exist

Did you run update.php?

Same problem. Updating did not help.

Do you happen to have the Notifications or Messaging modules enabled?

I have the same error. I do not have Notification nr Messaging modules installed. Able to provide additional information as requested.

Hi All,
I had the same problem because I had mail system installed and a new version requires the autoload . So after I put the module files in directory it "enabled" it automatically without creating it.
Indeed no tables were created in db.
I just disabled and reenable it and the tables were created.
Reminds the joke about the difference between the computer industry and the vehicles industry ...
but it helps

I'm still seeing this issue with 6.x-2.1. I've tried several different things and can't for the life of me get it to create the tables. Rolling back to 6.x-1.4 for now, but would love to see this addressed.

subscribe
autoload_registry' doesn't exist

Rolling back to 6.x-1.4 too

I have just applied all up to date core and modules to our website, and am having this same issue with this table not existing. I cannot see a resolution to this issue on Drupal.org. The post #5 above seems hopeful, but I cannot seem to disable/re-enable any applicable modules. Any advice? Wondering what the timeframe is for this issue to be addressed?

Does manually running

drupal_install_schema('autoload');

work?

Cause that's all autoload is doing, which is how all drupal modules install it's tables. a hook_install with a drupal install schema.

We're not having this problem and regularly deploy this module.

Having the same problem when first enabling autoload 6.x-2.1 in D6.26.

Multiple occurrences in dblog of

Table '[dbname].autoload_registry' doesn't exist query: SELECT filename FROM autoload_registry WHERE name = 'views_plugin_display_default' AND type = 'class' in [site home]/sites/default/modules/contrib/autoload/autoload.module on line 191

or

Table '[dbname].autoload_registry' doesn't exist query: SELECT filename FROM autoload_registry WHERE name = 'date_plugin_display_attachment' AND type = 'interface' in [site home]/sites/default/modules/contrib/autoload/autoload.module on line 191.

No tables are created in the database at this point.

Disabling and uninstalling generates dblog errors when attempting to drop the tables.

The module's row in {system} is of course not deleted by the uninstall, and it has the revised weight value of -100.

Re-enabling the module successfully creates the tables. Is that because the necessary weight value (which is originally set in hook_enable) is already present, whereas for a "true" first install scenario, the system row will have a default weight because hook_enable has never run?

At the moment I don't know enough about Drupal internals to predict how the weight of a module influences the install processing, bearing in mind I have not been trying to install multiple modules with the same admin page action.

Update at 16:38 - as suggested by previous comments, installing a vanilla D6 system and then installing just the autoload module does not cause a problem. However the list of modules running in my production Drupal site is a very long one so I will try to narrow down the possible conflicts.

OK I've ended up making a copy of my live Drupal site and temporarily putting a debug_traceback into the actual watchdog function. I could reproduce the problem at will if I reloaded the db export and ran the autoload install. The traceback indicated that class_exists was being run and invoking autoload_class via spl_autoload_call before the schema tables were created and populated.

However I also discovered that my database {system} table had an old row in it for autoload with the unlikely weight of -282828 which I suspect was hacked by my predecessor. Once I deleted the suspect row before re-running the install, I was not getting the error during install.

So as my solution appears to be achieved by cleaning up dubious old database content, I won't be spending more time on trying to reproduce the problem on a generic D6 system.

However I hope my comments may be helpful to anyone having a similar problem.

running the following on the command line worked for me:

drush eval "drupal_install_schema('autoload')"

I got this situation too.
The problem is due to MySQL weird behavior, which is described here: #819524: Database schema check on primary key (unique) + default combination.
Also are related:

• https://drupal.org/node/159328#comment-4068138
• https://drupal.org/node/811594#comment-3084806

Solution is just to remove 'default' => '', for fields of the primary key.
Here is the patch, that fixes it.