Got this error this morning

DatabaseSchemaObjectExistsException: Table locales_source already exists. in DatabaseSchema->createTable() (line 621 of C:\sites\d6d7\includes\database\schema.inc).

Occurred when enabling the locales module and content translation together. may be dup of #761740: On enabling 2 or more modules: DatabaseSchemaObjectExistsException but doubt don't know for sure and it's closed with won't fix.

This works fine on a straight D7 scratch install.

CommentFileSizeAuthor
#6 896672-test.patch1.27 KBDamien Tournoud
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

plach’s picture

Component: locale.module » base system
Issue tags: +D7 upgrade path

This is probably a base system issue.

ctmattice1’s picture

Priority: Normal » Critical

received this error again from todays head. error log shows database exception.

DatabaseSchemaObjectExistsException: Table <em class="placeholder">locales_source</em> already exists. in DatabaseSchema->createTable() (line 621 of C:\sites\d6d7\includes\database\schema.inc).

marking as critical since it breaks upgrade path.

chx’s picture

Please share a dump of your database, or in this case system table at least. Thanks.

Damien Tournoud’s picture

Status: Active » Postponed (maintainer needs more info)

Needs a way to reproduce.

We do have tests for the upgrade path with the locale module enabled. In which condition does it break the upgrade path?

ctmattice1’s picture

Status: Postponed (maintainer needs more info) » Active

I'm willing to share the db but it should not be necessary.

This actually doesn't break the upgrade path itself. The upgrade does complete.

I start out the upgrade with content translation and locales modules disabled in 6.19 (they were enabled once, then disabled, as this is the current recommended procedure before upgrading).

I then delete and reload d7 from cvs download of HEAD. There are no d6 modules present but sites/all may have latest d7 version of coder and devel.

run update on the site reusing settings.php file i've used forever. The variable update_free_access is set to TRUE and the update runs anonymously as I am not logged into the site.

I still get #826640: Update results page missing session data, causing "Undefined index: update_success" notice and "aborted prematurely" message on upgrade completion and have posted the results there. This problem with locales module occurs after upgrading when you go to the modules page and start enabling them.

If the table {locales_source} is present in the d6 db then this would be the expected result when schema.inc tries to create it unless a db table check is done first.

Damien Tournoud’s picture

Priority: Critical » Major
FileSize
1.27 KB

Still cannot reproduce. Lowering priority until someone reproduces.

Damien Tournoud’s picture

This might actually be caused by #938560: {system} records of installed modules are removed. Not sure how yet.

webchick’s picture

Status: Active » Needs review

Marking "needs review" so testbot takes a look.

ctmattice1’s picture

Checked the schema_version as suggested in #938560: {system} records of installed modules are removed, it was -1. Went back to d6 enabled/disabled locale module. Of course it barfed a message about the table already existing from the d5 db but drupal 6.19 did enable locale whereas D7 errored and would not enable it.

Checked the schema_version for locale in the d6 db after enabling, it was 6006. disabled locale in d6, recheck schema_version, still retained 6006

Upgraded this db to d7, checked system schema_version after upgrading and before trying to enable locale - upgrade process reset it to 7001. Enabled locale without a hitch, so this was a db issue dating back to d5 somewhere.

I'll leave this open for now. I looked (didn't try it) at the patch and it looks sane but would not have corrected the error I was experiencing.

Feel free to close out.

sun.core’s picture

Status: Needs review » Closed (cannot reproduce)

We definitely have some weird Locale update issues left, but this issue sounds a bit too vague and cannot be reproduced.

Thanks for reporting though!

bartclarkson’s picture

ctmattice1, thank you very much. It's 2013, but this issue hit me out of nowhere. Simply turning on the locale module in the migrated D7 utterly killed the dev server (WSOD).

Your pointing out the business of -1 in the System table was the critical piece of the puzzle.

I didn't need the previous locale configuration. So I changed the -1 to 7000, which had the effect of allowing me to then Uninstall the module. Then I just turned it on and went about normal configuration. Case closed.