You almost got it....move form, move container, re-move form. This has been one of those 'trial and error' things...the problem lies here...container A knows that form is a member of it...if you just update the container...the container b can't say that the form is a member of it because the form doesn't exist....but if you move the form then the container denies ownership (in a manner of speaking)...so the form must first exist on server b for the container to accept ownership...then you re-import form onto server b and the container no longer balks about it not belonging to it...so it lets you import with the permissions you have set.
_____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook Sent: Tuesday, September 25, 2007 10:33 AM To: [email protected] Subject: Re: Migrating/Importing forms from Deployable apps ** I think I get it, but let's see. So I import the subset of form(s) from the DA(s), which strips the Roles from the forms. Then just importing the blank application container(s) restores those roles to the forms? Is that documented somewhere, or is this a little gem from your own research and analysis? Rick On 9/25/07, L. J. Head <[EMAIL PROTECTED]> wrote: ** I'm not talking about an "Export Application"...I'm talking about go into applications, right click on the application in question, export to def. This will generate a def file similar to just a form export but of the application instead....not all of the definitions of the app along with data, blah blah blah. Do you get the difference? Oh...and BTW...if you use Migrator there is a switch somewhere that tells it to migrate the app first (same part I'm talking about) and then the form so that everything is updated properly including permissions _____ From: Action Request System discussion list(ARSList) [mailto: _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
