Prolaw and SQL Replication – Creating, Breaking, and Updating Prolaw

Monday, January 30th, 2012 | ProLaw Case Management, Uncategorized | Mike Smith

This guide will cover the various aspects of replication for a Prolaw SQL server.  If you have a replicated environment and are updating any aspects of Prolaw such as the custom tabs or updating Prolaw itself, you will need to stop replication first.  You may also refer to this guide if you need to set up a replicated environment.  This guide will focus on the SQL portion itself, assuming you already have the document shares replicated via DFS or other means. You may refer to other posts on this blog on how to set up test versions of Prolaw or how to install updates.


If you are working with any Prolaw updates, adjusting a replicated environment, or conducting any other related work it is always best practice to ensure all users are out of Prolaw so that there is no potential for lost work product.


Break existing replication:

If you have an existing replication, and are not making any changes to SQL, its enough to simply delete the subscriber and leave the Publisher configured as is.

Step 1:  Verify all Prolaw Agents or Exchange Integrations are stopped and all users are logged out of Prolaw.

Step 2: Verify databases are currently synchronized, and then stop them through the replication monitor in SQL.

Step 3:  Delete the subscription on the secondary server (the Subscriber).


If you are updating Prolaw:

If you are updating Prolaw in a replicated environment, there are a few more steps involved.  Its also going to vary for every firm depending upon related server and network settings.

Step 1:  Update the primary Prolaw server following the standard Prolaw update process (

Step 2: Archive the updated Prolaw install directory and the updated SQL database and copy to the Subscriber server.

Step 3: Restore over the current Subscriber’s Prolaw database with the updated database from the Publisher (see note).

Step 4: Overwrite the Prolaw application directory with the archive from the updated server, being sure to not overwrite prolaw.ini as this file contains the specific server settings for Prolaw

Note:  If you are not using DFS for documents, prolaw.dbo.prolawini will most likely be excluded from the replication/overwriting as that would contain the path to the document share and would be different in all locations.


If you are creating a fresh replication:

If you want to setup a new replicated Prolaw site, you can start here.  This assumes you have Prolaw installed and tested at the remote site.

Step 1:  Create a publication on the primary SQL server by right-clicking publications and selecting “New Publication.”

Step 2: For the new publication options, use the default options unless shown below:

- Set the server as the Distributor.

- change the default replication folder if needed; otherwise the default is okay.

- select the database you use for Prolaw.

- select “Merge Publication.”

- use functionality level of the lowest member (preferring that they are all the same version).

- select all tables excluding as needed (see note).

- provide a user account for the Spanshot Agent and Publisher.

Note:  If you are not using DFS for documents, prolaw.dbo.prolawini will most likely be excluded from the replication as that would contain the path to the document share and would be different in both locations.


Create the new subscription:

Once Prolaw has been updated or you have created a new Publication, in order to restore the synchronization, the final step is to (re)create the Subscriber.

Step 1: Create the new subscription on the Publisher ensuring the Prolaw database is available.

- select run all agents at the Distributor.

- add the SQL server subscriber and select the correct remote database.

- use a domain administrator account for the Merge Agent.

- select continuously or a schedule for the synchronization to happen.

- Initialize immediately, using the defaults for the rest and creating the subscription.  The initial verification could take hours depending on your connection to the other SQL server.

Step 2: Verify and test the synchronization in the SQL monitor.


Any time you make any changes of this magnitude to SQL, Prolaw, or a replicated system, the most important step is to ensure your programs are acting as they should and data is being replicated correctly before users start to work.

Tags: , , ,

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Page 1 of 11

Leave a Reply