Conference iosg::all-in-1_v30

    Track down all the forms in CM$SITELOG and change their live location
    to be something like OA$LIB_ENGLISH:HDK.FLB (use a script to do this),
    then move them all back into development, and then move them back into
    the live area. By doing it this way CM will preserve all the links and
    allow you to continue working. You also don't screw up CM$SITELOG and
    cause potential problems with CART.
    
    Inside of including the FLB in a user's profile record it's possibly
    better to have an application initialization script that checks whether
    the user has access to the application before it opens the FLB. That
    keeps ALL-IN-1's initialization time at a reasonable level (no
    degradation by additional FLBs being opened) and avoids taking the file
    open hit until people actually want to use the application.
    
    Tony

    I have never looked at CM$SITELOG before. If I understand correctly,
    the directions you give would be to modify the existing system also.
    I think what I want to do is to, in a way, extract the application from
    siteoaform to hdk.flb without going through a lot moving from
    development to live etc. There must be fifty forms in this application
    by now. 
    
    Can I use the lib command to create the new forms library from the
    existing siteoaform?
    
    Dave Kinney

    Yes, changing the details in CM$SITELOG will affect the way CM handles
    these forms in the future, but I believe that this is what you are
    trying to do in the long run.  After all, if you go through all the
    work to extract the forms and build another form library you'll end up
    with an FLB that can be used, but you'll have to rebuild the FLB every
    time changes are made to the application. Using a new live location
    (the FLB) means that CM will update the FLB automatically.
    
    Tony

    Tony,
    
    What do you mean by the FLB will have to be 'rebuilt' with every
    change? What process are you refering to from say a application support
    persons perspective?
    
    Is thare a reference to changing the CM$SITELOG in one of the manuals?
    
    Thanks for all the advice.
    
    Dave Kinney

    Well, if you leave the forms in CM and move them into HDK.FLB to
    distribute to other sites, what happens when you update a form (in CM
    hopefully)?  You'll have to insert the updated form into HDK.FLB again!
    That's what I mean by having to rebuild the application form library
    after changes are made.
    
    CM$SITELOG is an entry form so use CRTL/V to get a list of fields. The
    one that you're interested is in the LIVE_DISK_LOCATION which will
    change from OA$SITE_LIB_ENGLISH:SITEOAFORM.FLB to something like
    OA$SITE_LIB_ENGLISH:HDK.FLB.  
    
    Tony

    
    Dave,
    
    Some additional info for transferring your elements to another system:
    
    When creating an element in ALL-IN-1 V2.4 a form is displayed in which
    you can enter general information about the element. One of the fields
    is 'Application'. By entering a reference to you 'application' these
    elements are grouped together within ALL-IN-1. At first sigth this is
    not too usefull, but...
    
    For ALL-IN-1 V2.3/V2.4 an Asset called GIP (Generic Installation
    Procedure) existed (although it's on the list of retirement) to package
    elements which could be unpacked on another system. This way you don't
    have to do this by hand (as you mentioned Scripts next to the form
    library). One of the search criteria when packaging is the
    'Application' value, so in one go you could select all elements.
    
    In ALL-IN-1 V3.0 standard functionality is the Package/Restore which
    allows you to pack elements (or a complete application) into a saveset,
    which can be restored on the receiving system.
    
    The result is that the elements restored are recorded in Customization
    Management again, so that system will know about these modifications
    and allows e.g. the CART (for ALL-IN-1 V3.0) to include these elements
    when checking your systems (as explained by Tony).
    
    Ciao,
    
    	Simon
    
    

    Stay away from GIP. It is dead in the water now and any kit that you
    build with GIP has to be rebuilt for ALL-IN-1 V3.0.  
    
    I don't think you need a tool as complex as the GIP anyway.  You only
    want to transfer a form library (or so you've said), so all you have to
    do is make sure that the forms are stored by CM in a suitable live location
    for everything to work...
    
    Tony

    
    My wife asked me a question about this and I got to thinking. She said,
    Why don't you just take the siteoaform, maybe rename it to avoid
    confusion, from the system with the application already running, and use 
    it at the other system as a source input for CM installing the forms at 
    the next site. Since there are only two other sites, It may take slightly 
    longer, but in both processes you have to touch every form anyway so whats 
    the difference? 
    
    The one major difference is that I don't have a portable application
    this way, but I figured why not ask. What do you think?
    
    Dave.

    Same reason as given before. Your approach (or your wife's approach) is
    fine as long as changes are never made to the application on the
    originating site. But this is unlikely to happen (for most
    applications) so I think it best to set things up properly from the
    start.
    
    T