NaN value is a valid value for PostgreSQL, but that is not a valid value for SQL Server. You will have to configure a transform to change the value NaN to a null value to be saved on the SQL Server side.
You will have to make sure that the trigger definition for the employees table has Use Capture Old Data set to 1. This will make sure that the location column is in the old data section of sym_data, and will be able to be used to route to the correct node.
The functionality of log mining for MySQL only exists in the SymmetricDS Pro version. When using the user interface, and deploying the nodes, on the endpoint summary screen you can change the deployment type from trigger based to log mining based. Here is a link to the endpoint summary screen: https://downloads.jumpmind.com/symmetricds/doc/3.16/html/user-guide.html#_endpoint_overview
Trggers will be created on the application tables when you have configured sym_trigger records for each application table that you want synchronization to occur for. You will also have to configure sym_trigger_router to associate each sym_trigger entry with a router from sym_router. Here is a link to the documentation: https://symmetricds.sourceforge.net/doc/3.16/html/user-guide.html Here is a link too a quick start tutorial: https://symmetricds.sourceforge.net/doc/3.16/html/tutorials.html
If you upgrade to 3.16.3 (the latest 3.16), you will acquire years of improvements in security, bugs, and performance. You will also be able to take a support snapshot that you can attach to this entry. A support snapshot is taken as follows: symadmin take-snapshot Or you can post a zip of the symmetric log files located in the logs directory.
Here is a link to the documentation that describes how to upgrade: https://symmetricds.sourceforge.net/doc/3.16/html/user-guide.html#_upgrading The upgrade will not lose any pending changes, and will send them. We have not experienced changes going out of order when a network outage occurs. Are you using multiple channels for the tables that are synchronized? If you are, then one channel may be in failure and not able to proceed with synching, but other channels will be able to sync just fine.
We opened an issue to use the CREATE OR REPLACE triggers construct so that we can avoid the drop. We will be supporting this construct on Postgres 14 and later. The issue is locate here: https://issues.symmetricds.org/view.php?id=6990
It looks like the delivery of the SQL event from the source to the target does not execute the Sync Triggers functionality on the target node. We will add this feature to our issue tracker. https://issues.symmetricds.org/view.php?id=6752