Updating CES Database Manually Updating the CES Database Automatically
Following are steps to update your existing CES database from one release to another:
NOTE: Take a backup of your CES database prior to proceeding with the migration.
Configure your CES database using DBLoad utility. For details, see Configuring DBLoad Utility for more details.
Run the migration script which is provided as part of the distribution. Format of the distribution is:
<OS_a>/resources/sdm/sdmdb/dbUpdate/<Release Name> where <OS_a> - refers to the supported platform of the software. For example, intel_a for Windows, and aix_a for IBM AIX operating systems <Release Name> - refers to name of the release to which CES database can be migrated. For example, R17SP3 contains changes made for R17 SP3 from previous release (that is, R17 SP2). On Windows: Change the directory to <CES Installation directory>\intel_a\resources\sdm\sdmdb\dbUpdate\<Release Name>. For example, cd E:\DS\R17SP3\intel_a\resources\sdm\sdmdb\dbUpdate\R17SP3 Run the batch file dbUpdate.bat. You are prompted to enter value for XJS_HOME (this is the path where CES Server is installed). For example, E:\DS\R17SP3\intel_a\resources\sdm\exploreJS You are prompted to enter value for DBLABEL (this is the value of the database label as configured in the dbload.cfg file). For example, CESDB. On AIX: Change the directory to <CES Installation directory>/aix_a/resources/sdm/sdmdb/dbUpdate/<Release Name>. For example, cd /software/applications/DS/R17SP3/aix_a/resources/sdm/sdmdb/dbUpdate/R17SP3 Edit the script dbUpdate.sh Set the value for XJS_HOME (this is the path where CES Server is installed). For example, /software/applications/DS/R17SP3/aix_a/resources/sdm/exploreJS Set the value for DBLABEL (this is the value of the database label as configured in dbload.cfg file) For example, CESDB Grant the execute permission on the script (if not available) by using chmod 755 dbUpdate.sh command. Run the script dbUpdate.sh. For example: In K shell $ ./dbUpdate.sh
<OS_a>/resources/sdm/sdmdb/dbUpdate/<Release Name>
where <OS_a> - refers to the supported platform of the software. For example, intel_a for Windows, and aix_a for IBM AIX operating systems <Release Name> - refers to name of the release to which CES database can be migrated. For example, R17SP3 contains changes made for R17 SP3 from previous release (that is, R17 SP2).
where
<OS_a> - refers to the supported platform of the software. For example, intel_a for Windows, and aix_a for IBM AIX operating systems
<Release Name> - refers to name of the release to which CES database can be migrated. For example, R17SP3 contains changes made for R17 SP3 from previous release (that is, R17 SP2).
On Windows: Change the directory to <CES Installation directory>\intel_a\resources\sdm\sdmdb\dbUpdate\<Release Name>. For example, cd E:\DS\R17SP3\intel_a\resources\sdm\sdmdb\dbUpdate\R17SP3 Run the batch file dbUpdate.bat. You are prompted to enter value for XJS_HOME (this is the path where CES Server is installed). For example, E:\DS\R17SP3\intel_a\resources\sdm\exploreJS You are prompted to enter value for DBLABEL (this is the value of the database label as configured in the dbload.cfg file). For example, CESDB.
On AIX: Change the directory to <CES Installation directory>/aix_a/resources/sdm/sdmdb/dbUpdate/<Release Name>. For example, cd /software/applications/DS/R17SP3/aix_a/resources/sdm/sdmdb/dbUpdate/R17SP3 Edit the script dbUpdate.sh Set the value for XJS_HOME (this is the path where CES Server is installed). For example, /software/applications/DS/R17SP3/aix_a/resources/sdm/exploreJS Set the value for DBLABEL (this is the value of the database label as configured in dbload.cfg file) For example, CESDB Grant the execute permission on the script (if not available) by using chmod 755 dbUpdate.sh command. Run the script dbUpdate.sh. For example: In K shell $ ./dbUpdate.sh
Running migrate script generates files with extensions .err, .stat, .upr. .err - contains error information .stat - contains status information .upr - contains unprocessed records For example, the files generated after the upgrade are: Modify_PartFamilySettings_Attr.dbl.err Modify_PartFamilySettings_Attr.dbl.stat Modify_PartFamilySettings_Attr.dbl.upr Check for errors (if any) in ".err" file and take action accordingly.
Modification of existing attributes or properties in a specific category or class: These are considered high impact changes. If the changed category is used by the user and contains data, that data may have to be recreated, depending on the actual changes made to the attribute(s). Examples of this kind of change are: changing the label of a property, changing the mandatory status of a property, or changing a normal property to a primary key. Creating or modifying forms for a specific category or class: These are considered high impact changes. If a form is modified during or after deployment, as part of customization, then a change to the out-of-the-box version of the same form will create conflict and have to be resolved manually, to retain the customization. Adding a new attribute or property to a specific category or class: These are considered low impact, since they do not impact the existing setup. Adding a new category or class: These are considered low impact, since they do not impact the existing setup.
All data model changes made during any main cycle, for example a new release, a service pack, etc. are provided as CES DBLoad files. These changes are distributed with clear demarcation in the package. For example, R1n SPx changes are available in <OS_a>/resources/sdm/sdmdb/dbUpdate/R1nSPx, where n is the last number on the release (R17, R18, etc) and x is the number of the service pack (SP1, SP2, etc.).
This process can be carried out manually, but it is difficult and time consuming. The difficulties associated with manual updating include:
setting up DBLoad and running the scripts manually configuring the DBLoad utility is not easy there is no information in the database to determine which data model changes are applied messages displayed while running the DBLoad utility cannot be interpreted trouble shooting this process is difficult
To make this process easier, an automated method is provided as a stand-alone tool, CESDBUpdate. This tool does the following:
Determines the existing level of the CES database Executes the scripts to update the CES database to the requested level Interprets messages generated during script execution and reports meaningful information to the user.
For information about configuring the dbload.cfg file, refer to Configuring the DBLoad Utility.
Ensure that the JDBC thin driver files are copied to the CES Installation directory, <OS_a>/docs/javacommon where <OS_a> refers to the supported platform of the software, for example, intel_a for Windows or aix_a for IBM AIX.
For an Oracle database on Windows, the JDBC thin driver files (classes12.zip and ojdbc14.jar) are located under %ORACLE_HOME%\jdbc\lib directory, where %ORACLE_HOME% refers to the installation directory of the Oracle software. For an Oracle database on UNIX, the JDBC thin driver files (classes12.zip and ojdbc14.jar) are located under $ORACLE_HOME/jdbc/lib directory, where $ORACLE_HOME refers to the installation directory of the Oracle software. For a DB2 database on UNIX, the JDBC thin driver files (db2jcc.jar and db2jcc_license_cu.jar) are available under $DB2_HOME/java directory, where $DB2_HOME refers to the installation directory of the DB2 software.
For an Oracle database on Windows, the JDBC thin driver files (classes12.zip and ojdbc14.jar) are located under %ORACLE_HOME%\jdbc\lib directory, where %ORACLE_HOME% refers to the installation directory of the Oracle software.
For an Oracle database on UNIX, the JDBC thin driver files (classes12.zip and ojdbc14.jar) are located under $ORACLE_HOME/jdbc/lib directory, where $ORACLE_HOME refers to the installation directory of the Oracle software.
For a DB2 database on UNIX, the JDBC thin driver files (db2jcc.jar and db2jcc_license_cu.jar) are available under $DB2_HOME/java directory, where $DB2_HOME refers to the installation directory of the DB2 software.
This task explains how to update the CES database automatically:
The CESDBUpdate tool is run from the command line. In Windows: CATStart -run CESDBUpdate.bat -env ENOVIA_CES.V5R18 -direnv /sdm/data/applications/CES_Indus/LCANav_Patch/R18REL In UNIX: catstart -run CESDBUpdate.sh -env ENOVIA_CES.V5R18 -direnv /sdm/data/applications/CES_Indus/LCANav_Patch/R18REL
During the update process you will be prompted for various pieces of information.
The following is an example of running the script and entering the necessary information, when prompted:
Once you have entered the necessary information, the update process begins. The following is an example of the display that may occur during the update process.
Once the update process has finished, the following is output:
You can also find details of the update in the CES_RELEASE_INFO table.
If you happen to run the CESDBUpdate tool after the database has already been updated, you may see something like:
If you happen to enter the wrong password, you may see something like this: