Honestly, it is difficult to say which is the best answer. Both are extremely helpful and informative, thanks. Nico, your detailed explanation is what I was originally seeking, thanks. I ran a fake migration and all is well. Incidentally I did include all of the directories including the .tables files. Anthony, your answer provides a fix for which I didn't pick up elsewhere and is also applicable in this case. I noticed the hash prefix, but didn't twig that this was a hash of the connection string. On which you are right - I did change it. Thanks again to both.
On Tuesday, December 19, 2017 at 4:36:13 PM UTC, Anthony wrote: > > Did you change the MySQL connection string? By default, the names of the > *.table files are prefixed with a hash of the connection string, so if you > change the connection string, the hash will change, and none of the > existing *.table files will be recognized. For a simple fix, you can force > the DAL to recognize the original hash -- just grab the prefix from an > existing *.table file and do: > > db = DAL(..., table_hash=[the original connection string hash]) > > Anthony > > On Friday, December 15, 2017 at 6:26:05 PM UTC-5, SimonD wrote: >> >> >> I've just upgraded from 2.14.6 to 2.16.1, and for the first time ever >> since using web2py (in years), I encountered a "(1050, "Table 'xxxxx' >> already exists")" error. >> I applied "db = DAL(...,migrate=False)" and this worked OK. If I remove >> the migrate=False I see the error again. >> I upgraded on a local server using 2.16.1 and a copy of the apps' folder >> and a restored mysqldump from my VPS running 2.14.6. This is my usual >> upgrade/test method. >> >> I'm a little perplexed why I see the error, because the app's entire >> folder and the mysql have not changed. Only the web2py version has changed >> (and I am using a different mysql host with the same data). I've not seen >> this when upgrading in the past. >> I also wish to enable migrations but the error re-occurs if I do. >> >> Although the fix is documented and database migration is explained in the >> book, I have not been able to find information about what migrate= does >> 'under the hood'. Same for fake_migration. Hence I am unsure what strategy >> to adopt to properly fix the snag. >> >> 1) Why do I see the above error when simply up-versioning web2py? The >> mysql DB and app's models have not changed. Nor is there any change >> anywhere in the app's entire folder. >> 2) I have read notes about .table files, but I thought these were used >> only for sqlite. Do these play a role in mysql also? >> 3) I am also unclear of exactly what fake-migration really do i.e. "db = >> DAL(...,fake_migrate_all=True)". I want to restore migration=true - is a >> fake_migration the way to fix whatever problem is causing the error? And >> what does it actually do? >> >> >> I'm sorry for these basic questions. I have a poor understanding of what >> the migrate and fake_migrate arguments really do, how they work, and what >> they check to trigger the above error. Google is usually my friend, but not >> in this case. >> I am sure a better 'under the hood' understanding would help me. Is there >> a great explanation somewhere, please, that will help me to get set >> migrate=True without further errors? >> >> Many thanks >> >> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
