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