INSERT replicate fine but UPDATE fail for numerous rows of a replicating table.
The constraints on the target table which are not defined on source table may be the culprit.
When the DEFAULT constraints are defined on target table columns but not on the source table columns, then the INSERT which do not have any values specified for those column of the the source rows which have corresponding target rows with DEFAULT constraint specified for the target column will replicate fine. However, this may cause the target row to differ in content from the source row whereby the target column with DEFAULT constraint now has some value inserted in it. Shareplex will not detect this discrepancy until an UPDATE occurs on the source row. When the UPDATE DML reaches target and Post constructs a SQL, it is not able to find a matching row on target to UPDATE since the target row had different value to begin with (during INSERT). Application need to be modified whereby either the source table should also have the DEFAULT constraint defined on the problem column or such constraint should be done away at least on target. Moreover, if using pseudocolumn like SYSDATE for the DEFAULT, use it only on source and not on target.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center