How can the Project Build in Phire handle multiple kinds of record changes?

For example, can a Project Build be done through Phire that will handle a project that contains:

1. Create a new table
2. Alter a table to contain new columns
3. Alter a table to change column definitions
4. Alter a table to drop columns that contain data
5. Migrate a table with no structural differences

 

1 Comment »

  1. Admin said,

    February 1, 2016 @ 5:25 pm

    The main thing to understand, that will probably explain very quickly is to say that the project build is ultimately performed through an API call to Application Designer.

    The build is launching for the project being migrated using the build settings that the developer/migrator have provided through the Phire page online. These are the default build settings that we recommend and many customers use:

    Build Options: Create Tables, Create Indexes, Create Views, Alter Tables, Create Trigger
    Build Execute Options: Execute and build script
    Table Creation Options: Skip if it already exists
    View Create Options: Recreate if it already exists
    Index Create Options: Recreate only if modified
    Drop Column Options: Drop column if data present
    Change Column Length Options: Truncate if field too short
    Alter Any: Adds, Changes, Renames, Deletes
    Alter even if no changes: unchecked
    Alter Table Options: Alter by Table Rename

    With these settings, App Designer can handle all of the described cases in a single project build attempt. Remember, it is comparing each individual record definition against the table structure in the target database, and would treat each item accordingly. This is true whether running the process through Phire or manually through App Designer.

    To be specific, the new record would generate a “create table” command. Since the other tables already exist, and because we selected the Table Create Option of “Skip if it already exists” they would not be dropped/created, rather they would be altered. And the rest of the alter-related options here would cause each item to generate appropriate “alter table” commands – new columns would be added, deleted columns would be dropped, etc. If there happened to be a record in the project that didn’t change structure, it’ll be unaffected in this example.

    You also have the option of running the migration with “Build script file” selected, rather than “Execute and build script”, so you can just review it without running it automatically. The script could be downloaded from the Phire history and executed manually off-line if necessary.

    You also have the option of selecting to just “Create tables” or “Alter tables” rather than do it all in one pass. Once the migration is complete, the Migration page would present a “Build” button that will re-launch the project build with different settings possibly. So you could create tables on one pass, alter on another.

    If you needed to do something really extraordinary that can’t be addressed by these options, then you can turn off the build for any given migration and do it manually.

    It’s really very simple at that point. In our experience, it’s almost never necessary to change the build settings from these defaults show above. App Designer does a good job of managing the individual items during the process according to rules that PeopleSoft employs, and Phire leverages that very conveniently for you.

RSS feed for comments on this post

Leave a Comment

You must be logged in to post a comment.