Data, Development Tips, How To, Information, Instalation & Configuration, Replication, SQL, Tip & Tricks

Database Replication – Part V

This post is in continuation to my earlier post. Please check if you missed.

Database Replication – Part I

Database Replication – Part II

Database Replication – Part III

Database Replication – Part IV

As committed in this post we will continue to cover practical approach, Next step from last post.

We will create a subscription using SQL Server Management Studio

To create the subscription

  • Connect to the Publisher in SQL Server Management Studio, expand the server node, and then expand the Replication folder.
  • In the Local Publications folder, right-click the Nav2018ItemTrans publication, and then click New Subscriptions.


The New Subscription Wizard launches.


  • On the Publication page, select Nav2018ItemTrans, and then click Next.


  • On the Distribution Agent Location page, select Run all agents at the Distributor, and then click Next.


  • On the Subscribers page, if the name of the Subscriber instance is not displayed, click Add Subscriber, click Add SQL Server Subscriber, enter the Subscriber instance name in the Connect to Server dialog box, and then click Connect.
  • On the Subscribers page, select the instance name of the Subscriber server, and select under Subscription Database.
  • On the New Database dialog box/Select from Drop Down List, enter Nav2018ReplDatabase in the Database name box, click OK, and then click Next.


  • In the Distribution Agent Security dialog box, click the ellipsis (…) button, enter <Machine_Name>\repl_distribution in the Process account box, enter the password for this account, click OK.


  • Click Next.



  • Click Finish to accept the default values on the remaining pages and complete the wizard.

Setting database permissions at the Subscriber

  • Connect to the Subscriber in SQL Server Management Studio, expand Databases, Nav2018ReplDatabase, and Security, right-click Users, and then select New User.
  • On the General page, in the User type list, select Windows user.
  • Select the User name box and click the ellipsis (…) button, in the Enter the object name to select box type <Machine_Name>\repl_distribution, click Check Names, and then click OK.


  • On the Membership page, in Database role membership area, select db_owner, and then click OK to create the user.


When setting up SQL Server replication you might see an error message from the Transactional Replication Log Reader Agent which reads like the following.

Error messages:

  • The process could not execute ‘sp_replcmds’ on ”. (Source: MSSQL_REPL, Error number: MSSQL_REPL20011) Get help: http://help/MSSQL_REPL20011
  • Cannot execute as the database principal because the principal “dbo” does not exist, this type of principal cannot be impersonated, or you do not have permission. (Source: MSSQLServer, Error number: 15517) Get help: http://help/15517
  • The process could not execute ‘sp_replcmds’ on ”. (Source: MSSQL_REPL, Error number: MSSQL_REPL22037) Get help: http://help/MSSQL_REPL22037

Often this error message can come from the database not having a valid owner, or the SQL Server is not being able to correctly identify the owner of the database.

Often this is easiest to fix by changing the database owner by using the sp_changedbowner system stored procedure as shown below. The sa account is a reliable account to use to change the ownership of the database to.

USE PublishedDatabase


EXEC sp_changedbowner ‘sa’


Once the database ownership has been changed the log reader will probably start working right away. If it doesn’t quickly restarting the log reader should resolve the problem.

While this does require changes to the production database, there is no outage required to make these changes.

To view the synchronization status of the subscription

  • Connect to the Publisher in SQL Server Management Studio, expand the server node, and then expand the Replication folder.
  • In the Local Publications folder, expand the Nav2018ItemTrans publication, right-click the subscription in the Nav2018ReplDatabase database, and then click View Synchronization Status.


The current synchronization status of the subscription is displayed.


  • If the subscription is not visible under Nav2018ItemTrans, press F5 to refresh the list.

Validating the Subscription and Measuring Latency

We will use tracer tokens to verify that changes are being replicated to the Subscriber and to determine latency, the time it takes for a change made at the Publisher to appear to the Subscriber.

To insert a tracer token and view information on the token

  • Connect to the Publisher in SQL Server Management Studio, expand the server node, right-click the Replication folder, and then click Launch Replication Monitor.
  • Replication Monitor launches.
  • Expand a Publisher group in the left pane, expand the Publisher instance, and then click the Nav2018ItemTrans publication.
  • Click the Tracer Tokens tab.
  • Click Insert Tracer.
  • View elapsed time for the tracer token in the following columns: Publisher to Distributor, Distributor to Subscriber, Total Latency. A value of Pending indicates that the token has not reached a given point.


This way we are done with Database Replication Setup.

Will come up with more topic soon.


Development Tips

Schema Synchronization in Microsoft Dynamics Navision 2015

NAV 2015 provides you with flexibility of deciding when and how your table changes should be synchronized with corresponding SQL tables.

What is table synchronization?


NAV 2013 R2:- Schema synchronization executes automatically on any connection to the Server.

NAV 2015:- Schema synchronization executes on demand by the Server.

Way the Synchronization works:

  1. Per Table Synchronization
  2. Synchronizing schema changes for all tables


Now let us see how it works:


Add/Modify/Delete Fields (change table definition) we will be prompted for Synchronizing the Schema.

It gives three options description is self-explanatory.

Some time we have to do major changes to the tables which takes lots of time to sync, we can postpone the sync process by selecting Later. Once we are done with all of our changes we can go with synchronization in one go.


We get same options.

New option Check Only….


This option will only report outcome and will not Sync the Schema.

Since we have just added new field so no risk as reported by above check.

Now I will delete one field from the table and let’s see what result comes.


Summary of the 3 options as below:


When data loss is reported while changes in table definition is referred as destructive changes.


You use upgrade codeunits when you make changes to a table definition, either from the Microsoft Dynamics NAV Development Environment or during an upgrade. Upgrade codeunits migrate existing business data from the old table structure into the new table structure. An upgrade codeunit serves the following purposes:

  • Provides instructions for how to handle data changes to a table during schema synchronization.
  • Provides the logic for migrating existing data in the business data table from the old format to the new format after schema synchronization.

A typical example of when to use an upgrade codeunit is when you remove a field from a table definition and you do not want to lose the existing data in the business data table. Instead, you want to use it somewhere else in the new application.

You implement upgrade codeunits when you make destructive changes to tables in Microsoft Dynamics NAV Development Environment. After you have created an upgrade codeunit to handle table changes, you can use it when you upgrade data from an earlier version of Microsoft Dynamics NAV to the current version. A single upgrade codeunit will typically contain table schema synchronization instructions and data migration logic for multiple tables that have changed from one version of Microsoft Dynamics NAV to another.


I will come back on this topic in another post with more details.

And many more options like PowerShell Sync with above options.


Perform on demand – transparency -> As developer and system administrator, you are in control when to call the schema synchronization and how to synchronize table changes. You can invoke it, plan for it and schedule for it on a case by case basis. You can also monitor its progress and monitor the state of your database (tenant).

Not blocking other changes – productivity -> Schema Synchronization has become more granular. It can be performed per table object as well as for all table changes at once. When one table is being synchronized you are no longer blocked, and you can continue making changes to other tables.

Opened for additional instructions – flexibility -> Using upgrade codeunits you can provide input for the schema synchronization to do extra tasks, like automatically moving or copying data into upgrade tables, checking the changes or forcefully applying them where necessary. (Will come up with more details on this in my next post)