Resolution:
Description: An Oracle database is assumed and all InConcert servers MUST have the same InConcert server ID.

These instructions assume you already have separate installation of the
InConcert server each pointing to a separate instance of the database server.  
The instructions are written for an Oracle database but they should hold true
for any database. It does not matter if the InConcert servers are on separate
hosts or on the same host.  Cloning an InConcert database can be done safely but
all steps must be done EXACTLY or the resulting cloned system will not run.  The
database owner of the Oracle database does not have to be the same in each
system but it may make things easier.

ALL InConcert servers must be of the same version of InConcert.  You can update
the SERVER_ID in the configuration files of the host you copied the database to.  NEVER update
the SERVER_ID in the database!!!!  Also never update the INIT_DB_VERSION after you copy over the database.  That will cause the EAD to fail because the INIT_DB_VERSION  is baked into the initial object IDs that the database is populated for BASE JOB TEMPLATE and icdba.


1.  Stop the InConcert server to be copied and do a full backup of all tables of
the InConcert tablespace.  Include the Oracle Sequence in the backup.  A hot backup of Oracle does not guarantee a
consistent database.  You may also want to backup the targeted system database
in case there are any problems with the clone of the system.

2.  Winzip or tar up all files in the repository directory.

3.  Stop the InConcert server you will be updating.

4.  Restore the tablespace in the new database.  Copy in the ALL the InConcert
repository files from the first server to the new repository directory.

5.If this is for TIBCO InConcert 7.1 or above you should use the IcBatchRegistry to update the LOCATION and PARTITION otherwise use SQL commands below.

In SQL*PLUS update the REPOSITORIES LOCATION and PARTITION if the host, port
or repository directory is different.  In sqlplus do:
update repositories
set location= '&ltnew_host>:port';
update repositories
set partition='&ltnew_fully_qualified_path>';

6.  If the logical name of the InConcert servers are different then that should
be updated in the database.  In SQL*PLUS do 'update SERVER_NAMES set
SERVER_NAMES="&ltname of target server>";'

If you are at InConcert 7.2 and above or BWC 5.3 or above then SERVER_NAMES.GLOBAL_ID and HOST MUST be updated.  The old host name in both cases should be updated to have the new host name.  If you leave the GLOBAL_ID the same then the EAD of the original and cloned system will form a fault tolerant pair and only one will be active.

7.  If the server id values were different between installations then the value of IC_SERVER_ID in IC_HOME/config/current.cfg must be updated to match what is in the database in SERVER_NAMES.SERVER_NUMBER.  NEVER update the SERVER_NUMBER value in the database!  

NOTE if this is TIBCO InConcert 6.2.1 or BW WF 5.1 or above the current.cfg does not exist so no change is needed in configuration file.

NOTE if this is TIBCO InConcert 7.2 or above or BWC 5.3 or above then the server id must be change in icconfig.xml.  In the second line of the file you will find the server branch of the server_name id="xxxx" in my case this is GG_72 id="1123".  I would then need to update the "1123" to the server id in database I copied over.

8.  If you have triggers that publish messages you will need to separate out the messages which are publish so that development event agents do not get production and vice versa.  This can be done in two ways.  One is to have separate sub networks and to not route Rendezvous messages between the two.  The other is to you may wish to update the subject field of triggers in the database so the event agents have different subjects to publish on.  To modify the database to have the new subject field in SQL*PLUS this becomes 'update triggers set text='NewSubect' where ACTION_TYPE='5001'.  This will change all subject fields.  If no subject fields were specified when the trigger was created then you are all set because the default subject field is "TIBCO.IC.&ltserver_name>.EVENT.&ltevent_type>.

Trouble shooting:
If you get an error of "row not found" or the Event Action Daemon dies because
of a uniqueness violation then the backup of the database was done hot resulting
in an inconsistent database.  The "row not found" will also be caused by updating
SERVER_NAMES.SERVER_NUMBER.  NEVER do this!

If the InConcert PC GUI client will not run because it can not access some system
document then the FULL repository was not copied to the target system.

Guy

How to clone an InConcert database or migrating ALL InConcert data.