View Issue Details

IDProjectCategoryView StatusLast Update
0005048SymmetricDSBugpublic2022-08-02 21:02
Reporterkraynopp Assigned Toelong  
Prioritynormal 
Status closedResolutionnot fixable 
Product Version3.12.10 
Summary0005048: Tables may become out of sync if ad-hoc trigger exist
DescriptionIf tables are modified by ad-hoc trigger, changes are rejected due loop protection mechanism.
Steps To Reproduce1. Exists two tables in oracle:
CREATE TABLE DATA.SYMTESTMAIN
( ID NUMBER(5,0) NOT NULL ENABLE,
    DATA VARCHAR2(200 BYTE),
    CONSTRAINT "SYMTESTMAIN_PK" PRIMARY KEY ("ID")
);

CREATE TABLE DATA.SYMTESTPROTO
( ID DATE NOT NULL ENABLE,
    CONSTRAINT "SYMTESTPROTO_PK" PRIMARY KEY ("ID")
);

2. And in PostgreSQL
CREATE TABLE data.symtestmain
(
    id numeric(5,0) NOT NULL,
    data character varying(200),
    CONSTRAINT symtestmain_pkey PRIMARY KEY (id)
);

CREATE TABLE data.symtestproto
(
  id timestamp(0) without time zone NOT NULL,
  CONSTRAINT symtestproto_pkey PRIMARY KEY (id)
);
Both tables are included in syncronization

3. Trigger in Oracle:
CREATE OR REPLACE TRIGGER DATA.SYMTESTMAINTRG
before delete or insert or update on data.symtestmain
for each row
begin
  insert into data.symtestproto (id) values (sysdate);
end;
This trigger adds row in symtestproto table on every insert, update and delete row in symtestmain table. Trigger exists only in Oracle.

4. Add row in symtestmain of PostgreSQL database
id data
1 qwe

5. This row is successfully captured.
sym_data in PostgreSQL:
data_id table_name event_type row_data pk_data old_data trigger_hist_id channel_id transaction_id source_node_id external_data node_list create_time is_prerouted
268 symtestmain I "1","qwe" 305 dev-main-channel 1955924 2021-07-06 11:07:33.899489 0

6. Data transferred in oracle, trigger SYMTESTMAINTRG fired, row added into SYMTESTPROTO table. Data captured.
sym_data in Oracle:
DATA_ID TABLE_NAME EVENT_TYPE ROW_DATA PK_DATA OLD_DATA TRIGGER_HIST_ID CHANNEL_ID TRANSACTION_ID SOURCE_NODE_ID EXTERNAL_DATA NODE_LIST CREATE_TIME IS_PREROUTED
12021 SYMTESTPROTO I "2021-07-06 11:07:50" 134 dev-main-channel 7.62.1576616 000 06.07.2021 11:07:50,503222000 0
12022 SYMTESTMAIN I "1","qwe" 133 dev-main-channel 7.62.1576616 000 06.07.2021 11:07:50,585466000 0

SOURCE_NODE_ID of both rows is set to 000, however only row in SYMTESTMAIN comes from 000 node. Row in SYMTESTPROTO table will not be transferred to 000 node (PostgreSQL) and table symtestproto in PostgreSQL will remain empty.
TagsNo tags attached.

Activities

kraynopp

2021-07-06 09:16

reporter   ~0001964

I do not know how to insert table here, so add screenshots.
ora_sym_data.png (6,089 bytes)   
ora_sym_data.png (6,089 bytes)   
pg_sym_data.png (15,198 bytes)   
pg_sym_data.png (15,198 bytes)   

elong

2022-08-02 21:02

developer   ~0002137

Unfortunately, it's working as designed, and I don't see a way to fix it systemically. A workaround is to manipulate the loop protection by setting the source node ID to null in your custom trigger (SYMTESTMAINTRG). You'd need to get the current source node ID from sym_pkg.disable_node_id and assign it to a variable. Then call sym_pkg.setNodeValue(null) to set source node ID to null. Then perform the insert to symtestproto. Then set the source node ID back to its original value.

Issue History

Date Modified Username Field Change
2021-07-06 08:52 kraynopp New Issue
2021-07-06 09:16 kraynopp Note Added: 0001964
2021-07-06 09:16 kraynopp File Added: ora_sym_data.png
2021-07-06 09:16 kraynopp File Added: pg_sym_data.png
2022-08-02 21:02 elong Assigned To => elong
2022-08-02 21:02 elong Status new => closed
2022-08-02 21:02 elong Resolution open => not fixable
2022-08-02 21:02 elong Note Added: 0002137