Harmony Core Office Hours, December 2019December 17, 2019
Harmony Core Office Hours, January 2020January 23, 2020
In recent weeks we have been working on making improvements to our SQL Replication environment, which demonstrates how to easily replicate your Synergy data to a SQL Server database. Some of these changes were undertaken in collaboration with a customer that uses the environment extensively, and we thank them for their input and support. Other changes have been on our road-map for some time and we think you’ll be excited about what has been achieved. Here’s a summary of the changes:
- Synergy 11 introduced a new SQL Connection API capability which calls the ODBC API function SQLDescribeParam behind the scenes to improve performance and avoid excessive cache memory thrashing for SQL statements that have I/O parameters when accessing SQL Server (VTX12_SQLNATIVE). Synergex recommend setting SSQL_PERFORMANCE_SQL to yes (or setting the SQLPERFORMANCESQL environment variable. We have updated the environment to do this, which should result in improved performance when running in Synergy 11 or higher environments.
- We have added the ability to run multiple instances of the replicator process side-by-side, within a single data set, and to divide up the replication of different files between these multiple replicator instances. Each instance is assigned a unique instance name and has its own associated instruction queue file, the name of which includes the instance name, as does the log file produced by each instance. In a multi-instance environment developers can chose on a file-by-file bases which data files are replicated via which queue file, and therefor via which replicator instance. It is important to understand that in this scenario there is no synchronization of the sequence in which changes are applied to the underlying SQL database between the multiple instances of the replicator.
- We have added the ability to exclude certain fields in a record from being appearing in and being replicated to the associated SQL Server database table. It is important that fields associated with keys not be excluded, unless those keys are also excluded (see the next item). Generally the fewer fields/columns that are replicated the faster the replication will be.
- We have added the ability to exclude certain keys from processing, so that matching database indexes will not be created in the associated database tables. Generally the fewer indexes that exist on a table the faster the replication will be.
- We have added the ability for the replicator to detect some kinds of database failure, caused by network errors, or the database being shut down or otherwise unavailable, and allow it to gracefully disconnect, and then attempt to reconnect, with a configurable number of retries and retry interval. This should make the replicator processes more robust.
- We have added the ability to change the database datatypes of fields. The main use case envisaged is transforming decimal fields into implied decimal fields (adding decimal places in the database data), but there may be other use cases, such as transforming Y/N fields into Boolean true/false fields, etc.
- We have also corrected an issue that could occur if replicator encountered an unexpected error and was configured to use BATCH COMMIT mode. Is some circumstances, if there were uncommitted changes at the time on an error any uncommitted changes could be lost because the change records were deleted from the instruction queue one by one before the batch was committed. Now any instructions related to uncommitted changes remain in the queue file until the batch is committed, and are then all deleted. When the replicator is restarted it will then attempt to reply the changes to the database again. This should help prevent the database getting out of sync if there is a replicator failure.
We’re excited about these new features in our SQL Replication offering and looking forward to hearing your feedback. By the way, many of these new features rely on using the latest and greatest version of CodeGen (5.4.8) which was also released today. If you’re already using an earlier version of the SQL Replication environment, or if you are interested in getting started and would like some assistance, don’t hesitate to contact us through your Synergex Account Representative.