The Update process will install the last product version available without API or database changes.

To update the product to the last available version, use the following command:

$ ./install.sh update

With the new version it is necessary to import the new databases of dictionaries. First, rename the existing databases. The bootstrap configuration database can be upgraded using the tool setup.

Rename the existing database wic and wic_admin, import the new and set transactions. It is important to state that for the same action there are two different paths.

• Option A (without database replication):

  Copy

  $ echo "rename database wic to wic_old;" | dbaccess - -                
  $ dbimport wic -d d_wics
  $ ontape -s -U wic

  The same for the wic_admin database:

  Copy

  $ echo "rename database wic_admin to wic_admin_old;" | dbaccess - -                
  $ dbimport wic_admin -d d_wics
  $ ontape -s -U wic_admin

  The third line ontape -s -U wic can be deleted if the command -l is added in the second one as explain in Option B.

• Option B (with database replication):

  The order -l is used to import the DB into transnational mode, which is the function of the ontape -s -U wic command. Then, the same action can be done with this other path:

  Copy

  $ echo "rename database wic to wic_old;" | dbaccess - - 
  $ dbimport wic -d d_wics -l

  The same for the wic_admin database:

  Copy

  $ echo "rename database wic_admin to wic_admin_old;" | dbaccess - - 
  $ dbimport wic_admin -d d_wics -l

The configuration database requires a schema conversion to update its structures to the new version.

Use the tool setup to upgrade the database:

bin/studio.sh --setup

+-----------------------+-----------------------------------------------------------------------------------------+------+
 Configuration status
+-----------------------+-----------------------------------------------------------------------------------------+------+
|key                    |value                                                                                    |state |
+-----------------------+-----------------------------------------------------------------------------------------+------+
|Config                 |/home/axional/studio/conf/config.xml                                                     |OK    |
|Temp                   |/home/axional/studio/tmp/axional-28177                                                   |OK    |
|JDBC protocol          |jdbc:informix-sqli                                                                       |OK    |
|JDBC host              |192.168.100.11                                                                           |OK    |
|JDBC port              |9088                                                                                     |OK    |
|JDBC service           |ol_dbsrv1                                                                                |OK    |
|JDBC username          |informix                                                                                 |OK    |
|JDBC password          |CRYPT-AES128:EJ9cGH7Pnb+vNkGj0fzc5p5LvbWTzifU90R1khUovyYwNiw8FcsYAerU+GoxJ6tvGIAuB2l+uUQ0|OK    |
|Dict wic database      |wic                                                                                      |OK    |
|Dict wic_admin database|wic_admin                                                                                |OK    |
|Configuration database |wic_conf                                                                                 |OK    |
|Configuration tables   |205 of 205 tables                                                                        |OK    |
|Configuration user     |manager                                                                                  |OK    |
|Conversion wic_admin   |Last [335] Current [335]                                                                 |OK    |
|Conversion auto file   |Last [5] Current [-1]                                                                    |FAILED|
+-----------------------+-----------------------------------------------------------------------------------------+------+

Type 'status database' for a complete database schema status
Press ? for help
setup $>

As the example illustrates, the conversion level for the wic_admin is the last 335 and no file conversions have been passed yet.

Follow these steps to apply conversions:

1. First of all, execute the command to create the new tables:

   Copy

   setup $>create tables

2. Load master data. This takes no effect in tables with rows:

   Copy

   setup $>load

3. Upgrade the schema. This process applies the conversions from files:

   Copy

   setup $>upgrade

4. The next command executes the statements to repair the differences from the model:

   Copy

   setup $>statusRepair

5. Compile SPLs and triggers:

   Copy

   setup $>create procedures

6. Check conversion levels:

   Copy

   setup $>status

Since this moment, there are 2 rows in wic_version table of configuration database, one for the wic_admin catalog and one for AUTO files conversions.

The levels stored are the current level of conversions. For example:

SELECT * FROM wic_version

obj_dict               obj_level user_created         date_created

wic_admin                    335 informix             2014-03-24 18:27:05    
AUTO                           5 informix             2020-05-20 09:46:34

It indicates that the level from files ( AUTO conversions) is 2. In other words, it indicates that the last conversion passed was the file number 2, so the next one will be the number 3.

Labels used in the portal and desktop applications and utilities are stored in a table at the wic_conf. This labels should be updated using the option

setup $>load labels

of the setup tool.

Set the database to no logging:

ontape -s -N wic_custom -t /dev/null

Execute an update statitics for the database.

UPDATE STATISTICS LOW;

Access to Axional Studio from a browser with a user with access privileges to the wic database, and privileges to execute and create objects on the wic_custom database.

From the applications menu select the WIC Metadata database and open the Deployment folder to work with these two objects according to each step:

• STEP 1 [Compile code (spl)]: Drop all XUDFunction, XUDProcedure, Procedure and Trigger.
• STEP 2 [Compile model (ddl)]: Drop all index.
• STEP 3 [Compile model (ddl)]: Drop all check constraint.
• STEP 4 [Compile model (ddl)]: Create all new object (New tables, index and constraints).
• STEP 5 [Compile model (ddl)]: Upgrade all objects prior to this version.
• STEP 6 [Compile model (ddl)]: Table load.
• STEP 7 [Compile model (ddl)]: Create all check constraint.
• STEP 8 [Compile model (ddl)]: Create all index.
• STEP 9 [Compile model (ddl)]: Model status.
• STEP 10 [Compile code (spl)]: Create all XUDFunction, XUDProcedure, Procedure and Trigger.
• STEP 11 [Compile code (spl)]: Code status.

Drop all stored procedures and triggers.

Drop all primary constraint, foreign constraint, unique constraint and drop all indexes.

Drop all check constraint.

Deploy the scheme of the new tables implemented in the new version and which are not currently created in the database.

Load the rows in those tables that currently have 0 rows and in the wic there are catalogued default rows (Form wic_table_object_data).

Start the upgrade process. This process is based on two tables:

• wic_version:Table of the wic_custom database that contains a row with the value of the obj_level column equal to the highest value of the chg_seqno column of the wic_change_log table of the wic database before starting the update process.
• wic_change_log: Table of the wic database that contains the register of all the statement to execute for update the schema of your database to the schema of the new version.

The execution result of the update process shows the executed statement and its status for each change record number ( change_seqno column). You have to move to the last page and check the status of the last sentence.

As seen in the example, the update process has stopped with error in the registration number 939 (Column change_seqno equal 939).

The change_seqno column has a link that leads right where the record of the block of the statement that failed.

Analyze the block of the statements that have failed, and using the dbstudio tool we connect to the wic_custom database and try to solve the problem manually.

Once the error has been fixed, perform the following update to set the obj_level column of the wic_version table to the value of the change_seqno column, which is where the upgrade process has stopped:

UPDATE wic_version SET obj_level = 939 WHERE obj_dict = 'wic';

Repeat this step until you get the message " NO CONVERSION CHANGES PENDING" as shown in the following figure:

Create all check constraint.

Create all indexes, primary constraint, unique constraint and foreign constraint.

Run a model status. This process compares the schema of each table catalogued in the wic dictionary with actually is created in the wic_custom database. Then, if there are differences, generate a report with the sql instructions that resolve that difference.

To the right of each sql statement a button is shown that if we press it, execute on the wic_custom database the statement that fixes the difference.

If the sql statement was executed correctly, the message " REPAIR EXECUTED" will be displayed as shown in the following figure.

Repeat this step until no differences appear as shown in the following figure:

Create all stored procedures and triggers.

This process check that each procedure and trigger catalogued in the wic dictionary is compiled and its timestamp is later than the her modification date.

The process generates a report of the status of each stored and trigger procedure as shown in the following figure. Where the value of the status column is equal to " VALID" for all items.

Refresh statistics.

echo 'UPDATE STATISTICS LOW DROP DISTRIBUTIONS;' |dbaccess wic_custom

Set the database to logging if it has previously been set to no logging before starting the update process.

ontape -s -U wic_custom -t /dev/null

Set the database to no logging:

ontape -s -N customer -t /dev/null

Access Axional Studio from a browser with a user with access privileges to the customer database and all the dictionaries linked to it.

The process explained below must be carried out for each of the dictionaries linked to the customer database in order of precedence from highest to lowest for some steps and vice versa for others. For example, according to the figure below, in some steps you start in wic_custom and end in wic_icon. Nevertheless. for others it starts in wic_icon and end in wic_custom.

From the applications menu, select the first dictionary Metadata database and open the Deployment folder to work with these two objects according to each step:

• STEP 1 [Compile code (spl)]: Drop all XUDFunction, XUDProcedure, Procedure and Trigger.
• STEP 2 [Compile model (ddl)]: Drop all indexes.
• STEP 3 [Compile model (ddl)]: Drop all check constraint.
• STEP 4 [Compile model (ddl)]: Create all new object (New tables, indexes and constraints).
• STEP 5 [Compile model (ddl)]: Table load.
• STEP 6 [Compile model (ddl)]: Upgrade all objects prior to this version.
• STEP 7 [Compile model (ddl)]: Create all check constraint.
• STEP 8 [Compile model (ddl)]: Create all indexes.
• STEP 9 [Compile model (ddl)]: Model status.
• STEP 10 [Compile code (spl)]: Create all XUDFunction, XUDProcedure, Procedure and Trigger.
• STEP 11 [Compile code (spl)]: Code status.

Drop all stored procedures and triggers from all dictionaries linked to the customer database starting with the dictionary with lower precedence number to greater precedence number. Based on our example, it starts with the wic_custom dictionary and ends with the wic_icon dictionary.

Drop all primary constraint, foreign constraint, unique constraint and drop all indexes from all dictionaries linked to the customer database starting with the dictionary with lower precedence number to greater precedence number. Based on our example, it starts with the wic_custom dictionary and ends with the wic_icon dictionary.

Drop all check constraint from all dictionaries linked to the customer database starting with the dictionary with lower precedence number to greater precedence number. Based on our example, it starts with the wic_custom dictionary and ends with the wic_icon dictionary.

Deploy the scheme of the new tables implemented in the new version and which are not currently created in the database. The deploy must start with the dictionary with greater precedence number to lower precedence number. Based on our example, it starts with the wic_icon dictionary and ends with the wic_custom dictionary.

Load the rows in those tables that currently have 0 rows and in the dictionaries there are catalogued default rows (Form wic_table_object_data). The load must start with the dictionary with greater precedence number to lower precedence number. Based on our example, it starts with the wic_icon dictionary and ends with the wic_custom dictionary.

Start the upgrade process. This process is based on two tables:

• wic_version: Table of the customer database that contains a row for each dictionary linked to it. The value of the obj_level column is equal to the highest value of the chg_seqno column of the wic_change_log table of each dictionary.
• wic_change_log: Table of the dictionary database linked that contains the register of all the statement to execute to update the schema of your database to the schema of the new version.

The upgrade must start with the dictionary with greater precedence number to lower precedence number. Based on our example, it starts with the wic_icon dictionary and ends with the wic_custom dictionary.

The execution result of the update process shows the executed statement and its status for each change record number ( change_seqno column). You have to go to the last page or run the object again to check the status of the last sentence.

As seen in the example, the update process has stopped with error in the registration number 1351 (Column change_seqno equal 1351).

The change_seqno column has a link that leads right where the record of the block of the statement that failed.

Analyze the block of the statements that have failed and try to solve the problem manually.

Once the error is resolved, we can perform one of the following actions depending on the type of error and the solution adopted:

• If the error is caused by a situation that prevents the process from continuing, for example, locked table, database in logging mode, etc. Then we solve the problem and restart the process at the same point where it failed.
• If the error is caused by a failure in the current update log, we try to execute the previously corrected sql statements from the dbstudio tool, and then execute the following update to set the obj_level column of the wic_version table to the value of the change_seqno column, which is where the upgrade process has stopped:
  Copy

  UPDATE wic_version SET obj_level = 1351 WHERE obj_dict = 'wic_icon';

Repeat this step until you get the message " NO CONVERSION CHANGES PENDING" as shown in the following figure:

Create all check constraint. Start with the dictionary with lower precedence number to greater precedence number. Based on our example, it starts with the wic_custom dictionary and ends with the wic_icon dictionary.

Create all indexes, primary constraint, unique constraint and foreign constraint. Start with the dictionary with greater precedence number to lower precedence number. Based on our example, it starts with the wic_icon dictionary and ends with the wic_custom dictionary.

Run a model status. This process compares the schema of each table catalogued in the metadata dictionary with actually is created in the customer database. Then if there are differences, generate a report with the sql statements that solve the difference. Start with the dictionary with greater precedence number to lower precedence number. Based on our example, it starts with the wic_icon dictionary and ends with the wic_custom dictionary.

To the right of each sql statement a button is shown that if we press it, execute on the customer database the statement that fixes the difference.

If the sql statement was executed correctly, the message " REPAIR EXECUTED" will be displayed as shown in the following figure.

Repeat this step until no differences appear as shown in the following figure:

Create all stored procedures and triggers. Start with the dictionary with greater precedence number to lower precedence number. Based on our example, it starts with the wic_icon dictionary and ends with the wic_custom dictionary.

This process check that each procedure and trigger catalogued in the metadata dictionary is compiled and its timestamp is later than the her modification date. Start with the dictionary with lower precedence number to greater precedence number. Based on our example, it starts with the wic_custom dictionary and ends with the wic_icon dictionary.

The process generates a report of the status of each stored and trigger procedure as shown in the following figure. Where the value of the status column is equal to " VALID" for all items.

Refresh statistics.

echo 'UPDATE STATISTICS LOW DROP DISTRIBUTIONS;' |dbaccess customer

Set the database to logging if it has previously been set to no logging before starting the update process.

ontape -s -U customer -t /dev/null