Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

OI Deploy - New Table

Good afternoon Brains Trust.

I just want to check my procedure here as I have always had an issue deploying a new table.

Basically I add the new Table & Dict in the Repository:


This allows me to see them in the Deployment definition


I thought this should be enough. It didnt seemt to work.

So I went an extra step and added dictionary columns to the same deploy.


Basically, after applying the RDK insitially the Table existed and was attached but had no Dictionary. Running the RDK again applied the dictionary and everything looked ok. I validated this was the case on a 2nd system.

So my question is what am I doing wrong? What is the minimum required effort (i.e. settings/config in the Repositor/Deploy) to get a new table out the door and immediatly functioning with a single pass of the RDK.


Comments

  • Hi all,

    Sorry to flog a dead horse but I am still having issues with Table deploys.

    Basically some of these tables already exist on sites as they have been manually added over time.
    I can deploy all the relevant DICTs anywhere as they should be the same across the board (in theory anyway!).
    Fortunately none of the tables I want to deploy have indexes on them yet so my problem lies in the data tables.
    If I dont deploy the data tables then the tables arent there and can't be attached or used. If I do deploy, and its on a site that some of those tables already exists, then the data gets wiped out and replaced by an empty table.

    Is there a way to automate all that without manually checking a hundred sites for various tables?
  • edited September 2022
    I think, if you add the following to the %PROCESS% record it might do the trick. Files are checked with @tables and will be created if dont exist.

    [CREATE TABLES]
    volume/filename/dbid
    .
    .
    volume/filename/dbid

  • Thanks @BarryStevens.
    I will give that a try and see how I go.
  • @BarryStevens

    I know this has been a bit but finally got around to giving this a bit of a test. These are my findings:

    I originally had this
    [COPY TABLES] .\APPDATA\DATA/DICT.EMPLOYEE_SIMTRANS/GLOBAL .\APPDATA\DATA/DICT.MATERIAL_SIMTRANS/GLOBAL .\APPDATA\DATA/EMPLOYEE_SIMTRANS/GLOBAL .\APPDATA\DATA/MATERIAL_SIMTRANS/GLOBAL
    This would do as I noted above. Create Dictionaries and Deploy the Table, either with the data of the source or an empty table. As noted, I didnt want existing tables being overwritten.

    I manually modied the %PROCESS% Record as you suggested in my deploy (attached the Volume and then edited the SYSUPGARDE record before saving and detaching to test.)

    I tried this (which seemed to create the tables if they didnt exist, leave them alone if they did but did NOT create the Dictionaries if they didnt exist.)
    [COPY TABLES] .\APPDATA\DATA/DICT.EMPLOYEE_SIMTRANS/GLOBAL .\APPDATA\DATA/DICT.MATERIAL_SIMTRANS/GLOBAL [CREATE TABLES] .\APPDATA\DATA/EMPLOYEE_SIMTRANS/GLOBAL .\APPDATA\DATA/MATERIAL_SIMTRANS/GLOBAL

    I thought order might be important so I tried this (no difference):
    [CREATE TABLES] .\APPDATA\DATA/EMPLOYEE_SIMTRANS/GLOBAL .\APPDATA\DATA/MATERIAL_SIMTRANS/GLOBAL [COPY TABLES] .\APPDATA\DATA/DICT.EMPLOYEE_SIMTRANS/GLOBAL .\APPDATA\DATA/DICT.MATERIAL_SIMTRANS/GLOBAL

    and this (with no joy):
    [CREATE TABLES] .\APPDATA\DATA/DICT.EMPLOYEE_SIMTRANS/GLOBAL .\APPDATA\DATA/DICT.MATERIAL_SIMTRANS/GLOBAL .\APPDATA\DATA/EMPLOYEE_SIMTRANS/GLOBAL .\APPDATA\DATA/MATERIAL_SIMTRANS/GLOBAL

    Just to restest, I went back to original:
    [COPY TABLES] .\APPDATA\DATA/DICT.EMPLOYEE_SIMTRANS/GLOBAL .\APPDATA\DATA/DICT.MATERIAL_SIMTRANS/GLOBAL .\APPDATA\DATA/EMPLOYEE_SIMTRANS/GLOBAL .\APPDATA\DATA/MATERIAL_SIMTRANS/GLOBAL
    Which DID create the dictionaries but also clobbered the data tables (as I expected )


    So, my 2 follow up questions:
    Am I doing something wrong so that the DIctionaries aren't being created using [CREATE TABLES]? It does seem to alleviate my data issue so I think this may be the right path.

    Utimately my common Use Case would be the DICTIonary always deployed with the Data table only being touched if it doesnt exist.

    If that all works as I hope is that something in the Deployment Manager to set, that I can't seem to see, in OI 9.4.6 or must I manually change the record to a CREATE each deploy instance (and hope nobody else regenerates it!) ?
  • looking at this it should work like that:
    [CREATE TABLES]
    .\APPDATA\DATA/EMPLOYEE_SIMTRANS/GLOBAL
    .\APPDATA\DATA/MATERIAL_SIMTRANS/GLOBAL
    [COPY TABLES]
    .\APPDATA\DATA/DICT.EMPLOYEE_SIMTRANS/GLOBAL
    .\APPDATA\DATA/DICT.MATERIAL_SIMTRANS/GLOBAL

    Is there anything in the upgrade log.

    I will do some testing at my end and see what I can see.
  • You might be interested in seeing this (I knew I kept it somewhere)

    DK Installation Processes


    One of the records in the SYSUPGRADE table, %PROCESS%, contains the instructions to be used during the installation process. Instructions are placed into this record in blocks, with a header at the top of the block indicating the process to perform. Below is a list of the installation processes:

    [CREATE TABLES] * To create tables
    VOLUME/TABLE/ACCOUNT
    VOLUME/DICT.TABLE/ACCOUNT

    [COPY TABLES] * To copy tables
    VOLUME/DICT.TABLE/ACCOUNT
    VOLUME/TABLE/ACCOUNT
    Create the dictionary in the deployment and copy all of the dictionary records into the SYSUPGRADE table; this will also create any indexes on that table that existed in the development system.

    [DELETE TABLES] * To delete tables
    TABLE

    [ATTACH TABLES] * To attach tables
    VOLUME/TABLE/ACCOUNT

    [DETACH TABLES] * To detach tables
    TABLE

    [ALIAS TABLES] * To alias tables
    TABLE/ALIASNAME
    Will alias a table in the RDK directory.

    [COPY OSFILE] * To copy OSFile
    ODIR/FILE

    [DELETE ROWS] * To delete rows
    TABLE/KEY

    [EXECUTE PROCEDURES] * To execute procedures prior to upgrading RDK
    PROGRAM NAME

    [DECLARE DLL] * To declare DLL
    NAME OF ROW IN SYSPROCS THAT DEFINES THE DLL

    [EXECUTE PROCEDURES POST] * To execute procedures after RDK upgrade
    PROGRAM NAME

    ******************************

    I think now the sequence should be:

    [CREATE TABLES]
    .\APPDATA\DATA/EMPLOYEE_SIMTRANS/GLOBAL
    .\APPDATA\DATA/MATERIAL_SIMTRANS/GLOBAL
    .\APPDATA\DATA/DICT.EMPLOYEE_SIMTRANS/GLOBAL
    .\APPDATA\DATA/DICT.MATERIAL_SIMTRANS/GLOBAL
    [COPY TABLES]
    .\APPDATA\DATA/DICT.EMPLOYEE_SIMTRANS/GLOBAL
    .\APPDATA\DATA/DICT.MATERIAL_SIMTRANS/GLOBAL

    This will create the tables if dont exist. DATA before DICT - covers both bases.
    this really should be creating the DICT as well as DATA
    .\APPDATA\DATA/EMPLOYEE_SIMTRANS/GLOBAL
  • @BarryStevens

    Handy little cheat sheet you have there.
    I will try your suggestion and report my results back.

    Cheers!
  • @opto_will

    One way you could control things is make use of the [EXECUTE PROCEDURES] where you could test for and create tables as needed, set a version number where needed etc etc

    Edit SYSUPGRADE %PROCESS% And ADD These 4 Lines
    ************************************************************************************

    [UPDATE ROWS]
    SYSOBJ/$MY_UPGRADE*MYAPP

    [EXECUTE PROCEDURES]
    MY_UPGRADE
  • @BarryStevens.

    I had definately been thinking of implementing something like that. I just didnt realise until you noted it that I could make that part of the Deploy.

    I take it that is a manual attach/edit of every deploy created?
  • Yes, because %PROCESS% gets recreated.
    btw, did you look at upgrade.log
  • @BarryStevens

    Fair enough. I expected as much. That will make our own little implementation of CI/CD (as rudimentary as it is at the moment) a little more difficult but that just means I need to implement better practices to manage it!

    Log file was pretty basic. I will pay more attention with each run when I get to retest with your suggestions but it was pretty much just a START/FINISH with nothing else. I cant remember what my last test was though...
  • @BarryStevens:

    What is the syntax in %PROCESS% (when executing procedures postupgrade) to include command-line arguments for function parameters?

    My subroutine is:
    Move_Values_Between_Fields(oldLocation, newLocation)

    When I add to %PROCESS%:
    [EXECUTE PROCEDURES POST]
    MOVE_VALUES_BETWEEN_FIELDS("PARAM.O.111", "PARAM.O.106")

    or:
    [EXECUTE PROCEDURES POST]
    MOVE_VALUES_BETWEEN_FIELDS "PARAM.O.111", "PARAM.O.106"

    I get this run-time error:
    SYS1000: Error loading program "MOVE_VALUES_BETWEEN_FIELDS("PARAM.O.111", "PARAM.O.106")"

    Adding:
    [EXECUTE PROCEDURES POST]
    MOVE_VALUES_BETWEEN_FIELDS

    finds the program, but of course nothing is passed to the parameters oldLocation and newLocation,
  • looking at the code it does the folloing to execute the proc.

    call @PostProc

    so, maybe research the call command.
  • @BarryStevens:

    Using the syntax in the Call statement for a list of arguments, the result is the same as before. From the error message it appears that the deployment program treats everything on the second line in %PROCESS%, from name of subroutine through argument list, as a single program to be loaded.
Sign In or Register to comment.