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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
