By Steve Ives, Posted on January 29, 2020 at 6:23 pm
Important quality improvements for REV11 licensing
A new patch release for Windows and Unix is now available to download on the Synergex website. All customers are encouraged to update to 11.1.1c for important quality improvements.
This update includes new versions of the following products:
Synergy/DE (32- and 64-bit)
REV11 licensing upgrade package (32- and 64-bit, delivered in one installer on Windows)
Synergy DBL Integration for Visual Studio
11.1.1c includes quality improvements for the following issues:
IMPORTANT: Previously, in REV11 licensing environments, an expired license error could occur if a license allocated by a program expired while the program was running. Even if new keys had been delivered and installed, if the license server had not been restarted since the new keys were installed, the error could occur.
It is important that all customers using subscription licensing in a REV11 environment install the 11.1.1c patch (for version 11 systems) or apply the 11.1.1c version of the licensing upgrade package (for version 9 or 10 systems).
If for any reason you are not able to do so, you should ensure that your license server is restarted as soon as possible after your new subscription keys are delivered. Long-running processes are resilient to a license server restart.
In versions 11.1.1a and 11.1.1b, if an attempt to rename a remote file (via xfServer) resulted in an error being generated, in some cases xfServer could fail with a segmentation fault.
In versions 11.1.1 through 11.1.1b, using the isutl utility to re-index a large multi-key ISAM file with an index exceeding 4,294,967,295 bytes caused a corrupted index to be created.
In versions 11.1.1 through 11.1.1b, when running xfServer in Secure or Trusted mode, a client using the RUSER mechanism to provide login credentials to the server experienced a “Bad username, login rejected” error.
In versions 11.1.1 through 11.1.1b, in some circumstances when opening a remote file via xfServer when that server did not already have other files open, the xfServer process could fail.
The patch also includes the following enhancements to Synergy DBL Integration for Visual Studio:
We significantly enhanced the Visual Studio build system for Synergy .NET projects by improving the dependency-checking algorithms. Previously, any change in the code of, for example, a class library caused all projects that reference that library to be rebuilt. With these changes in place, dependent projects will only be rebuilt if changes in the dependency library result in the signatures of externally visible items being added, changed, or removed. This will result in a significant reduction in elapsed build times in many cases.
We improved the hover-over information (QuickInfo) displayed for type declarations for variables, fields, properties, etc. We added simple colorization and documentation comments (when available), and in some cases, type names are now fully qualified.
See the release notes for a complete list of 11.1.1c changes. See the Synergy/DE 11pagefor information about the latest Synergy/DE features.
By Steve Ives, Posted on January 24, 2020 at 4:32 pm
In Microsoft Visual Studio version 16.4 a new feature was, I was going to say introduced, but snuck in might be more appropriate way of describing things. There was no mention of the new feature in any release notes that we can find, and an internet search for the name of the new feature currently returns no useful matches!
The feature is called Adaptive Formatting and apparently what it does is allows code editor windows to “heuristically determine if the current file should use tabs or spaces for indentation”. Previously this behavior was determined by a language specific setting, and those settings are still present, but if Adaptive Formatting is enabled (which it is by default by the way), then it wins!
So if your code is indented with tabs, and suddenly Visual Studio decides to start using spaces instead (or vice-versa) then it’s probably Adaptive Formatting getting it wrong! Thankfully this new feature can be disabled by going into Tools > Options > Text Editor > Advanced and un-checking the Use adaptive formatting option.
Following the holidays, we didn’t have much time for major updates to Harmony Core since our last office hours. Our focus has been on the EF Core 3.1 provider, which is necessary for us to support ASP.NET Core 3.1. This is should be finished in the next few days, and this will probably resolve a few open issues on GitHub.
By Steve Ives, Posted on January 16, 2020 at 8:10 pm
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.