Mario R. Carro

Hi, I'm having trouble with an installation (Firebird 3.0 on the SymDS server, just one client, with Firebird 2.5, both with SymDS 3.7.32). The issue is that every time a change is made in the client after the data is sent by SymDS to the server, the SymDS server sends the data back to the client (sometimes causing problems with key violations, etc). The value of ping_back_enabled is 0 everywhere, so that's not the cause, but I noticed that on the server, the value source_node_id is always null in...

Hi, I'm having trouble with an installation (Firebird 3.0 on the SymDS server, just one client, with Firebird 2.5, both with SymDS 3.7.32). The issue is that every time a change is made in the client after the data is sent by SymDS to the server, the SymDS server sends the data back to the client (sometimes causing problems with key violations, etc). The value of ping_back_enabled is 0 everywhere, so that's not the cause, but I noticed that on the server, the value source_node_id is always null in...

Hi, I'm having trouble with an installation (Firebird 3.0 on the SymDS server, just one client, with Firebird 2.5, both with SymDS 3.7.32). The issue is that every time a change is made in the client after the data is sent by SymDS to the server, the SymDS server sends the data back to the client (sometimes causing problems with key violations, etc). The value of ping_back_enabled is 0 everywhere, so that's not the cause, but I noticed that on the server, the value source_node_id is always null in...

Ok, thanks for your comment. I'll try upgrading to the latest version to see what happens.

Is that so? The user guide for v3.7.19 says in 4.6: ---8<--- Initial Load Order Order sequence of this table when an initial load is sent to a node. If this value is the same for multiple tables, then SymmetricDS will attempt to order the tables according to FK constraints. If this value is set to a negative number, then the table will be excluded from an initial load. ---8<--- That's why I expected the initial load would just work... What would SymDS do in case of referential cycles?

*conflictive master table If I do that (set initial_load_order) what happens with other tables that that table references or is referenced by? I would need set the load order for them too, no?

Excuse me for the delay, I've been out of office. You mean out of the replication? That is not the problem, both are fully replicated (all columns) and update without problems, except that the foreign key order is not respected. I didn't know about init_load_order! This column is currently zero for every row in sym_trigger_router. Is that OK? We would need to first update all the some value greater than zero (lets say 10) and the set it to a lower value for the conflictive slave table, isn't it?

Excuse me for the delay, I've been out of office. We are using v 3.7.19 Both tables are set for replication. Both update properly when changes are made in any of them... until at some point replication halts due foreign key violations. Then we add manually the missing record in the master table at the node with problems and replication resumes until the next time...