Stelo Technical Documents

Upgrade Considerations for SQDR v6 & later

Last Update: 9 March 2023
Product: StarQuest Data Replicator
Version: v6.12 and later
Article ID: SQV00DR046


SQDR 6.1x is a major release. This document describes in detail some of the differences between SQDR 6.1x and earlier versions of SQDR. See the SQDR Release Notes for the latest information.


  • SQDR is now 64-bit only.
  • SQDR is now available for Linux. See the chapters SQDR on Linux and Linux: ODBC Drivers in SQDR 6.x Help.
  • Db2 LUW 11.5.5 or SQL Server 2016 & later are now recommended for the control database. If you are currently using SQDR with an earlier version of Db2 or SQL Server, you may be able to continue to use the earlier version, but we recommend updating at your earliest convenience.
  • A number of deprecrated files have been removed from the installer.
  • The Windows Installer for SQDR 6.x is a major upgrade - i.e. a comprehensive update of a product that involves a change of the ProductCode Property. The previous version of the product will be removed and then installed. During the Uninstall phase of the major update, answer No to the dialog asking if you would like to remove control tables and registry entries.
  • Support for new Apply option “Merge” for use with supported relational DBMS destinations, such as SQL Server, Snowflake, and PostgreSQL (v15). This results in improved performance in many cases..
  • Role Based Access Control & Auditing
  • Powershell scripting


gRPC replaces COM

SQDR v5.x was restricted to Microsoft Windows as it used COM for communication between the Data Replicator Manager and the service. SQDR v6.x now uses the gRPC (Google Remote Procedure Call) framework, enabling the use of Linux.

The replacement of COM with gRPC communications has the following ramifications:

  • Programmatic access using COM (VBScript, PowerShell, Visual Basic, and C#) has been replaced with PowerShell cmdlets. See Automating SQDR tasks using PowerShell for details.
  • VBScripts scripts supplied with the installer (e.g. TargetChecker, PauseResumeIRGroup, etc) have been rewritten to use PowerShell instead COM.
  • Additional PowerShell scripts are now included.
  • Data Replicator Manager v6.x must be used when connecting to an SQDR service running v6.x. Similarly, use Data Replicator Manager v5.10 or later when connecting to an SQDR service running 5.1x or 5.2x.
  • Requirements for remote management have changed. See the topic Add or Remove Server in the Help file for details.
  • Data Replication Manager no longer requests elevation when it is invoked, as most operations do not require administrative rights to the computer.
  • In SQDR v5, connecting with Data Replicator Manager or a COM-based application would automatically start the SQDR service if it was not running. This is no longer the case; either ensure that the service is running before starting Data Replication Manager, or run Data Replication Manager or PowerShell cmdlets as elevated (Run as Administrator); See Starting & Stopping the SQDR Service below for additional information.

SQDR Streaming Support

A major new feature is the ability to send baseline and change data as Kafka messages to user-written consumers or to Azure Databricks without the need to install additional software or configure stored procedures. See Using SQDR Streaming Support and Using SQDR Streaming Support with Azure Databricks.

The Stelo Data Link Sink Connector for Azure Databricks provides an alternative to using Kafka messages when sending data to Databricks.

Starting & Stopping the SQDR Service (SQDRSVC)

If you wish to start and stop the service from within the Manager application, or have the invocation of the Manager automatically start the service if it is not running, then start the Manager as elevated by right-clicking on its icon and selecting Run as Administrator. In addition, your userID must have authority to start and stop services - i.e. it should be be in either the local Administrators group or be a domain admin.

The above paragraph refers to local usage (where Manager is running on the same machine as the service).

In the case of remote access, it is not necessary to run the Manager as elevated to stop the service from within Manager; it is sufficient for the user to be a domain user that is a member of the local Administrators group of the remote system.

To start the service remotely, use the Windows command sc or the PowerShell start-service cmdlet. You may also need to edit the Windows firewall of the remote system to enable the three pre-defined rules for Remote Service Management (NP-In, RPC, and RPC-EPMAP).


The Default listeners are configured as follows:

  • persistent connections - listening on all interfaces, port 7737
  • non-persistent connections - listening on localhost only, port 7738

To allow Manager, PowerShell, and SQDR Service Properties access from a remote system, use SQDR Service Properties (locally) to change the value of grcpTransADDRPORT (the listener for non-persistent connections) from 127.0.01:7738 to and then restart the SQDR service.

If you want to restrict remote access to certain users, configure the Windows firewall to allow connections to port 7738 only from certain IP addresses

Reverting to SQDR v5

The format of the control database has changed from 5.2x so there is no easy way to revert to SQDR v5. We recommend creating a backup of the control database before updating to SQDR v6. If it is necessary to return to SQDR v5, uninstall SQDR v6, confirm that all files have been removed, reboot, install SQDR v5, restore the control database from the backup, and run SQDR Configuration. Note that any configuration or status changes that occurred after updating to v6 will be lost; you will likely need to run new baselines of all subscriptions.




The information in technical documents comes without any warranty or applicability for a specific purpose. The author(s) or distributor(s) will not accept responsibility for any damage incurred directly or indirectly through use of the information contained in these documents. The instructions may need to be modified to be appropriate for the hardware and software that has been installed and configured within a particular organization.  The information in technical documents should be considered only as an example and may include information from various sources, including IBM, Microsoft, and other organizations.