Change Log
7/9/2018
•We changed the sample environment to place SQL Server into "auto-commit" mode at all times except when executing the old-style table load mechanism (pre bulk load). By doing so we can avoid having to explicitly execute start transaction / end transaction statements, each of which is a network operation in client / server environments. If you wish to revert to the previous behavior then you can use the new replicator command line option -autocommit NO or alternatively set the environment variable REPLICATOR_AUTO_COMMIT=NO.
5/31/2018
•We addressed an issue when a bulk load operation was taking more than 60 seconds to process the BUILK INSERT statement. There was a default 60 second timeout on the execution of the SQL statement, which is inappropriate for large BULK INSERT operations. We suppressed the timeout for such operations.
•We enhanced the replicator_menu program by adding some basic support for replicator instance names. We also added an option to view running replicator processes on Linux systems.
•We made several enhancements to the Linux replicator management scripts.
5/17/2018
•We changed XCALL REPLICATE so that it adds shutdown requests to the beginning of the instruction queue instead of the end. This will mean that shutdown requests will be actioned as soon as possible, i.e. as soon as the replicator has completed its current task. Previously a shutdown request would bot be processed until all currently queued tasks had been completed.
•We fixed the Load and Bulk Load operations for multi-record-format (tagged) structures. These were inadvertently broken when we switched from the custom IO routines to regular IO statements.
2/22/2018
•We changed the bulk load mechanism to now use a new feature in FileService called "chunked upload". This mechanism breaks down the upload of large files into multiple synchronous operations, in turn reducing the memory requirements and making is possible to upload very large files.
•The REPLICATOR_REMOTE_EXPORT environment variable has been removed and replaced with two new environment variables REPLICATOR_FILESERVICE_HOST and REPLICATOR_FILESERVICE_PORT.
2/15/2018
•We have removed the previous bulk load mechanism that used xfServer to upload data to the database server for subsequent BULK INSERT and have replaced it with a better and more flexible solution. The environment now includes a Synergy .NET project named FileService which is the code for a Windows Service that can be installed on the Windows database server host. The Windows service in turn hosts a Web API 2 RESTful web service that allows the delimited data files that are used during bulk load operations to be uploaded to the server via an HTTP post. This capability can be supported from any Synergy environment, including OpenVMS systems. The bilk load code that replicator uses has been updated to use this new HTTP mechanism instead of using xfServer on the database server system. If you wish to use this new bulk load mechanism then you must have a Synergy runtime (RUN10) license available on the database server system, in addition to the SQL Connection API (SCSQ10) license that is also required.
1/19/2018
•We introduced a mechanism for relative files to be replicated in addition to ISAM files. The code generated for relative files will include a "RowNumber" column that is populated with the associated record number from the underlying relative file. This row number is then used to synchronize the data in the file and table.
1/19/2018
•We introduced a new "bulk load" mechanism which in some circumstances can substantially reduce the time taken to load initial data into a table. The mechanism exports the data to a delimited file in the Synergy environment, then uses xfServer to copy the file to the database server where it is subsequently processed with a BULK INSERT statement. The sample EMPLOYEE file (which has 25,000 records) loads 20x faster using the new mechanism in my test environment (2 seconds vs 20 seconds). This mechanism requires an instance of xfServer to be running on the SQL Server system, and so can't be used when replicator is running on OpenVMS. This capability is intended to be a temporary solution for use on Windows and UNIX / Linux until a better and more generic solution can be developed.