Kbase P174808: Replication Agent seems to terminate after a tablemove is done to a table in the database.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
07/10/2010 |
|
Status: Unverified
SYMPTOM(s):
Replication Agent terminates after a tablemove is done to a table in the database.
Table <tableString> []<tableNum> has been moved to area <tareaName> []<tareaNum>. (8613)
All indexes associated with table <tableString> []<tableNum> have been moved to area <tareaName> []<tareaNum>. (8614)
Source database is showing that the Replication Agent is terminating.
The Fathom Replication Agent <agent-name> is requesting to be terminated. (10699)
The Fathom Replication Agent <agent-name> is being terminated. (10700)
All Fathom Replication Agents have been terminated or have ended. (10702)
The Fathom Replication Server will shutdown but the source database will remain active. (10698)
The Fathom Replication Server is ending. (10505)
The target database is showing error 1028 and 10428.
SYSTEM ERROR: Rollforward Apply AI note, BKUPDCTR=<number>, note updctr=<number>. (1028)
Function <functionname> failed in <functionname> with error <error>. (10428)
Diagnost errors are also written to the target database log file.
Diagnostic Dump of RLAIRollFState_t - After Apply Failure
Diagnostic Dump of RPAIBlock_t - After Apply Failure
Diagnostic Dump of RPNote_t - After Apply Failure
Diagnostic Dump of Current AI Block - 71662 length 16384 bytes
FACT(s) (Environment):
Command: proutil dbname -C tablemove
Table does get moved appropriately in the source and target databases.
All Supported Operating Systems
OpenEdge 10.x
OpenEdge Replication
CAUSE:
Bug# OE00154383
CAUSE:
OM Cache is not updated on the target database after a table move.
FIX:
None at this time.
A workaround for this issue is to "bounce/restart" the target database so that you can then access the moved records associated with the table that was moved.