Correcting Adaptive Server Error

Identify and fix the Adaptive Server problem causing the replication error.

1. Log in to the RSSD and execute the rs_helpexception:

   1> rs_helpexception
   2> go

   Summary of Logged Transactions on ‘westernRS’
   Total # of Logged Transactions = 1
   Xact ID Org         Site Org User Org Date Dest Site #        Recs/Xact
   ------------------- ------------- ------------- ------------- ---------
   107 mil01hprdss.eur eurian        Jun 13 2006   westernDS.eur         3
   For Detailed Information on a Logged Xact., type ‘rs_helpexception
   {XactID}’
   (return status = 0)

2. To show the entire text of the transaction, execute rs_helpexception with the v option and the transaction ID from step 1:

   1> rs_helpexception 107, v 
   2> go

   You see:

   Detailed Summary of Logged Transaction # 107 on 'westernRS'
   Origin Site            Origin User   Org. Commit Date    #Cmds in Xact
   --------------------   -----------   -----------------   -------------
   westernDS.westDB       eurian        Jun 13 2006 12:24               3
   
   Dest. Site             Dest. User    Date Logged
   --------------------   -----------   -----------------
   westernDS.westDB       …eurian       Jun 13 2006 12:27
   
   This transaction was logged by the ‘sysadmin log_first_tran’ command.
   
   Rejected Records
   textval
   ----------------------------------------------------------------
   A0100distribute :origin_time=’Jun 13 12:24:24:416PM’,:origin_user=‘’,
   :mode=1
   begin transaction ‘logexec’ for ‘eurian’/’******’
   begin transaction
   A0100distribute :origin_user=’’,:mode=1
   exec “TT”.”so_req_rep_all_allcon” @”p01”=80000709,@”p02”=’MIL’
   execute tt_act_rep_all_allcon @p01 = 80000709, @p02 = ‘MIL’
   A0100distribute :origin_time=’Jun 13 12:24:416PM’,:origin_user=‘’,
   :mode=1
   commit transaction
   execute rs_update_lastcommit @origin = 107,@origin_qid =0x00000001004620
   d300019296000effffffff000000008910009bd7cd0001000000000001,
   @ secondary_qid =0x000000000000000000000000000000000000000000000000000
   000000000000000000000, @origin_time = ‘Jun 13 12:27:227PM’
   commit transaction
   (return status = 0)

   This text corresponds to what is sent to the database (in this case, function strings have been applied).
3. Use the transaction information to manually apply the update to the replicate database.
4. After fixing the error in the database, resume the connection in the Replication Server:

   > resume connection to westernDS.westDB
        skip transaction

5. Delete the transaction from the exceptions log to keep the log small:

   1> exec rs_delexception 107
   2> go

   You can use rs_delexception_id to delete a range of transactions identified by transaction ID. You can also use rs_delexception_date to delete a range of transactions identified by transaction date, and rs_delexception_range to delete a range of transactions identified by originating site or user, or destination site. See the descriptions of the stored procedures in Replication Server Reference Manual > RSSD Stored Procedures for complete usage information and more examples.