yes.... ideally you run in production with migrate=False. When you need to change table models, than migrate=True.
When you run into sync problems, and only then, fake_migrate_all is there to help. On Thursday, April 25, 2013 6:47:35 PM UTC+2, at wrote: > > > Thanks for the help. It worked. > > After regeneration of .table files, fake_migrate_all flag should be set to > False again, right? > > Regards > > On Thursday, 25 April 2013 17:04:15 UTC+5, Niphlod wrote: >> >> you may have the mytable file but the connection string when it was >> generated was different (there's a hash in front of all .table files just >> for this). Anyway, if you're sure that you don't need to trigger any >> migration, just set fake_migrate_all=True for one request and all .table >> files will be regenerated without trying to do anything to your database >> tables. >> >> On Thursday, April 25, 2013 12:24:59 PM UTC+2, at wrote: >>> >>> Hi, >>> >>> I am trying to connect to a remote postgres database running on a ubuntu >>> server. The application is hosted on windows 7 server. Getting following >>> error on application startup: >>> <class 'gluon.contrib.pg8000.errors.ProgrammingError'> ('ERROR', >>> '42P07', 'relation "mytable" already exists') >>> The strange thing is in databases folder, I already have mytable file. >>> Any idea what could be the issue? >>> >>> Thanks, >>> >> -- --- 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/groups/opt_out.