The web2py version is the same on both machines; I just copied my whole
web2py folder over. Now admittedly my web2py version is slightly out of
date so it might be something that's been improved recently. I've got a
patch for another issue that I need to pull and test tonight so I'll try to
make a test for this too.
The archive table was originally created by web2py. Yes, I did delete
.table files from /app/databases but they were the ones from the other
computer (different uuid hash in file name) and weren't being used anyway
so that shouldn't make a difference.
On Tuesday, February 23, 2016 at 11:22:06 AM UTC-6, Richard wrote:
>
> Pretty weird, but you have made some progress... So, to resume, it like if
> archive table were never really get created by web2py so it keeps trying to
> create it and failed since it already exist in the backend...
>
> So, there were an issue at the moment you start using the feature, or
> there is an error in the actual web2py version (did you upgrade web2py as
> long as migrating you system??, if so consider use the old web2py to see if
> the issue occuring... This would help determine if the issue is coming form
> new web2py version or not).
>
> Or could it be possible that you create the archive table manually back in
> time? Or that some file in app/databases/ folder get deleted??
>
> Richard
>
>
>
> On Tue, Feb 23, 2016 at 11:12 AM, Brian M <bmer...@gmail.com <javascript:>
> > wrote:
>
>> 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>
>>> 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> 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.
>>>>> 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.
