Richard,
Nope, I didn't change the name of the app itself. The only thing that
changed is the name of the computer the DB is on and thus the DAL
connection string.
The traceback error is :
<class 'pyodbc.ProgrammingError'> ('42S01', "[42S01] [Microsoft][SQL Server
Native Client 11.0][SQL Server]There is already an object named
'shipment_at_risk_archive' in the database. (2714) (SQLExecDirectW)")
Interestingly the error doesn't occur on every request even though the
db.shipment_at_risk._enable_record_versioning() is in a plain model file
and would presumably get executed for every page. It only pops up if I'm
trying to get into the database admin screen of App Admin or if I'm on a
page that actually utilizes the archive table.
Attempting to include an archive_name matching the existing table within
_enable_record_versioning() results in the same error. If I use a new name
for the archive table then it just creates that table and works fine but
this isn't desirable since I want to keep using the data in the
pre-existing archive table. Having _enable_record_versioning() enabled for
only a single table at a time also does no good.
What I've ended up doing to get past this is using a different archive_name
value and letting the DAL go ahead and create new tables. Then i just
changed the database/ .table file's name to match the original archive
table's name and also edited the contents so that it used the original
table name in things like constraints. That seems to work and is
essentially doing a manual fake migration. But I'd still like to hear from
Massimo or another dev whether or not this is intended to behave this way
or if there really should be a fake_migrate argument for
_enable_record_versioning() like there is for regular table definitions.
Brian
On Monday, February 22, 2016 at 10:18:31 PM UTC-6, Richard wrote:
>
> Other possible explanation... Did you change app name? Sometimes this kind
> of web2py feature use some part of web2py and app three in the name of
> table created "automagically"...
>
> For instance... I was having issue with session in database feature
> because web2py use application name in the table name of the session in
> database feature, so if I was not specify the name of the table in which I
> want the session file to be store and I rename application (which I do in
> order to test version tag and deploy) I wasn't able to execute tests
> because web2py try to insert records in the wrong table... So I had to
> specify table name like so :
>
> session.connect(request, response, db, masterapp='APP_NAME')
>
> So session goes in web2py_session_APP_NAME session for any clone of the
> master app...
>
> Richard
>
>
> On Mon, Feb 22, 2016 at 11:09 PM, Richard Vézina <ml.richa...@gmail.com
> <javascript:>> wrote:
>
>> Ok, so in this case, my theory is good... Try to leave just one
>> _enable_record_versioning() for one turn... You try access your app with
>> only one table under record versioning to see if it works... Then if this
>> work, I would make sure (explicit) what is the name of the archive table to
>> see if the issue go away...
>>
>> Richard
>>
>> On Mon, Feb 22, 2016 at 10:46 PM, Brian M <bmer...@gmail.com
>> <javascript:>> wrote:
>>
>>> No, not using single archive table. For each table I want archiving
>>> enabled for, fortunately only a few, I have
>>> db.table_name1._enable_archiving(), db.table_name2._enable_archiving() and
>>> my database does that have separate tables for table_name1_archive and
>>> table_name2_archive. I'm pretty sure that by default if you haven't
>>> explicitly provides some other name for the archive table web2py
>>> automatically uses <main table name>_archive which is exactly what I have
>>> (because _enable_record_versioning() initially created the tables in the
>>> database I restored from)
>>>
>>> On Monday, February 22, 2016 at 9:10:06 PM UTC-6, Richard wrote:
>>>>
>>>> I think it because you use single archive table, could it be??
>>>>
>>>> If I remember there is many differents way to setup record versioning
>>>> feature...
>>>>
>>>> So what may happen in your case, if you have a single history table and
>>>> multiple ._enable_record_versing() for each table to be versioned, is that
>>>> web2py try to recreate the same history table each time he enconter the
>>>> _enable_record_versioning()
>>>>
>>>> Personally I have evaluate the feature over auth_user table only for
>>>> now and make use of it as a per table history table... So, I init the
>>>> feature like so:
>>>>
>>>> db.auth_user._enable_record_versioning(archive_db=db,
>>>> archive_name='auth_user_archive',
>>>> current_record='current_record',
>>>> is_active='is_active')
>>>>
>>>> Where I specified the name of the table to use for archiving records...
>>>>
>>>> You may have a look at your history table(s) and try to set the
>>>> previous parameters for each of your instanciation of the
>>>> _enable_record_versioning()
>>>>
>>>> Richard
>>>>
>>>> On Mon, Feb 22, 2016 at 10:01 PM, Brian M <bmer...@gmail.com> wrote:
>>>>
>>>>> Um yeah I suppose I could let the DAL create the tables all itself and
>>>>> therefore also generate all of the expected .table files in the database
>>>>> folder and then go back in afterwards and do the actual DB restore on top
>>>>> of the new empty database. But it seems like I shouldn't really have to
>>>>> play tricks like that.
>>>>>
>>>>> The traceback error message is basically can't create
>>>>> table_name_archive an object with that name already exists. Sorry, don't
>>>>> have access to my work PC right now but that's the gist of it - can't
>>>>> create it is is already there. It is the same error you'd get with any
>>>>> other table should you forget to turn off migrations/enable fake_migrate
>>>>> except there seems to be no way to do that for the automatically
>>>>> generated
>>>>> _archive tables you get with _enable_record_versioning().
>>>>>
>>>>> On Monday, February 22, 2016 at 8:54:29 PM UTC-6, Richard wrote:
>>>>>>
>>>>>> What is the traceback error message?
>>>>>>
>>>>>> On Mon, Feb 22, 2016 at 9:53 PM, Brian M <bmer...@gmail.com> wrote:
>>>>>>
>>>>>>> The restore was done with MS SQL Server's built-in backup & restore
>>>>>>> so yes it has all of the tables and info. The dozens of other tables in
>>>>>>> my
>>>>>>> database worked just fine with migrate=False, it seems to be just the
>>>>>>> few
>>>>>>> _archive ones that are having issues.
>>>>>>>
>>>>>>> On Monday, February 22, 2016 at 8:39:22 PM UTC-6, Richard wrote:
>>>>>>>>
>>>>>>>> If you restore database like for like, why are you bother with
>>>>>>>> fake_migrate... Just leave everything to migrate=False should be
>>>>>>>> alright if
>>>>>>>> you dump contains all the tables...
>>>>>>>>
>>>>>>>> Richard
>>>>>>>>
>>>>>>>> On Mon, Feb 22, 2016 at 4:55 PM, Brian M <bmer...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I seem to have run into a problem with tables I'm using
>>>>>>>>> _enable_record_versioning() with. I'm setting up on a new computer
>>>>>>>>> and have
>>>>>>>>> restored a DB backup to the new computer. Now when I try to run pages
>>>>>>>>> that
>>>>>>>>> utilize those tables the database is complaining that the _archive
>>>>>>>>> tables
>>>>>>>>> already exist. I've tried
>>>>>>>>> db.table_name._enable_record_versioning(fake_migrate=True) but that
>>>>>>>>> argument isn't expected. I've tried using fake_migrate_all=True in
>>>>>>>>> the DAL
>>>>>>>>> connection but that doesn't do it either. So what can I do to get
>>>>>>>>> web2py to
>>>>>>>>> recognize that the archive table is already there and it doesn't need
>>>>>>>>> to
>>>>>>>>> try to recreate it.
>>>>>>>>>
>>>>>>>>> Brian
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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+un...@googlegroups.com.
>>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>> 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+un...@googlegroups.com.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>> --
>>>>> 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+un...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>> --
>>> 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+un...@googlegroups.com <javascript:>.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
--
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.
