Hmm... About app/databases/ I don't know exactly all how it works, but I
think your issue come form there... uuid if there is one, would not have
anything to do with your computer, I am pretty sure of that, and you can
leave these files there for sure without any problem...
Though there surely some kind of issue with migrate=False,
fake_migrate=True if it failed to manage archive tables correctly and sync
web2py with the backend schema... This is a corner case, that may not have
been identify yet... You may consider creating a dummy app and try to
reproduce the issue with this app and test it with last version of web2py
to see if issue still there (if any).
test case :
- at least 2 tables with web2py versionning
- versionning should occur in a unique table
- delete app/databases/*
- try fake_migrate see if it fails
If you can reproduce this issue, in you actual web2py version and in a new
version, then open a ticket on github... So we all get aware of this
issue...
Thanks
Richard
On Tue, Feb 23, 2016 at 6:26 PM, Brian M <bmere...@gmail.com> wrote:
> 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> 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.
>>> 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.
>
--
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.
