NCR Counterpoint Course 309 Multi-Site for Counterpoint Multi-Site Training Manual Multi-Site for Counterpoint Version 8.4 Agenda General Information Table of Contents For Your Information:

NCR Integrated Stall Solution 1

©NCR Corporation 2012

NCR Counterpoint

Course 309 Multi-Site for Counterpoint

Multi-Site Training Manual

For Your Information...

Here is some logistical information to help you find your way around the training

facilities:

RESTROOMS Restrooms are located outside the Training Room on the left. The

Women’s restroom is immediately to the left and the Men’s restroom is

further down the hallway.

BADGES All trainees are required to wear a VISITOR badge during their time in the

facility. You will need to scan the badge to obtain access to the Training

Room. Please return the badge to the instructor at the conclusion of your

training.

PHONES A telephone is available in the Training Room. Press 9 to get an outside

line. Please turn off your cell phone while in class.

WIRELESS The GUEST wireless network provides trainees with access to the

ACCESS Internet.

SMOKING This is a smoke-free building. A smoking area is provided in a patio area

outside the back door of the building. Please use the ashtrays provided.

REFRIGERATOR Help yourself to the drinks in the refrigerator in the Training Room. A

filtered water dispenser is also available in the room. You can also use the

refrigerator to store food items that you may have.

LUNCH The instructor will stop class for approximately one hour to allow

participants to enjoy their lunch. There are several restaurants within

walking distance of the Memphis training facility.

OFFICES We are proud of our offices but request that you have an escort to visit

areas outside of the Training Room.

APPOINTMENTS All of our employees schedule their time each day, so you will generally

need an appointment to see them. If you need to speak with your Sales

Rep or a Support Rep, please notify the Training Coordinator or Training

Instructor so that an appointment can be scheduled.


Copyright 1995 – 2015 by NCR Corporation

PROPRIETARY RIGHTS NOTICE: All rights reserved. No part of this material may be

reproduced or transmitted in any form or by any means, electronic, mechanical, or otherwise,

without permission in writing from NCR Corporation.

SYNCHRONICS and the Synchronics designs are registered trademarks of NCR Corporation,

Inc., Memphis, TN.

Other products mentioned are trademarks of their respective manufacturers.

REV: 030915


Multi-Site for Counterpoint

Version 8.4

Agenda

General Information

Table of Contents For Your Information: Overview of class format and training materials

Section 1. Overview

How does Multi-Site get deployed? What is the DataXtend Replication Engine (DXRE)? Discussion of the Counterpoint environment for Multi-Site configurations, and how licensing and registration of the products are handled.

Section 2. Deploying Multi-Site and Counterpoint How to prepare the Hub and Remote servers for the installation of Multi-Site and

Counterpoint. Install Counterpoint and the Counterpoint service pack on the Hub server and each Remote server.

Section 3. Other Deployment Activities Using the Multi-Site utilities to perform functions independently of the CPSQL

Installation, such as: install Counterpoint service packs; update to a new Counterpoint version; update your Counterpoint registration or DXRE registration; convert from a standalone or WAN server to a Multi-Site Hub server; apply new schema scripts or replication rules to a replicating database; add a store or location.

Section 4. DXRE Concepts How replication rules are designed and determine what data can be replicated

from site to site. Subscribing each site to a set of data and scheduling replication. How a database is activated for replication, and how changes in the database are tracked. Ways to start replication, and how the replication process works.

Section 5. DXRE Troubleshooting How to monitor replication and read replication logs. Troubleshooting tools that

you will use. How to identify, resolve, and prevent replication errors.


Table of Contents

Section 6. Appendixes

DataXtend System Tables, Replication Engine Utilities, dsetting Utility, Avoiding Replication Errors, Customizing Counterpoint, Changing the CPServices Port

Section 7. Glossary

Terms used in DXRE Exercise Handbook Exercises that illustrate deployment of Multi-Site and DXRE concepts

presented in class

Multi-Site Training Manual Overview

SECTION 1: OVERVIEW

How are Multi-Site and DXRE Deployed? ..................................................1 Example Multi-Site Configuration ...............................................................2 How Multi-Site Works .................................................................................3 Hardware and Software Requirements ......................................................4 Licensing and Registration .........................................................................6 Exercise 1: Configuring the Systems .........................................................8

Multi-Site Training Manual Overview

Multi-Site Training Manual 1-1 Overview

Overview of Multi-Site

Deploying Multi-Site Done via standard installation of Counterpoint Prerequisites and

Counterpoint

Prerequisites install (on MS systems only)

DataXtend Replication Engine (DXRE)

DataXtend registration file

Counterpoint install Counterpoint registration file

Counterpoint

Database schema customizations

Activates database for replication

Distributes custom reports & forms (via FileSync)

DXRE DataXtend Replication Engine (currently V8.2) Synchronizes data changes between multiple

Counterpoint databases Bi-directional across TCP/IP networks Additional Components Administrator Schedule replication sessions and

subscribe sites to data "work sets" (or use Radiant Multi-Site

Configuration Editor) Controller Monitor and manage replication

sessions, licenses, and site availability Designer Define custom replication rules Part of the DataXtend Studio Site Monitor Display information about replication

network partners and sessions Command line utilities Perform administrative and configuration

tasks from a command prompt

Mu

lti-

Sit

e T

rain

ing

Manual

1-2

O

ver

vie

w

Ex

am

ple

Mu

lti-

Sit

e C

on

fig

ura

tio

n

Hig

h-s

pee

d c

onnec

tio

n

Hu

b S

erver

• M

S H

ub

• C

ou

nte

rpo

int

pro

gra

ms

& f

ull

dat

a

• O

pti

ons:

MS

& H

ub

(opti

onal)

Off

line

Tic

ket

Entr

y

• M

SS

QL

(F

ull

)

• D

XR

E

Rem

ote

Serv

er 1

• C

ounte

rpo

int

pro

gra

ms

&

(par

tial)

dat

a

• O

pti

ons:

MS

(opti

onal)

Off

line

Tic

ket

Entr

y

• M

SS

QL

• D

XR

E

Rem

ote

Serv

er 2

• C

ounte

rpo

int

pro

gra

ms

&

(par

tial)

dat

a

• O

pti

ons:

MS

(

opti

onal)

Off

line

Tic

ket

Entr

y

• M

SS

QL

• D

XR

E

Work

sta

tion

1 -

Off

lin

e

• C

oun

terp

oin

t pro

gra

ms

& (

par

tial

) d

ata

• C

PS

ervic

es

• M

SS

QL

Work

sta

tion

2

• C

oun

terp

oin

t pro

gra

ms

Work

sta

tion

1

• C

ou

nte

rpoin

t pro

gra

ms

Work

sta

tion

1

• C

oun

terp

oin

t pro

gra

ms

Work

sta

tion

2 -

Off

lin

e

• C

oun

terp

oin

t pro

gra

ms

& (

par

tial

) dat

a

• C

PS

ervic

es

• M

SS

QL

Work

sta

tion

2 -

Off

lin

e

• C

oun

terp

oin

t pro

gra

ms

& d

ata

(par

tial)

• C

PS

ervic

es

• M

SS

QL

Work

sta

tion

3 -

Off

lin

e

• C

ou

nte

rpoin

t pro

gra

ms

& d

ata

(p

arti

al)

• C

PS

ervic

es

• M

SS

QL


How Multi-Site Works

Data is replicated between the Hub and Remote servers

Bi-directional process between the two databases involved in each replication session

Example:

Customer records

Price changes

New customer records entered at a Remote site are replicated to the Hub

Price changes entered at the Hub are replicated to the Remote server


Hardware and Software Requirements

Hub Server

Function

Primary Counterpoint server (Hub server in

MS environment)

Required for Multi-Site

Counterpoint Options:

Multi-Site

Hub

Offline Ticket Entry optional

plus others, as desired


Windows XP Pro with SP3*

Windows Server 2003 with SP1 (32-bit only)

Windows Server 2008 (32-bit or 64-bit)

Windows 7 (32-bit or 64-bit)

2 GHz Pentium 4 or better

2 GB memory

MSSQL 2008 or MSSQL 2005 with SP2

(Standard, Enterprise, or Workgroup Edition),

configured for SQL Server Authentication

Named Pipes and TCP/IP with static IP/ network

address or DNS-resolvable host name

Disable Shared Memory protocol

Internet connection

Clock synchronization software

.NET Framework 1.1 (installed with DXRE)

Open port 242

If missing, installed by CPSQLPrereqs.exe Microsoft .NET Framework 3.5 SP1**

Microsoft .NET Framework 4.0

SQL Server Native Client

SQL Server Management Objects

SQL XML 4

SQL Server 2008 Shared Management Objects

SQL Server 2008 System CLR Types

SQL Server 2008 R2 Express‡ (optional; only if

default instance of MSSQL is not installed)

DataXtend Replication Engine (DXRE) 8.2

* For XP Pro, if network is configured as a workgroup

(rather than as a domain), enable Windows networking

and disable Simple File Sharing.

** On Windows Server 2008, before installing

CPSQLPrereqs.exe, use Start|Administrative Tools|Server

Manager to install .NET Framework 3.5 SP1.

‡ On 32-bit operating systems, before installing SSE,

use Add or Remove Programs to remove Microsoft SQL

Server Native Client

If missing, installed by CPSQLPrereqs.exe

On 32-bit server, run from CPSQL

Installation menu.

On 64-bit server, browse CP download and

copy CPSQLPrereqs directory to the

server’s local drive.



Remote Server

Function

Counterpoint server at remote location (MS

environment)

Can also be used a workstation

Counterpoint Options:

Multi-Site

Offline Ticket Entry optional


Windows XP Pro with SP3*

Windows Server 2003 with SP1 (32-bit only)

Windows Server 2008 (32-bit or 64-bit)

Windows 7 (32-bit or 64-bit)

2 GHz Pentium 4 or better

2 GB memory

MSSQL 2008 or MSSQL 2005 with SP2

(Standard, Enterprise, or Workgroup Edition),

or SSE 2008/2005, configured for SQL Server

Authentication

Named Pipes and TCP/IP with static IP/

network address or DNS-resolvable host name

Disable Shared Memory protocol

Internet connection

Clock synchronization software

.NET Framework 1.1 (installed with DXRE)

Open port 242

If missing, installed by CPSQLPrereqs.exe Microsoft .NET Framework 3.5 SP1**

Microsoft .NET Framework 4.0

SQL Native Client

SQL Server Management Objects

SQL XML 4

SQL Server 2008 Shared Management Objects

SQL Server 2008 System CLR Types

SQL Server 2005 Express‡ (optional; only if

default instance of MSSQL 2005 not installed)

DataXtend Replication Engine (DXRE) 8.2

* For XP Pro, if network is configured as a workgroup

(rather than as a domain), enable Windows networking

and disable Simple File Sharing.

** On Windows Server 2008, before installing

CPSQLPrereqs.exe, use Start|Administrative Tools|Server

Manager to install .NET Framework 3.5 SP1.

‡ On 32-bit operating systems, before installing SSE,

use Add or Remove Programs to remove Microsoft SQL

Server Native Client

If missing, installed by CPSQLPrereqs.exe

On 32-bit server, run from CPSQL

Installation menu.

On 64-bit server, browse DVD and copy

CPSQLPrereqs directory from the DVD to

the server’s local drive.


Licensing and Registration

Initially installed with trial or temporary licenses DataXtend Replication Engine (DXRE) 30 days (PD30DayLicense.PNL)

Auto-installed when DXRE is installed DataXtend Studio N/A

No temporary license available After receiving permanent Counterpoint registration file, generate and install permanent licenses for DXRE and DataXtend Studio. To create permanent licenses, start Counterpoint at the Hub server. Select Setup / System / Registration. If Code type is "Permanent", click . Counterpoint must be permanently registered in order to generate a permanent license for DXRE. (Code type can be "Permanent" or "Temporary" to generate a permanent Studio license.)


DataXtend Licenses

DXRE License

PDLicense.PNL

30-day license automatically installed when DXRE is installed

Click in Setup / System / Registration on Hub Server to generate permanent DXRE license if Counterpoint Code type is "Permanent"

Generates license file in C:\Program Files\Radiant Systems\CounterPoint\CPSQL.1\Scripts

To install permanent DXRE license, on Hub Server, start DataXtend Controller and select Actions | Available databases | Add Network License from the menu bar

Studio License

Create permanent Studio license (no temporary license) on Hub Server using Setup / System / Registration if Counterpoint Code type is "Temporary" or "Permanent"

Creates license file in C:\Program Files\Radiant Systems\CounterPoint\CPSQL.1\Scripts

Use when installing DataXtend Studio (in order to modify replication rules to incorporate database customizations)

Can only be installed on one system in a network

PDLFXR.PDL


Exercise 1: Configuring the Systems

Try it Yourself!

In class, you are a member of a team that includes up to four students. Each

team has been provided three computers. During the first day of class, you will:

install Counterpoint on the Hub and Remote servers

enable replication across the systems

subscribe each server to the appropriate data work sets

set up schedules for replication In the first exercise, you will pre-configure the servers. Perform Exercise 1 in the Multi-Site Exercise Handbook. You'll be ready to begin Section 2 in this training manual when finished.

Multi-Site Training Manual Multi-Site Deployment

SECTION 2: DEPLOYING MULTI-SITE AND COUNTERPOINT

CUSTOM Folder on Servers.......................................................................1 Attach Pre-configured Database on Hub Server.........................................2 Exercise 2: Preparing to Install Counterpoint .............................................3 Install Counterpoint on Hub Server .............................................................4 Updating From a Previous Multi-Site Version .............................................5 CP Install Logs on Multi-Site Server ...........................................................6 Exercise 3: Deploying Counterpoint on Hub ..............................................7 CPServices Indicators ................................................................................9 Exercise 4: Deploying Counterpoint on Remote Servers and Workstations ...................................................................................... 10 File Sync ................................................................................................... 11 Exercise 5: Completing Multi-Site Configuration....................................... 12

Multi-Site Training Manual Multi-Site Deployment

Multi-Site Training Manual 2-1 Multi-Site Deployment

CUSTOM Folder on Servers

For new installs, create C:\CUSTOM on the Hub and each Remote server For upgrades, create CUSTOM below prior version’s Counterpoint top-level directory on the Hub and each Remote server Put these files in the CUSTOM folder on the servers:

File Where to obtain it

Registration.hub

(only on Hub server)

Download from Retail Partner website or obtain from your Counterpoint partner A unique Counterpoint registration file will be built from Registration.hub when Counterpoint is installed on each server. Each Remote server uses CPServices to contact the Hub server to obtain the registration information to build its own registration file.

<Schema change scripts> (Optional) Scripts used to add new custom tables or columns to the Counterpoint database

The databases created at the Hub and each Remote server must have identical schema in order for replication to work. Copy these scripts to the CUSTOM folder on each server so that they can be applied during the Counterpoint installation on the servers. Create and test the scripts on a development system that’s outside of the Multi-Site replication network.

<Custom replication rules>

(Optional) Replication rules developed with the DXRE Studio Designer If you add custom tables or columns to the Counterpoint database, you will need to modify the standard replication rules in order for data in the new tables and columns to be replicated. The Hub and each Remote server must use identical replication rules. Copy the custom replication rules to the CUSTOM folder on each server so that they can be applied during the Counterpoint installation on those servers. Create the custom replication rules on a development system that’s outside of the Multi-Site replication network.

Deployment.ini

(only for upgrades)

When upgrading Multi-Site from version 8.3.8 or 8.3.9, copy the Deployment.ini file from the prior version to the CUSTOM folder on each server.


Attach Pre-configured Database on Hub Server

On the Hub Server:

● If database is already configured and at V8.4, attach to Hub Server using SQL Server Management Studio.

● If database does not already exist, create a new one during the installation on the Hub server.

● Whether the database is already configured or a new one is created, the Counterpoint installation will:

o Build the Counterpoint Registration.ini file from Registration.hub o Apply any custom schema scripts to the database o Activate the database for replication o Provision the database (for purposes of CustomerConnect, SmartAlerts,

or Offline Ticket Entry)

● If you select to create a new database during installation, build the Counterpoint

data in it at the Hub.


Exercise 2: Preparing to Install Counterpoint

Try it Yourself!

In this exercise, you will copy the Counterpoint registration file to the CUSTOM

folder on the Hub server. You will also copy and attach the pre-configured V8.4 company database to the Hub server.

Perform Exercise 2 in the Exercise Handbook.


Install Counterpoint on Hub Server

To install Counterpoint on the Hub server: Log in to the Hub server as a Windows administrator

Start the SQL Server service (MSSQLSERVER) on the server

Navigate the Complete Counterpoint download, right-click setup.exe and select Run as Administrator.

Select the Folder name under which you want Counterpoint installed on the server.

To upgrade your Hub’s Multi-Site

database from either V8.3.8 or V8.3.9, enable the “I am updating from a previous version” check box.

At the Select Role window, select Multi-Site Hub server with Remote servers reporting to it.


Updating From a Previous Multi-Site Version

What is done when you select to update from a previous Multi-Site version? Do this before installing Counterpoint V8.4

Post tickets and settle credit cards Publish CPOnline orders Review custom modifications Replicate all remote servers with Hub (FirstSite) server Disable replication on all servers (enable after update is complete on all

servers) Back up Hub database and top-level Counterpoint directory Create CUSTOM folder below old version’s Counterpoint top-level directory

on each server (e.g., \CounterPoint) Copy Deployment.ini from

C:\CPSQLPackages\ServerFiles\DeploymentScripts to CUSTOM folder Copy registration.hub to CUSTOM folder (Hub only) Copy schema scripts and replication rules to CUSTOM folder

What Counterpoint installation does

Executes UpdateFromxxx.sql script against Multi-Site database

Copies company’s top-level files from old version over to new version’s folders

\CounterPoint\DemoHub Program Files\Radiant Systems\CounterPoint \

CPSQL.1\TopLevel\DemoHub Executes pdupgrade to apply new replication rules to database


CP Install Logs on Multi-Site Server

Logs located in Program Files\Radiant Systems\CounterPoint\CPSQL.1\Logs\CPLogs

SQLCMD.LOG All SQLCMD commands executed during install DXRECMD.LOG All DXRE commands executed during database activation


Exercise 3: Deploying Counterpoint on Hub

Try it Yourself!

This exercise consists of two steps, steps 3 and 4. In step 3, you will

install Counterpoint on the Hub Server and activate the database for replication, and

open the port assigned to CPServices.

In step 4, you will start CPServices on the Hub server and build some additional data in Counterpoint related to administering Counterpoint in a Multi-Site environment.


Install Counterpoint on Remote Servers

For a new install of Counterpoint:

● Be sure that you start Counterpoint on the Hub system before installing Remote Servers.

This ensures that you can access the Hub’s database before its data is replicated to any remote site, and also allows you to set the password for a CP administrator. You’ll need that password when registering a Remote server with the Hub.

● Do not install the Counterpoint service pack on the Hub server during initial setup. Wait until after all Remote servers also have Counterpoint installed, and then install the service pack on all servers at the same time.

● You must set up stores, locations, and workgroups on the Hub system before you install any Remote server.

● Best practice: Delay installation of Counterpoint on Remote servers until “base” Counterpoint data (items, inventory, customers, stations, drawers) have been configured on the Hub server.

● Do not attach an already configured database on a Remote server. A new database will be created on a Remote server and populated with data from the Hub’s database.


CPServices Indicators

Hub Server CPServices is running Float over to see system name (e.g., Main Store) Remote Server

CPServices is running Float over to see system name (e.g., East Store)

CPServices not running Float over to see URI it's trying to connect to (e.g., https://Hub/51968)


Exercise 4: Deploying Counterpoint on Remote Servers and Workstations

Try it Yourself!

This exercise consists of three steps, steps 5, 6 and 7. In step 5, you create the CUSTOM folder on the Remote server and copy any

custom schema scripts and replication rules to the folder.

In step 6, you will: install Counterpoint on each Remote server, during which

- the Remote’s database is activated for replication, - the first replication session is initiated with the Hub server, - the Remote server registers with the Hub server and selects its

workgroup - the Remote server’s workset subscriptions for replication are

selected open the port assigned to CPServices apply the latest Counterpoint service pack to the Hub and all Remote

servers At this point, you will be able to start Counterpoint on each server. In step 7, you will install the Counterpoint prerequisites and Counterpoint on

each workstation. Perform Exercise 4 in the Exercise Handbook.


File Sync

● Component of CPServices that synchronizes files in Software Updates folder and company’s Configuration folders from Hub server to Remote servers

● Enabled when Remote server registers with Hub server, as long as company aliases are identical

● What is synchronized? Contents of SoftwareUpdates Data dictionary settings Custom reports and forms Custom label files and queries Item and Customer images Custom Quick Reports

● Automatic synchronization occurs at 2:30 am on Remote server

● Initiate manually by connecting to Hub server in NCR Counterpoint Management Console and selecting Request File Sync


Exercise 5: Completing Multi-Site Configuration

Try it Yourself!

In this exercise, you will manually initiate a File Sync from the Hub to the Remote

server so that the Remote server gets the company’s Configuration folders immediately.



Customizing File Sync

Create FileSyncConfig.xml in Counterpoint Bin folder to:

On server

On client Contents of FileSyncConfig.xml

Identify role of system Add other server folders to synchronize (FileSyncConfig.xml on server)

<FileSyncSystemConfig>  <IsServer>true</IsServer>

 <IsClient>true</IsClient>

</FileSyncSystemConfig>

Add other server folders to synchronize

Change the destination delivery folder

Change the snapshot schedule

Settings for a Remote server that’s a host to offline workstations and

a client to a Hub server

<FileSyncSystemConfig> <IsServer>true</IsServer> <FileSyncConfigList>

<FileSyncConfig ConfigId="5001" ConfigName="Utils"> <BaseDir>D:</BaseDir> <SyncDir>Utils</SyncDir> <IncludeSubfolders>true</IncludeSubfolders> <Description>File Sync configuration for the Utils

folder</Description> <ExclusionDirectories>

<Directory>LocalOnly</Directory> </ExclusionDirectories> <ExclusionFiles>

<File>Licenses.dat</File> </ExclusionFiles> </FileSyncConfig>

</FileSyncConfigList> </FileSyncSystemConfig>

Sets up D:\Utils and its subdirectories on the server to be synchronized with client machines, excluding D:\Utils\LocalOnly folder and the Licenses.dat file. Assign

unique ConfigId from 1 – 3998.


Change destination delivery folder and snapshot schedule (FileSyncConfig.xml on client)

Snapshot schedules:

0 0 1 1 * Run once a year at midnight in the morning of January 1

0 0 1 * * Run once a month at midnight in the morning of the first of the month

0 0 * * 0 Run once a week at midnight in the morning of Sunday

0 0 * * * Run once a day at midnight

0 * * * * Run once an hour at the beginning of the hour

Disabling File Sync (Bin\CPSvcs.exe.config on server)

<FileSyncSystemConfig> <FileSyncConfigOverrides>

<FileSyncConfigOverride ConfigName="Utils"> <BaseDir>D:</BaseDir>

</FileSyncConfigOverride> </FileSyncConfigOverrides> <SnapshotUploadSchedule>0 * * * *</SnapshotUploadSchedule>

</FileSyncSystemConfig>

Syncs C:\Utils from the server to D:\Utils on client system. Changes snapshot upload schedule to run at the begtinning of each hour.

ConfigId is not used in client's file.

Add SuppressLoad=”true” to File Sync ServiceModule line. Save file and restart

CPServices when done.

minute (0-59)

hour (0-23)

day of month (1-31)

month (1-12)

day of week (0-6 where 0=Sunday)

Multi-Site Training Manual Other Deployment Activities

SECTION 3: OTHER DEPLOYMENT ACTIVITIES

Installing a Counterpoint Service Pack .......................................................3 Updating to a New Counterpoint Version ...................................................6 Updating a Counterpoint Registration ........................................................7 Installing a Permanent DXRE License .......................................................9 Updating the Multi-Site Configuration ....................................................... 11 Activating or Updating a Database ........................................................... 14 Adding a Store or Location ....................................................................... 18

Multi-Site Training Manual Other Deployment Activities

Multi-Site Training Manual 3-1 Other Deployment Activities

Other Deployment Activities After Counterpoint is installed, other deployment activities may be necessary to keep the Hub and Remote sites operating properly. Some of the additional activities include:

Install a Counterpoint Service Pack

Update to a new Counterpoint release

Update a Counterpoint registration

Install a permanent DXRE license

Activate a database for replication or update an existing replicating database

Change the CPUser or PDUser login for an existing replicating database

Add or Remove a Store or Location Each of these activities is described on the following pages.



Installing a Counterpoint Service Pack On the Hub and each Remote server, download the current Counterpoint service pack (CPSP84.exe.zip) from the Counterpoint web site (www.counterpointpos.com/support/software_cpsql.htm).

http://www.counterpointpos.com/support/software_cpsql.htm


Installing a Counterpoint Service Pack with Rules Changes

If Service Pack contains rule file changes and server is using an earlier version of CP, this window appears:

Choice What it means

I do not have a custom Rules file Proceed with service pack install

I have already updated my custom Rules file

You have put the updated custom rules file in the CUSTOM folder on the server and are ready to install the service pack

I need to download the new Rules file to make my changes

You want to download the new Rules file so that you can update it with your customizations. Service pack install will be terminated.

I am no longer using Multi-Site MultiSite.ini was found on the server because, at some point, server had been configured for Multi-Site. Choose this option to rename the file to MultiSite.ini.old, and to proceed with service pack install.

For either I do not have a custom Rules file or I have already updated my custom Rules file, respond that you have completed each of the pre-installation steps before proceeding with the service pack installation. See Update Guide for details on each step.


Installing a Counterpoint Service Pack On a server, when service pack installs:

updates Bin, TopLevel, and Scripts directories on server

If schema changes are involved,

Requests SQL credentials

Applies ServicePackUpdateFor8.x.sql to all databases that have connection strings in Companies.ini

Provisions database for primary company

On a workstation, when Counterpoint is started the next time:

executes CPSQLSP.exe from SoftwareUpdates folder on server

For Never Offline workstation, updates Bin directory

For Sometimes or Always Offline workstation with a connection to the server:

Updates TopLevel and Scripts directories If schema changes are involved, applies

ServicePackUpdateFor8.x.sql to the offline database

For Always Offline workstation without a connection to the server: Manually run CPSP84.exe on workstation

If your workstations are running under Terminal Services, the service pack will

update only the Terminal Server and not the workstations attached to the Terminal Server.


Updating to a New Counterpoint Release

After downloading the new Counterpoint release If schema changes have been previously made to the database, and custom

replication rules are currently in use, verify how these are impacted by the new release.

You may need to update your scripts that make the schema changes and you will need to modify the new replication rules to re-add your customizations.

On the Hub server

Before installing the new release, force replication with each remote server 3 times in rotation (remote1, remote2, remote3, then remote1, remote2, remote 3 again, etc.).

Use the DataXtend Controller to make the Hub’s database unavailable.

Install Counterpoint prerequisites

If it’s not already present, create CUSTOM folder under old version’s top-level Counterpoint directory

Copy Counterpoint registration file to CUSTOM folder on Hub server

Copy any custom schema scripts and replication rules to CUSTOM folder on Hub server

Install Counterpoint on the Hub server

Start CPServices on the Hub server

Use the DataXtend Controller to make the Hub’s database available.

After all Remote servers have updated to the new release, download and install the current Counterpoint service pack on the Hub server

On each Remote server

After the Hub server has completed the update to the new release:


Create CUSTOM folder under old version’s top-level Counterpoint directory

Copy any custom schema scripts and replication rules from Hub server to CUSTOM folder on each Remote server

Install Counterpoint on each Remote server

Download and install the current Counterpoint service pack on each Remote server (after installing it on the Hub)

On each workstation

After a workstation’s server has completed the update to the new release:


Execute ClientSetup.exe on each workstation


Updating a Counterpoint Registration

Reasons for updating your Counterpoint registration

Purchased a new Counterpoint Option(s) for the system.

Increased the number of users in the Counterpoint license. Added a new Remote Server to the Counterpoint system. Received a permanent registration file and need to replace the temporary

one.

Hub and Remote servers have already updated to a new version of Counterpoint and did not have the updated registration file at that time.

On the Hub server

1. Copy Registration.hub to the Counterpoint TopLevel directory (Program Files \ Radiant Systems \ CounterPoint \ CPSQL.1 \TopLevel on the Hub server. Also copy it to the CUSTOM folder under CPSQL.1.

2. Select Start / Programs / NCR Counterpoint / Utilities / Multi-Site / Create Registration File.

At the Select Role window, select Multi-Site Hub with Remote servers reporting to it.

Complete the rest of the windows in this function to create a new Multi-site registration file for the Hub server.


On each Remote server

1. Select Start / Programs / NCR Counterpoint / Utilities / Multi-Site / Create Registration File.

At the Select Role window, select Multi-Site Remote server that reports to a Hub.

At the Remote Multi-Site Information window, specify the Hub server’s IP address, host name, or DNS. Also identify the Port # used by CPServices on the Hub server. Select the serial number assigned to the Remote server.

Complete the rest of the windows in this function to create a new Multi-site registration file for a Remote server.


Installing a Permanent DXRE License

Temporary license expires 30 days after installing DXRE

Cannot create permanent DXRE license until permanent Counterpoint registration is installed and updated on all servers and Offline V1 workstations

Creating the permanent DXRE license

1. On the Hub server, or a workstation connected to that server, start Counterpoint and log in to your company database.

2. Select Setup / System / Registration. Click to create the permanent license for DXRE. The license

file is named PDLicense.PNL and will be located in Program Files / Radiant Systems / CounterPoint / CPSQL.1 / Scripts.

Installing the license

3. To add the permanent DXRE license, select Start / Programs / DataXtend /

Remote Edition / Controller on the Hub server. Select Available Databases

from the Actions menu.


Select the Hub's database from the

list of Available Databases, and click .

Browse to Program Files / Radiant Systems / CounterPoint / CPSQL.1 /

Scripts on the Hub server. Select the PDLicense.PNL file and click Open. Click OK when completed and close the DataXtend Controller utility. Restart the DataXtend Replication Engine service.


Updating the Multi-Site Configuration

The MultiSite.ini file is built when you activate a database, and contains settings

that will be used the next time Multi-Site is installed on the system or if the database is activated again.

The Update Multi-Site Configuration utility allows you to correct some of the settings in the MultiSite.ini file.

The fields that you can correct include: CPUser ID (SQL user who “owns” the Counterpoint database) CPUser password

PDUser ID (if you change the PDUser ID, you will also need to

PDUser password make modifications to several database triggers) After correcting any values, you can choose to run the Activate or Update

Database utility or you can use SQL Server Management Studio to add the SQL user and give them “dbowner” permission to the Counterpoint database.

Start the utility by selecting Start / Programs / NCR Counterpoint / Utilities / Multi-Site / Update Multi-Site Configuration. Click Next at the Welcome

window.


Settings on a Hub server

The current Multi-Site configuration settings appear.

If they are already correct, select I

do not want to change the configuration settings. The utility will exit after you click Next.

To change the settings, simply click

Next. Settings on a Remote server When the Multi-Site Login

Information appears, you can change the CPUser ID or password.

We suggest that you do not change

the PDUser ID.


At the Start Installation window, a

message appears to tell you that the Multi-Site confugration logins and passwords are ready to be updated.

A final window appears to tell you that the Multi-Site configuration file has been updated.


Activating or Updating a Database

During the installation of Counterpoint on a Multi-Site server, you have the option

to either create a new database or use a pre-configured database. The database will automatically be activated for replication as part of the Counterpoint installation.

Use the Activate or Update Database utility (Start / Programs / NCR

Counterpoint / Utilities / Multi-Site) if:

1. You are switching a standalone or WAN server with an existing database to a Multi-Site Hub server

2. You need to apply schema changes or replication rule changes to a database that is already activated for replication

Before running this utility, ensure that you have copied any custom schema scripts and/or replication rules to the CUSTOM folder that’s located in Program Files \ Radiant Systems \ CounterPoint \ CPSQL.1 on the Hub server and each Remote server. On the Hub server only, also place registration.hub on the CUSTOM folder. Run the utility to completion first on the Hub server, and then on each Remote server.

Start the utility by selecting Start / Programs / NCR Counterpoint / Utilities / Multi-Site / Activate or Update Database.

Identify whether SQL Server is installed as the default instance on the current server (This computer) Or as a named instance on the current server or on an entirely different server (Other computer).


Select whether the activation should use Windows authentication or SQL authentication. Ensure that the path to the SQL Server data files is accurate. Click Next at the Welcome window.


1) If you are switching a standalone or WAN server with an existing database to a Multi-Site Hub server:

Select Multi-Site Hub server with Remote servers reporting to it. (Remote servers should always convert from a standalone or WAN system by installing Counterpoint.)

Enter or browse to the path for your

CUSTOM folder.

Select the Counterpoint database that

you want to activate. Select the alias associated with the

database.


Click Next to start the activation

process.

2) If you need to apply schema changes or replication rule changes to a database that is already activated for replication:

Verify the parameters that will be used for the activation process. If necessary, select I want to change the login parameters to modify the CPUser ID or password. We suggest that you do not change the PDUser ID. Click Next at the Start Installation window to begin the activation or update of the database. You will see several messages as the database is activated or updated.


Adding a Store or Location to Multi-Site

To add a new store or location to an existing Multi-Site environment, follow these steps:

1. Download the new registration.hub file from the partner website and copy it to Program Files \ Radiant Systems \ CounterPoint \ CPSQL.1 \ CUSTOM on the Hub server.

2. On the Hub server, start Counterpoint and create the new location, new store, new workgroup, new tax code (if necessary), stations, drawers, users, and assign user drawers. Also run Inventory/Utilities/Create Inventory to create inventory records for the new location.

3. Install the Counterpoint Prerequisites on the Remote server and any workstations.

4. If you used custom schema scripts or replication rules for the Hub’s database, create a C:\CUSTOM folder on the new Remote server and copy the same scripts and replication rules from the Hub server to the CUSTOM folder on the Remote server.

5. Install Counterpoint on the Remote server.

6. Open the CPServices port on the Remote server.

7. Install the Counterpoint Service Pack on the Remote server.

8. Install Counterpoint on any workstations.

9. Use the Multi-Site Configuration Editor to change the replication subscriptions that were automatically set for the new remote server.

10. If you defined specific replication schedules for each server (rather than a single replication schedule for 'All Sites'), use the Multi-Site Configuration Editor or DataXtend Administrator to set up replication schedules for the new Remote server.

Multi-Site Training Manual DXRE Concepts

SECTION 4: DXRE CONCEPTS

What Data is Replicated: Replication Rules ...............................................1 Exercise 6: Installing DataXtend Studio .....................................................2 Replication Rules .......................................................................................3 Global Tables ..................................................................................4 Local Tables ....................................................................................5 Fragments .......................................................................................6 Transaction Sets .............................................................................8 Work Sets .......................................................................................9 Subscribing to Work Sets .............................................................. 12 Subscribing to Work Sets Using Multi-Site Configuration Editor ... 13 Exercise 7: Subscribing to Work Sets ....................................................... 16 Saving the Custom Replication Rules ...................................................... 17 Regenerating the DXRE Feedback Filter ...................................... 18 When and How Often to Replicate ........................................................... 19 Scheduling Replication Using Multi-Site Configuration Editor ....... 20 Scheduling Replication Using DataXtend Administrator................ 22 Exercise 8: Scheduling Replication .......................................................... 24 Database Activation Process ................................................................... 25 Q&A: Initial Replication and Subscriptions ............................................... 27 Exercise 9: Viewing the Results of Activation .......................................... 29 PDC Control Tables ................................................................................. 30 Fragments and PDC Control Tables ............................................. 31 Delta Update Tables ................................................................................ 34 Delta Tracking Example ................................................................ 35 Delta Update Tables and Triggers ................................................ 36 Delta Update Tables ..................................................................... 37 Ways to Start Replication ......................................................................... 38 Replication Partner Selection ................................................................... 41 Making a Site Unavailable Temporarily .................................................... 42

Multi-Site Training Manual DXRE Concepts

Database Maintenance for Multi-Site ....................................................... 43 Deactivating a Remote Database ............................................................. 44 Moving a Replicating Database – Hub ..................................................... 46 Moving a Replicating Database – Remote ............................................... 48 Condemn vs Pdreset vs Duninst .............................................................. 50

Multi-Site Training Manual 4-1 DXRE Concepts

What Data is Replicated?

Determined by Replication Rules and Site Subscriptions Replication Rules

Pre-defined for Counterpoint (msdelta.rul in Scripts directory)

Developed and viewed using DataXtend Designer (component of DataXtend Studio)

Imported into Counterpoint database when database is activated or upgraded for replication

Hub Server

CP database

Remote Server

CP database replication

Online access Online access

Workstation Workstation


Exercise 6: Installing DataXtend Studio

Try it Yourself!

Skip this exercise if you did not bring your own computer to class. In this exercise, you will install the DataXtend Studio (which includes the

DataXtend Designer) on your own computer. The DataXtend Replication Engine will also install, if it is not already present.

In addition, you will 1) copy and attach the DemoHub database on your system,

2) create an administrative user named pduser with db_owner access to the DemoHub database, and then 3) import the replication rules for Counterpoint into the database.

After these operations are done, you will be able to use the DataXtend Designer

to see the replication rules for that database. For class, you will need to have handy the Counterpoint flash drive. Perform Exercise 6 in the Exercise Handbook.


Replication Rules

For Counterpoint, Replication Rules define: Global tables All records are replicated to all sites

Examples: AR_CATEG_COD, PO_VEND

Local tables Not replicated. Table remains "local" to each site.

Examples: AR_RENUM_CUST, IM_TAG

Work Sets Groups of tables whose data is replicated together. Each site must subscribe to the work set slices they wish to maintain at their site.

Examples: IM_LOC_SUBSCRIBE PS_STR_SUBSCRIBE SY_EVENT

Fragments Fields within a table that must be replicated together.

Transaction Sets Related records in multiple tables that must all successfully replicate or that must all be "rolled back" if there's a problem with any record.


Replication Rules: Global Tables

Global Tables All records are replicated to all sites

In the Designer, Global Tables are shown on the "Replicated" tab and are not assigned to any work set.


Replication Rules: Local Tables

Local Tables Not replicated; table remains local to each site

In the Designer, all Local Tables are shown on the "Not Replicated" tab. If you have added a custom table to the database, the table initially appears on the "Not Replicated" tab. Right-click and select Replicate table to add it to the list of Global tables.


Replication Rules: Fragments

Fragments Fields in a table that should replicate together are

grouped into the same fragment

Prevents "data collisions" if multiple sites update data in different fragments of the same record

Only fragments with revised data are replicated

Primary key field is not in a fragment

Non-replicated fields are in a fragment named "Local"

View fragments using DataXtend Designer ("Structure" tab) IM_ITEM

One site can change the Category for an item, and another site can change the Description for the same item, with no conflicts during replication.

If data in any of these fields changes, all of the fields in the "CATEG" fragment are replicated.


Replication Rules: Fragments

Tables with Multiple Fragments AR_CUST AR_SHIP_ADRS IM_INV IM_ITEM PO_VEND PO_VEND_ITEM PS_STA PS_STR SY_LBL_JOB SY_WRKGRP


Replication Rules: Transaction Sets

Transaction Sets Tables whose related records must be handled as a

single SQL transaction (commit or rollback at both sites)

Master + detail records in different tables (tickets, cash receipts, purchase orders)

View transaction sets using DataXtend Designer ("Transaction" tab)


Replication Rules: Work Sets

Work Sets Multiple tables whose data is related and needs

to be replicated together

Some worksets based on stores and locations

Information for a single location or single store is a "slice" of a work set

Site must be subscribed to full work set or "slice" to have access to data in work set's tables

In the Designer, tables in work sets are shown on the "Replicated" tab with the name of the work set to which the table is assigned. To receive and replicate data in these tables, a site must be subscribed to the work sets that contain the tables. To add a custom table to a workset, the custom table must have at least one column that links to some table in the workset. On the "Work Set" tab, click the link-to table in the workset. When the custom table displays under "Related Tables", click Add to Work Set.



Work Set Name Description of Data

DM_STR_HIST_SUBSCRIBE (Dashboard data)

Aggregated Dashboard data for a store

Subscribe to view aggregated data in Dashboard.

Each remote server should subscribe to its own store's slice, if the site plans to use the Dashboard to view its own performance.

DM_LOC_HIST_SUBSCRIBE (Forecasting data)

Aggregated Forecasting data for a location

Subscribe to use aggregated data for Forecasting.

Each remote server should subscribe to its own location's slice, if the site plans to build forecasts for use with forecast-driven replenishment.

IM_LOC_SUBSCRIBE (Inventory data)

Primary data for a location. Includes the location record, inventory records, and unposted inventory transactions.

Subscribe to view inventory information, or to enter inventory transactions.

Each remote server should subscribe to its own location's slice.

IM_LOC_HIST_SUBSCRIBE (Inventory history data)

History of all posted inventory transactions for a location.

Subscribe to post inventory transactions, or to view or report on history for a location.

Each remote server should subscribe to its own location's history work set slice.

PS_STR_SUBSCRIBE (Store config data)

Primary data for a store, including store record, unposted PS documents and credit card transactions, customer data, and unposted A/R transactions.

Subscribe to enter sales tickets, orders, holds and/or quotes, to add or maintain customer information, or to enter A/R transactions.

Each remote server should subscribe to its own store's slice.

PS_STR_HIST_SUBSCRIBE (Misc store history data)

History of drawer closing, A/R transactions, and timecard data.

Subscribe to post PS documents or A/R transactions, to settle credit card transactions, or to access timecard data.

Each remote server should subscribe to its own store's history work set slice.

PS_STR_DAY_SUBSCRIBE (Point of Sale history data)

History of all posted Point of Sale documents and associated credit card transactions, and commissions.

Subscribe to post PS documents or A/R transactions, to settle credit card transactions, or to view or report on history for a store or customer.

Each remote server should subscribe to its own store's work set slice, for the number of days to retain history.

SY_EVENT (Distributions)

History of all posting events and distributions.

Auto-subscribe to receive distributions and event records for other sites. No slices.

Normally, remote servers do not subscribe to this workset.

Note: After Multi-Site is configured and operating, new stores, locations, and calendars can only be created on the Hub server, and existing stores can only be deleted at the Hub.



Work Set Example

Base table

First Dependent table

Foreign keys in this table, back to parent table (IM_XFER_IN_LIN)


Subscribing to Work Sets

Use Multi-Site Configuration Editor to change work set subscriptions for each site

The Hub server is automatically subscribed to all work sets for all sites (“auto-subscribed”)

Each Remote server is automatically subscribed to work sets for its own location and store.

Select Start | CounterPoint SQL | Utilities | Multi-Site | Multi-Site Configuration Editor

Connect to Hub server

Enter subscriptions for all sites at Hub Can change subscription for a site to include other location/store

“slices” of work set data

PS history subscriptions for remote servers can be changed to retain more or less than 90 days of history

Multi-Site Configuration Editor is alternative to using DataXtend Administrator to manage subscriptions

Subscriptions entered via Configuration Editor appear in DataXtend Administrator

Unable to set number of days of PS history in DataXtend

Administrator (all days or none)


Subscribing to Work Sets using Multi-Site Configuration Editor

Select Start | Programs | CounterPoint SQL | Utilities | Multi-Site | Multi-Site Configuration Editor Enter the ID and password of the DXRE

administrator. On the Subscriptions tab, select a work set for which you want to assign

subscriptions

The Hub server is always “Auto-subscribed” to all slices of all work sets (a “Complete” database).

Initially, each remote server is subscribed to its own location/store work set

slice. Note: Avoid auto-subscribing a remote site to a work set other than

Distributions. If you later decide to change the subscriptions, the act of clearing auto-subscribe will remove all of the data for that work set before it then replicates any slices that you might have selected.


Remote servers do not need to subscribe to the Distributions work set at all. Each server will generate distributions and events for the transactions posted on its own system. Click after changing a subscription. Remote servers must subscribe to the Inventory data for any location for which they intend to sell, purchase or receive inventory. And the remote servers will also need to subscribe to the Inventory History data for the same locations in order to post the transactions that they have entered. In order to post tickets for a store, to post Receivables transactions, and to view Timecard data, remote servers must subscribe to their own store’s slice of the Misc store history data work set.


In order to sell to any customer, a remote server will need to subscribe to all slices of the Store config data work set.

In order to post tickets for a store, remote servers must subscribe to their own store’s slice of the Point of Sale history data work set.

You can also select the number of days of ticket history that will be retained on the remote server.


Exercise 7: Subscribing to Work Sets

Try it Yourself!

In this exercise, you will use the Multi-Site Configuration Editor on the Hub server to view the work set subscriptions that were configured for the Remote server and the Hub server.



Saving the Custom Replication Rules

To produce the custom replication rules after completing your changes, follow these steps: 1. Verify rules Select Tools / Verify rules. Correct any errors and reverify until no errors are

reported. 2. Save verified rules Select File / Save. 3. Prepare to activate Select Tools / Prepare to Activate. If necessary, clear "Mark starter data for replication".

(Do not select this on a development system.) 4. Export rules Select File / Export Rules. Name your custom rules file something other than

msDelta.rul, the default rules file name. We suggest msCustom.rul.

This is the file that will need to be copied to the

CUSTOM folder under Program Files / Radiant Systems/ CounterPoint / CPSQL.1.*

5. Create text file Select File / Export Script This produces a readable text file of the custom

replication rules that you can use to compare to a text file of the standard replication rules to see the changes between the two sets of rules.

* In addition to copying the custom rules file to the CUSTOM folder, you will also need to:

copy the SQL script that alters the database schema to the CUSTOM folder

either install Counterpoint, or use the Activate or Update Database utility to [re]activate the database.

regenerate the DxreFeedbackFilter.sql script (see next page)


Regenerate DxreFeedbackFilter.sql

If you produce custom replication rules in an existing replicating environment, you must also regenerate DxreFeedbackFilter.sql and execute it against your replicating databases. To regenerate DxreFeedbackFilter.sql

Exit to a command prompt and switch to the Bin folder under the Counterpoint instance folder.

From the Bin folder, execute the following command:

CpCmd DxreFeedbackFilter /db=<server>:<databasename> /dbUser=pduser /dbPassword=PDPassword8 /generateonly /OutputFile=<full path to where script should be created>

Either indicate to generate the script in the Scripts folder below the Counterpoint instance folder, or move the generated DxreFeedbackFilter.sql script to that folder after the script is created (and overwrite the existing one).

Copy the regenerated DxreFeedbackFilter.sql script to the Scripts folder on all replicating servers (Hub and remote servers).

Then, when no one is using Counterpoint, use the SQL Script Utility or the Query Editor to execute the script against the activated database on each server.


When and How Often to Replicate

Considerations

Avoid conflict with other scheduled events (e.g., database backups).

Replicating can cause heavy use of system resources and impact performance for other processes.

Replicating during the day can result in unposted transactions replicating to multiple sites; problems if they get posted at multiple sites (avoid by using workgroup or user batch IDs)

Replicating during heavy database activity may result in conflicts if child tables are replicated, and parent records were not yet present to replicate.

Replicating frequently can result in lower impact on performance, due to less data.

How many sites need to replicate on the same schedule? You will be able to define a different schedule for each site, or all sites can use the same schedule.

Enter schedules for all sites on the Hub server Default replication schedule: Servers: Every 30 minutes, Monday - Friday 8:00 am to 7:00 pm Use Multi-Site Configuration Editor or DataXtend Administrator to create

your own schedules.


Scheduling Replication using Multi-Site Configuration Editor

Select Start | Programs | CounterPoint SQL | Utilities | Multi-Site | Multi-Site Configuration Editor Enter the ID and password of the DXRE

administrator. Switch to the Site Info tab.

Select the server for which you want to build a schedule.

The server’s database, DXRE site ID and Site Type appear.


Click to define a schedule for the server. Applies on the following options:

Action options:

Enable Scatter to prevent replication from starting at all sites at exactly the

same time.

At Every,identify the amount of time to elapse before another site starts replication. At For, indicate the amount of time by which all of the sites should have started. This value needs to be less than the value of Replicate Every.

Example: In a replication network with 12 sites, specifying to

scatter Every 5 minutes for 30 minutes means that every 5 minutes, two sites will start replication and that all 12 sites will have started within 30 minutes.

Click Replicate Now to force replication between the Hub and Remote server, to immediately send the new schedule to the remote site.


Scheduling Replication using DataXtend Administrator

Select Start | Programs | DataXtend | Remote Edition | Administrator

Can define one schedule that applies to several sites

Can define multiple replication schedules for a single site

Can define more complex replication schedules

Enter schedules for all sites on Hub server

Select a specific site from the left pane. To include multiple sites in a single schedule, select All Sites, Complete Sites (Hub server), or High Sites (Remote servers). (We don’t have Low Sites in Multi-Site.) Then switch to the Schedule tab.

Click to

enter a new schedule.


To disable the schedule without deleting it

To restrict partner for bandwidth cycles

Name the schedule as you want. Under On the Following Days,

select whether to replicate: - on specific days of the week, - for a certain period each month, or - only for a specific date range. Under Between the hours of,

specify the times (on a 24-hour clock) during which replication is allowed.

Under Perform the Following,

enable Replicate Every and enter how often replication should be done within the specified time period.

Scatter works the same way as shown for the Multi-Site Configuration Editor. Other choices: Replicate at least If site hasn't replicated at all within the specified time

frame, start a session. If it fails, retry after specified "repeat every" time.

Push Local Changes If site hasn't replicated at all within the specified time

frame, start a session and push local changes to another site. Retry if it fails.

Pull Remote Changes If site hasn't replicated at all within the specified time

frame, start a session and obtain changes from another site. Retry if it fails.

Every [hh:mm] Specified time frame Retry every [hh:mm] For failures, retry after "retry every" interval Click when completed. A message appears to advise that the schedule will take effect after the schedule

records are replicated to the involved site(s). After you click OK at the message, the schedule is honored on the Hub server immediately and replication to other sites will occur based on the schedule. (You can instead manually initiate replication, if you don't want to wait until the next scheduled replication time.)

Deleted schedules will take effect only after replication occurs and the replication

engine is subsequently stopped and restarted at the involved site(s).


Exercise 8: Scheduling Replication

Try it Yourself!

In this exercise, you will build replication schedules on the Hub server.

You will begin by using the Multi-Site Configuration Editor to build a custom schedule for the Remote1 server. You will then use the DataXtend Administrator to view the schedule that you built for Remote1, and you will also build a new schedule there for all sites.



Database Activation Process

What happens when a site’s database is activated for replication?

1. Creates pduser database login If this particular user makes changes to Counterpoint data, the changes are

not flagged for replication.

2. Imports replication rules and applies them to database ("dimprule")

- creates the DXRE system and control tables in the database

- loads system data records

- generates control table records for all the application data

Updates system and control table definitions and replication rules for

databases that are already activated

3. Generates and applies replication triggers to the database ("dtrigger")

- triggers will fire when records are inserted or changed in a CP table

- if user is NOT pduser, trigger will update associated fragment in PDC Control table record

Includes creating new PDC Control table records for inserts, changes to PDC

Control tables based on work set and transaction set slice memberships, and flagging deletions for delete operations. For all operations, it modifies the control table timestamps to flag the recent update.

4. Applies delta triggers to the database ("msdelta.sql")

- creates initial records in MSD tables

- triggers will fire when specific fields are updated in certain Counterpoint tables

- if user is NOT pduser, trigger on user table will update associated MSD table

- if user is pduser (during replication), trigger on MSD table applies delta value to user table


5. Activates database at site and initiates first replication ("dinst")

- on Hub Site only, initializes replication network and allocates GUIDs that will be used in PDC Control tables throughout the replication network

- partners database with replication engine, making database available for replication

- creates data source for local database: (PDrrrrrrnnn, where rrrrrr=releaseID and nnn=activation instance e.g., PD29BZ1O001)

- if replication engine is running, performs first replication with the partner site (Hub server)

Requires exclusive access to partner site to ensure proper initialization of starter data at the new site (one site at a time)

Obtains GUID blocks for PDCID values in PDC Control tables

Obtains system table records (dSite, dSched, etc.)

Obtains all Global table records

6. Applies dsetting parameters to the database

- MINIMALTABLELOCKING = Y Locks row instead of table during replication, so that table can be

updated by multiple replication sessions running at the same time

- QUERYCACHESIZE = 10000000 Amount of disk cache allocated to replication engine for queries.

- /CLEAR AUTOCOMMIT Clear setting that forces the replication engine to commit every

update immediately (previously needed due to bug)


Q&A: Initial Replication and Subscriptions

The first time a database is activated for replication at a site, the replication engine (if running) automatically performs the initial replication with the partner site. Unlike other sites, when the Hub’s database is activated the first time, it does not automatically perform the initial replication. During setup, the initial replication typically occurs immediately after the database is activated and default data subscriptions are set. Subscriptions to work sets for all sites and the replication schedule(s) are entered on the Hub, using the Multi-Site Configuration Editor or DataXtend Administrator.

Q: When is the database first activated at a site? A: _________________________________________________________

Q: What system is selected as the "partner site" for initial replication? A: _________________________________________________________

Q: What data is replicated during the first replication session? A: _________________________________________________________

_________________________________________________________

Q: How do other sites "find out" the work sets they are subscribed to and the schedule for replication for their site?

A: _________________________________________________________

Q: Why doesn't the Hub automatically perform the initial replication when its database is activated?

A: _________________________________________________________

Q: How do other sites get the actual data in the tables that belong to work sets to which they are subscribed?

A: _________________________________________________________


When subscribing a site to a work set, you can auto-subscribe them to the work set or you can subscribe them to specific "slices" of the work set. After defining replication schedules on the Hub and applying them, the Hub will honor the schedule and attempt to replicate at the next scheduled time.

Q: What can you do to replicate the information from the Hub sooner than the next scheduled time?

A: _________________________________________________________

Q: What's the difference between auto-subscribing and subscribing to all "slices" of a work set?

A: _________________________________________________________


Exercise 9: Viewing the Results of Activation

Try it Yourself!

In this exercise, you will use the SQL Server Management Studio to view the DXRE system and control tables that were created in the DEMOHUB database when the replication rules were imported at the beginning of the activation process.

You will also see the triggers that were applied to the database during activation. Perform Exercise 9 in the Exercise Handbook.


PDC Control Tables

At each site, for every Counterpoint table that can be replicated … IM_ITEM PDCIM_ITEM PDC control tables are created in a site's database when the replication rules are imported.

there's a corresponding PDC control table that tracks the date and time that a change was made to a record, and the site that made it.


Fragments and PDC Control Tables

PDCIM_ITEM Separate control tables maintained at each site When considering records for replication at a site, compares PDC1 stamp in local control record to last time replication occurred for this table between the two partner sites (from local dActHist table).

Creation date/time of this record (12/31/1979 = starter data: data was present when database was activated)

Last time this record was updated (12/31/1979 = never been replicated) , and site ID who changed it

Last time this fragment was updated, and site ID who changed it

PD control ID


Fragments and PDC Control Tables

Start replication 1) What tables and work sets are subscribed in common between the two sites? 2) For a table or work set in common, check dActHist record for table and partner

site: when was last time this table was replicated with this site? dActHist – site #1 dActHist – site #2

IM_ITEM: Last replic w/#2 = Friday 01:00 IM_ITEM: Last replic w/#1 = Friday 01:00 Last replic w/#3 = Saturday 05:00

3) Since Site #1 has replicated this table with another partner since Friday, some records may be more current at site #1 than at site #2.

Compare PDC1 times in each site's PDCIM_ITEM record: when is the last time

this record was updated at each site? PDCIM ITEM – site #1 PDCIM ITEM – site #2

Item #100: PDC1 = Saturday 05:01 Item #100: PDC1=Friday 01:08

4) If PDC1 times for either site are later than the last replication date/time between the two sites, compare each fragment's PDC1xxxx values. Replicate data from more current fragment to other site, and update PDC1xxxx and PDC2xxxx values for that fragment at site that was updated.

PDCIM ITEM – site #1 PDCIM ITEM – site #2

Item #100: PDC1 = Saturday 05:01 Item #100: PDC1 = Friday 01:08 PDC1Desc = Saturday 05:01 PDC1Stat = Friday 01:08 PDC2Desc = site #1 PDC2Stat = site #2

Site #1 Site #2


After replicating a record, update PDC1 time in each site's PDCIM_ITEM record

with most current PDC1 value (either site 1's or site 2's). PDCIM ITEM – site #1 PDCIM ITEM – site #2

Item #100: PDC1 = Saturday 05:01 Item #100: PDC1 = Saturday 05:01 PDC1Desc = Saturday 05:01 PDC1Stat = Friday 01:08 PDC2Desc = site #1 PDC2Stat = site #2 PDC1Stat = Friday 01:08 PDC1Desc = Saturday 05:01 PDC2Stat = site #2 PDC2Desc = site #1

5) When replication of a table completes, update dActHist record at each site with "last replication" timestamp for that table and partner site.


Delta Update Tables

Delta Update Tables (xxxxx_MSD)

For tracking life-to-date change (in relation to zero) to values updated by transaction posting at all sites

Members of replication work sets

MSD tables updated by triggers that fire during normal transaction posting

Columns in master tables do not replicate and get updated only by triggers on the MSD table that fire during replication to apply changes from MSD records

Example: When site 100000 changes Qty_Commit from

10 to 12, triggers at other sites will apply a +2 change to Qty_Commit in the IM_INV table during replication.

IM_INV_MSD


Delta Tracking Example

Consider the delta column IM_INV.QOH (quantity on hand) for location MAIN

Each site starts with an IM_INV record for MAIN that starts with QOH = 0. Each site then posts a transaction that updates QOH. Triggers on IM_INV create/update IM_INV_MSD records at each site.

Site #1 (Hub) Site #2 Site #3

IM_INV.QOH 0 0 0

IM_INV_MSD (#1, 0) (#2, 0) (#3, 0)

TRX QTY +1 +2 +3

IM_INV.QOH 1 2 3

IM_INV_MSD (#1, +1) (#2, +2) (#3, +3)

Replicate between sites #1 and #2. DXRE replicates the IM_INV_MSD records. Replication-time triggers on IM_INV_MSD recalculate IM_INV.QTY_ON_HND at each site, based on the total IM_INV_MSD records.

IM_INV.QOH 3 3 3

IM_INV_MSD (#1, +1) (#2, +2) (#3, +3)

(#2, +2) (#1, +1)

Replicate between site #1 and #3. Again, DXRE replicates the IM_INV_MSD records and triggers recalculate the QOH value. Sites #1 and #3 now reflect changes to QOH from all sites.

IM_INV.QOH 6 3 6

IM_INV_MSD (#1, +1) (#2, +2) (#3, +3)

(#2, +2) (#1, +1) (#2, +2)

(#3, +3) (#1, +1)

Replicate between sites #1 and #2. Now all sites are in sync.

IM_INV.QOH 6 6 6

IM_INV_MSD (#1, +1) (#2, +2) (#3, +3)

(#2, +2) (#1, +1) (#2, +2)

(#3, +3) (#3, +3) (#1, +1)


Delta Update Tables and Triggers

= fires during processing in Counterpoint = fires during replication

Maintenance Add customers Edit customers Delete customers Transactions BAL UNPSTD_BAL ORD_BAL NO_OF_ORD LWY_BAL NO_OF_LWY

AR_CUST

What fragment changed? When did it change?

PDCAR_CUST

BAL UNPSTD_BAL ORD_BAL NO_OF_ORD LWY_BAL NO_OF_LWY

AR_CUST_MSD

What fragment changed? When did it change?

PDCAR_CUST_MSD

PDx_ARCUST trigger

TR_AR_CUST_xxx trigger

PDx_ARCUSTMSD trigger

TR_AR_CUST_xxx trigger

(run as pduser)

<trigger_name> trigger

<trigger_name> trigger


Delta Update Tables

Table Delta Columns

AR_CUST (Customers) BAL NO_OF_ORDS ORD_BAL LOY_PTS_BAL TOT_LOY_PTS_ADJ

UNPSTD_BAL LWY_BAL NO_OF_LWYS TOT_LOY_PTS_EARND TOT_LOY_PTS_RDM

IM_INV (Inventory) GL_VAL QTY_COMMIT QTY_ON_BO QTY_ON_HND QTY_ON_PO

QTY_ON_XFER_IN QTY_ON_XFER_OUT QTY_ON_ORD QTY_ON_LWY QTY_ON_SO

IM_INV_CELL

(Inventory Cell)

QTY_COMMIT QTY_ON_BO QTY_ON_HND QTY_ON_PO QTY_ON_XFER_IN

QTY_ON_XFER_OUT QTY_ON_ORD QTY_ON_LWY QTY_ON_SO

PO_RECVR_HIST

(Received PO History Header)

ADJ_CNT ADJ_MISC_AMT_1 ADJ_MISC_AMT_2 ADJ_MISC_AMT_3 ADJ_MISC_AMT_4 ADJ_MISC_AMT_5 ADJ_TOT_MISC ADJ_SUB_TOT ADJ_TOT

VCHR_MISC_AMT_1 VCHR_MISC_AMT_2 VCHR_MISC_AMT_3 VCHR_MISC_AMT_4 VCHR_MISC_AMT_5 VCHR_TOT_MISC VCHR_SUB_TOT VCHR_TOT

PO_RECVR_HIST_LIN

(Received PO History Lines)

ADJ_LIN_MISC_CHRG_1 ADJ_LIN_MISC_CHRG_2 ADJ_LIN_MISC_CHRG_3 ADJ_LIN_MISC_CHRG_4 ADJ_LIN_MISC_CHRG_5 ADJ_TOT_LIN_MISC_CHRG

ADJ_COST ADJ_EXT_COST ADJ_RECVD_COST ADJ_RECVD_EXT_COST ADJ_TOT_COST_CORR

PO_RTV_HIST

(RTV History Header)

VCHR_MISC_AMT_1 VCHR_MISC_AMT_2 VCHR_MISC_AMT_3 VCHR_MISC_AMT_4

VCHR_MISC_AMT_5 VCHR_TOT_MISC VCHR_SUB_TOT VCHR_TOT

SY_GFC (Gift Cards) CURR_AMT

SY_STC (Store Credits) CURR_AMT


Ways to Start Replication

1) Schedule replication 2) Manually run Multi-Site Configuration Editor 3) Manually run DataXtend Synchronizer 4) Manually run DataXtend Controller 2) Manually run Multi-Site Configuration Edtior.

Use this method to start replication between a remote server and the Hub server. The Hub server is always selected as the replication partner. Select Start / Programs / CounterPoint SQL / Utilities / Multi-Site / Multi-Site Configuration Editor. Switch to the Site Info tab. Select the remote server that will replicate with the Hub. Click Replicate Now to start the replication session.

3) Manually run the DataXtend Synchronizer.

Select Start / Programs / DataXtend /

Remote Edition / Synchronizer. Click to start replication.


The replication engine automatically determines the other site to replicate with, based on:

- highest average bandwidth with this site - subscription to same work set slices - number of elapsed days since last replication with this site

You can start the Synchronizer on a remote system, using remote control

software. 4) Manually run the DataXtend Controller. Select Start / Programs /

DataXtend / Remote Edition / Controller.

Select Initiate Replication from

the Actions menu. The data source name for the database at

this site displays as an "available database". This database will be one participant in the

replication. Click to start replication. With this method, the replication engine

determines the other site to replicate with, and is exactly the same as if you had run the DataXtend Synchronizer.

If you want to control which site to replicate

with, click instead.


A list of other Sites in the replication

network appears. Select the other site to replicate with, and

then click . Changes made since the last replication

session between the two sites are replicated.


Replication Partner Selection

DataXtend Replication Cycles determine who is selected Initiated by High availability sites (Remote Servers):

1. High-to-Complete Cycle

High-availability systems (Remote Servers) replicate with Complete systems (Hub) every time

Only exception is Resuscitation Cycle

2. Bandwidth Cycle

If multiple "Complete" systems, selects based on bandwidth Considers site only if previously used as partner (record in dSite)

3. Resuscitation Cycle

Prevents "cliques" from forming Replicates with previous partner if 5 days since last replication Change 5-day period using CHECKDEADSITES dsetting

parameter (see Appendix 3)

Initiated by Low availability sites (no Multi-Site systems have this):

1. Bandwidth Cycle

Selects site based on bandwidth and shared work set slices Considers site only if previously used as partner (record in dSite) Chooses as many sites as necessary to ensure that all of its own

data changes are replicated to at least one other site


Database Maintenance for Multi-Site

SQL Database Maintenance

Replication creates additional fragmentation on indexes

Rebuild indexes nightly to ensure good replication times

Maintenance tasks to perform on Hub and Remote servers: Backup the database at least nightly Rebuild indexes weekly or nightly Update statistics weekly or nightly

Must configure a Database Maintenance Task in Management Console for SQL maintenance tasks to complete successfully


Making a Site Unavailable Temporarily

To temporarily make a site unavailable for replication

Start the replication engine at the site to be made unavailable. Open the DXRE Controller

and select Available Databases from the Actions menu.

Ensure the available

database is highlighted and click .

Stop the replication engine

by typing pdre stop at a command prompt.

When you are ready to make the

site's database available again, ensure the unavailable database is highlighted and click

. Restart the replication engine by

typing pdre start at a command prompt.


Deactivating a Remote Database

To permanently remove a site's database from replication network

1. Finish processing and posting all transactions in Counterpoint at the site to be deactivated.

2. Initiate replication at the site to be deactivated. 3. Use View / Site information in the DataXtend Controller to ensure that the

replication session was successful. If necessary, correct any problems and replicate again.

4. At Hub, use the DataXtend Administrator to condemn the site (on the

Information tab). This removes the site from the replication network. 5. Initiate replication at the site to be deactivated, specifically selecting Hub as

the partner.

If the database will continue to be used outside of the replication network, at the

site to be removed:

6. At a command prompt, execute pdreset utility to remove the PDC control tables, system tables, and triggers from the database. Use the data source name for the remote database for DatabaseDSN.

pdreset /odbcn=pduser /odbcp=PDPassword8 DatabaseDSN

7. Execute drop procedure SQL command to drop the DataXtend stored

procedures from the database: drop procedure PDGetNextID, PDGetSiteID, PDisPDUser, PDisCompact

8. Execute drop function SQL command to drop the pduser.PDDecodeTime

function from the database: drop function pduser.PDDecodeTime

9. Execute msdropdelta.sql SQL script to drop the delta tables from the

database. 10. At a command prompt, switch to the \CounterPoint\Scripts folder and

execute duninst utility to remove the DataXtend DSN from the system. duninst DatabaseDSN


If the database will no longer be used, at the site to be removed:

11. At a command prompt, switch to the \CounterPoint\Scripts folder and execute duninst utility to remove the DataXtend DSN from the system.

duninst DatabaseDSN

12. Detach the database from the SQL Server. 13. Delete the physical database files (.mdf and .ldf).


Moving a Replicating Database – Hub

Moving a replicating database to a new Hub system On the old Hub server:

1. Stop the DataXtend replication service ("pdre stop" at command prompt)

2. Use MSSQL to do a full back up the Hub’s database.

3. Save a copy of the Counterpoint registration.ini for the server.

4. Save a copy of the Counterpoint Toplevel\<company> folder.

5. Save a copy of the Counterpoint CUSTOM folder (below CPSQL.1)

On the new Hub server:

6. Install MSSQL 2008 R2 or MSSQL 2012 on new Hub server.

7. Install Counterpoint prerequisites on new Hub server ("Hub server") so that DXRE installs.

8. Install clock synchronization software on new Hub server.

9. Copy the database backup to the new server and use MSSQL to restore it

10. Create the PDUSER account as a user in MSSQL Management Studio

o For server roles, enable only “public” o For user mapping, enable the restored database.

Set the user field to “pduser”, and manually type “pduser” for Default Schema Enable only “db_owner” and “public”

When saving the PDUSER account, click OK if you get a message that the user already exists.

11. Associate the new PDUSER account with the restored database by running this SQL command:

Use <restored_database_name> SP_change_users_login ‘auto_fix’, ‘pduser’


12. Manually activate the database by entering this command at a command prompt:

pdactivate /DA=MSSQL /ODBCN=pduser /ODBCP=PDPassword8 /RE /FO /SITEN=<NewHubSiteID> /DB=<SQLServerName:DatabaseName> /LOGF=c:\pdactivate.log /FI

13. If the new Hub server name has changed, use a SQL editor at each remote site to update the NetAddr column for SiteID 1000000 in the pduser.dsite table with the new computername of the Hub.

update pduser.dsite set NetAddr=<newcomputername> where SiteID=’1000000’

14. Use the DXRE Controller to manually force replication with all remote sites.

15. Install Counterpoint as a single-site server, including installing a service pack if necessary to match the version number used at remote sites.

16. Copy the Toplevel\<company> files below the Counterpoint instance folder (e.g., CPSQL.1) to the new Hub server

17. Copy the Counterpoint Registration.ini file to the Toplevel folder on the new server.

18. Copy the Custom folder to the Counterpoint instance folder on the new server.

Database type Reinstall an updated database

Force activation of a copy of an already-activated database

Denotes First Site (Hub) database


Moving a Replicating Database – Remote

Moving a replicating database to a new Remote system

1. Replicate with the Hub to ensure that all existing data has been successfully replicated.

2. Stop the DXRE service ("pdre stop" at command prompt) 3. Use MSSQL to do a full backup of the Remote server's database.

4. Save a copy of the Counterpoint registration.ini for the server.

5. Save a copy of the Counterpoint Toplevel\<company> folder.

6. Save a copy of the Counterpoint CUSTOM folder (below CPSQL.1)

7. On the Hub, use the DataXtend Administrator to condemn the old site.

8. On the old Remote system, execute duninst <DatabasePDDSN>. Step 7 & 8 deactivate the database and removes the old site from the replication

network. On the new system at the Remote site:

9. Install MSSQL 2008 R2.

10. Install the Counterpoint prerequisites ("remote server") so that DXRE gets installed. (Don't install Counterpoint yet.)

11. Restore the database from backup.

12. Re-associate the pduser login to the database on the new system by

executing this stored procedure in the SQL Script Utility or Query Editor: Exec sp_change_users_login 'auto_fix','pduser'

13. Execute pddsn to create a temporary DSN named "test".

pddsn /da=mssql /db=<computername>:<databasename> /odbcn=pduser

/odbcp=PDPassword8 test

14. Execute pdreset utility to remove the PDC control tables, system tables, and

triggers from the database. pdreset /odbcn=pduser /odbcp=PDPassword8 test


This step is required so that when the database is re-activated, it recreates

these tables and triggers with the correct site ID.

15. Execute drop procedure SQL command to drop the DataXtend stored procedures from the database:

drop procedure PDGetNextID, PDGetSiteID, PDisPDUser

16. Execute msdropdelta.sql script to drop the delta tables from the database.

17. Execute duninst to remove the temporary DSN. (If the database were still activated, duninst would also deactivate it.)

duninst test

18. On both the Hub and Remote servers, execute dsetting to automatically

resolve Type V conflicts between the Hub and Remote server.

dsetting <DatabaseDSN> PD_RESOLVE_TYPEV_CONFLICT Y

19. Install Counterpoint on the Remote server, selecting the role of Multi-Site

Remote server and choosing to use a pre-configured database.

20. On both the Hub and Remote servers, reverse the dsetting option that was applied.

dsetting <DatabaseDSN> PD_RESOLVE_TYPEV_CONFLICT N


Condemn vs Pdreset vs Duninst

Utility Description

condemn Deactivates database Removes site from replication network

To condemn, use DataXtend Administrator | Information tab.

Don't condemn if you plan to reactivate the database, so that it automatically uses the same GUIDs. (If you condemn and later reactivate database, new GUIDs are assigned. Use dreclid to reclaim GUIDs after condemning.)

Use when permanently removing database from replication network, or when moving database to a new server or workstation.

pdreset Deletes PDC control tables, system tables, and triggers from database

To run, execute from command prompt:

pdreset /odbcn=pduser /odbcp=PDPassword8 <DataSourceName>

Use when permanently removing database from replication network, when moving database to a new server, or when bringing the database back after correcting it on a different system.

duninst Deactivates database Removes ODBC data source name Removes DXRE registry keys

To run, execute from command prompt:

duninst <DataSourceName>

Does not affect data (PDC control tables, system tables, or triggers) in database, so it can be reactivated later.

Use when permanently removing database from replication network, when moving database to a new server workstation, or when bringing the database back after correcting it on a different system.

Multi-Site Training Manual DXRE Troubleshooting

SECTION 5: DXRE TROUBLESHOOTING

Monitoring Replication ................................................................................1 Data Xtend Site Monitor .............................................................................2 DataXtend Logs ..........................................................................................4 Replication Logs .........................................................................................5 Reading a Replication Engine Log ..................................................6 Key Segments of Replication Engine Log .......................................7 Configuring Replication Engine Logs ..............................................9 Troubleshooting Tools .............................................................................. 10 Overview: Identifying and Resolving Errors ............................................. 12 Exercise 10: Server Rename .................................................................... 14 Identifying and Resolving Errors ............................................................... 15 Types of Errors ............................................................................. 15 Resolving Duplicate Primary Key Errors ....................................... 19 Exercise 11: Duplicate Primary Key ......................................................... 21 Resolving Duplicate Primary Key Errors Example .................................... 22 Exercise 12: Duplicate Primary Key ......................................................... 25

Gift Card and Store Credit Problems ........................................................ 26 Most Common Problems and Avoiding Them .......................................... 27 Other Replication Problems ...................................................................... 29 Database Changes Not Replicated .............................................. 29 When to Use pdfixcutoff ........................................................................... 30

Multi-Site Training Manual DXRE Troubleshooting

Multi-Site Training Manual 5-1 DXRE Troubleshooting

Monitoring Replication

Monitor at all sites daily via Site Information or Replication Summary

Site Information Select Start | Programs | DataXtend | Remote Edition | Controller. Select View / Site

Information

Shows replication

information for each site used as a replication partner with this site.

Watch for a "Last

Attempted…" date that is later than "Last Successful…" date.

Replication Summary in Counterpoint From the Counterpoint menu, select System / Views / Replication Summary. Shows replication

information for each site used as a replication partner with this site.

Watch for a "Status" of

Check log files.


DataXtend Site Monitor

Use to obtain information about the replication network Site information Replication Partner information Replication Session information Select Start | Programs | DataXtend | Remote Edition | Site Monitor.

Select to open the database.

Enter the connection information. Site information appears initially. Use View on the menu bar to look at other information. Use File / Export to File to export data to a comma-delimited file


DataXtend Site Monitor

Replication Partner Information Replication Session Information


DataXtend Logs

Type of Log Log Name Location

Replication Details of replication session

rsla0000#s01.log rsla0000#s02.log …

Program Files \ Progress \ DataXtend \ logs \ Engine To view: Start \ Programs \ DataXtend \

Remote Edition \ Replication Engine Logs

Use Action/Options in DataXtend Controller to configure logs

Administrator Record of activity using Administrator

da.log da.lo2 …

Program Files \ Progress \ DataXtend \ logs To view: Start \ Programs \ DataXtend \

Remote Edition \ Administrator Log

Designer Record of activity using Designer

prd.log prd.lo2 …

Program Files \ Progress \ DataXtend \ logs

Use View/Preferences (Logging tab) in DataXtend Designer to configure logs

PDActivate Record of database activation

pdactivate.log pdactivate.lo2 or pdupgrade.log …

C:\


Replication Logs

For each replication session, replication engine logs show:

Events that occurred during replication at local and partner sites

Problems that caused replication to fail

Problems that could potentially cause future replication to fail

Tables updated and not updated since the previous replication session

Table cutoff dates

Oldest fragment found in each table

Total number of records updated, inserted, and deleted Located in C:\ Program Files \ Progress \ DataXtend \ logs \ Engine View using Start | Programs | DataXtend | Remote Edition | Replication Engine Logs New log created each time replication engine starts or a single log reaches the

maximum log size

Names like rsla00010s01.log rsl = replication engine log a = ASCII format ("b" = binary) 00010 = instance of replication engine running, since installation

s01 = sequence number of log within same replication session

rsla00001s01.log = log from first use of the replication engine

rsla00001s02.log = second log from first use of engine; first log from same session has reached maximum size

rsla00002s01.log = replication engine has been stopped and restarted (new session)


Reading a Replication Engine Log

1. Message Type Type of message: I = Information about events on a per table basis W = Warning about potential problem that doesn't cause

replication to fail E = Error message about problem that caused replication to fail D = Debug message used for debugging purposes S = Setting message A = Audit message C = Conflict message (data conflicts) 2. Thread ID Unique identifier for thread (replication session with particular partner) 3. DateTime Date and time at which message was written to log (in format

mm:dd-hh:mm:ss); shown in UTC 4. Message Qualifier Qualifies the type of message for specific log entry. CONFLICT = Data conflict (message type "C") ODBC = ODBC error AUDIT = audit information (message type "A") SEVT = session event message (middle pane messages) SMSG = session message (lower pane messages) 5. Message Actual text of message

1 2 3 5

4


Key Segments of Replication Engine Log

Version of the Replication Engine and date/time the log file was created

DataXtend RE Replication Engine Version 8.2.0.0 Feb 16 2010 for Win32/Intel

Log file started: 7/10/2013 1:54:54 PM

Initiation of a replication session D 0f3c 0710-14:23:38 dses8028 Accepting incoming session...

I 0f3c 0710-14:23:38 internal DListener 011BA6B8 has accepted incoming session from

EAST-STORE (192.168.1.102) on socket 620

D 0f3c 0710-14:23:38 dcmn41007 Thread started [id:0000047C]

I 0f3c 0710-14:23:38 dses2017 SEVT 128214: NewSession(1): 0

I 0f3c 0710-14:23:38 dses2013 SMSG: Session 128214 started ()

Information about each thread, including site ID, site name, session ID, and database to be replicated

D 047c 0710-14:23:38 dcmn41000 DThread::Execute calling Run()

D 047c 0710-14:23:38 dses17002 DSessionManager::Run start (_pSession=05AEB518)

D 047c 0710-14:23:38 dses23000 Session Replication Session (0): Using zLib Compression

D 047c 0710-14:23:38 dses1001 Session Replication Session (0): Using Triple DES Encryption

D 047c 0710-14:23:38 dses6001 DJobManager: Added job "Repl Recv" (#128214).

S 047c 0710-14:23:39 dcmn1 Setting PARTNER_IP_ADDRESS=remote1

D 047c 0710-14:23:39 pdre22036 DREH:Entering INIT

S 047c 0710-14:23:39 dcmn1 Setting PARTNER_SITE_ID=1000001

D 047c 0710-14:23:39 dom 35011 New connection to PD29BZ1O001 created.

S 047c 0710-14:23:39 dcmn1 Setting LOCAL_SITE_ID=1000000

S 047c 0710-14:23:39 dcmn1 Setting LOCAL_SITE_NAME=Main Store

S 047c 0710-14:23:39 dcmn1 Setting CURRENT_SESSION_ID=128214

S 047c 0710-14:23:39 dcmn1 Setting CURRENT_DATABASE_NAME=PD29BZ1O001

Replication session begins

I 047c 0710-14:23:39 dses2015 SMSG: (pdre,22042)-Attempting replication on network

29LCWR. Local database is CounterPoint (MultiSite) - PD29BZ1O001

I 047c 0710-14:23:39 pdre22043 Session 128214: Attempting replication on network 29LCWR.

Local database is CounterPoint (MultiSite) - PD29BZ1O001

Establish a connection with other site to perform replication

D 047c 0710-14:23:39 pdre22048 Handshake: receiver: tStart = 07/10/2013 19:23:39

D 047c 0710-14:23:39 GetPartnerID() = 1000001

D 047c 0710-14:23:39 dbName = PD29BZ1O001

Last successful replication with partner

I 047c 0710-14:23:39 pdre66021 Current replication history record for partner site East

Store(00LFLT):

I 047c 0710-14:23:39 7/10/2013 5:38:30 PM How far back the Replication Engine will look for changes to be replicated to the site

D 047c 0710-14:23:40 internal Thread 47C(Replication history for partner 00LFLT)

released lock on PD29BZ1O001.dActHist

D 047c 0710-14:23:40 dom 2013 Committing transaction for database PD29BZ1O001(04A9CD80).

D 047c 0710-14:23:40 pdre66046 Fuzziness for window of consideration: 604 seconds


Identifies local site, partner site, and cutoff date/time used in replication session. (Cutoff

= how far back replication engine will look for updates; before negotiation = global cutoff date; negotiated cutoff = specific cutoff for each table)

D 047c 0710-14:23:40 pdre34063 Local site: Main Store HUB(00LFLS)

D 047c 0710-14:23:40 Partner site: East Store remote1(00LFLT)

D 047c 0710-14:23:40 Reference time: 7/10/2013 7:23:39 PM(UTC)

D 047c 0710-14:23:40 7/10/2013 2:23:39 PM(local)

D 047c 0710-14:23:40 Drift: 2

D 047c 0710-14:23:40 Cutoff: 7/10/2013 5:28:26 PM (before negotiation)

Identifies tables that have not changed since the previous replication session.

I 047c 0710-14:23:40 pdre81061 Quick scan of SY_WORKSTATION indicated no changes

A 047c 0710-14:23:40 pdre34081 AUDIT: 154 tables have no changes and will not be replicated

For each table, determines the timestamp of the oldest fragment

I 047c 0710-14:23:42 pdre66034 Oldest fragment found during replication of table SYCOMP with

site East Store(00LFLT) was timestamped 7/10/2013 7:23:39 PM

For each table, identifies table that was replicated, number of bytes sent and received, amount of time replication of table took.

A 1050 1030-07:30:05 pdre34217 AUDIT TSET IM_ADJ_TRX: Xmit: 0 bytes, Recv: 0 bytes

A 1050 1030-07:30:05 Time: 0.047s (0 Mb/min)

For each table, identifies number of records sent to partner, and number of records updated, inserted, and deleted from local database.

A 047c 0710-14:23:42 pdre34218 AUDIT SY_COMP: Xmit: 0 bytes, Recv: 0 bytes

A 047c 0710-14:23:42 Time: 0.016s (0 Mb/min)

Indicates replication session has completed. Identifies total number of bytes transmitted, time of session, total number of records updated, inserted, or deleted in local database, and oldest fragment.

A 0444 0630-12:39:03 pdre34315 AUDIT TOTAL: Xmit: 558 bytes, Recv: 334 bytes

A 0444 0630-12:39:03 Time: 6.204s (0.00862669 Mb/min)

A 0444 0630-12:39:03 SessionID: 2711

A 0444 0630-12:39:03 pdre34316 AUDIT TOTAL: 7 keys sent, 4 records sent

A 0444 0630-12:39:03 pdre34317 AUDIT TOTAL: 3 records updated, 0 inserted, 0 deleted

D 0444 0630-12:39:03 pdre34318 PerfAudit Total: DL:0ms, UL:0ms, RL:0ms, CL:0ms

I 0444 0630-12:39:03 dses2015 SMSG: (pdre,34320)-Replication of PD29BZ1P001 with

REMOTE2(00LFLU) has ended successfully with 3 conflicts resolved

I 0444 0630-12:39:03 dses2015 SMSG: (pdre,34321)-PD29BZ1P001 replication statistics: 558/334

bytes sent/recv'd in 6.204s

D 0444 0630-12:39:03 dses2016 SMSG 2711: (pdre,34180)-Updating link history

I 0444 0630-12:39:03 pdre66057 Oldest fragment found during replication with site

REMOTE2(00LFLU) was timestamped 6/30/2005 5:36:18 PM


Configuring Replication Engine Logs

To configure amount of detail to show in logs, size of log files, and disk space allocated to logs

Configuration is site-specific

Select Start | Programs |

DataXtend | Remote

Edition | Controller. Then select Actions |

Options. By default, all logging options except "Verbose"

are enabled. Disable "Debug" option for normal operations

unless a problem needs to be researched (results in very large logs).

In the future, you may be requested to enable the

"Debug" and "Verbose" options to assist with troubleshooting.

Default settings are shown here.

Max Log Size (10M) In a single session, when a log grows to 10MB, create a new log. For example, when rsla00010s01.log reaches 10MB, a new file rsla00010s02.log is created.

Total Log Size (50M) All replication logs from all sessions can only occupy up to 50MB disk space before logs are removed.

Max Number of Old Files (100) Maximum number of logs to keep prior to current session's logs.

Max Age for Old Files (14) Maximum number of days to keep logs prior to current session's logs.


Troubleshooting Tools

You will need access to several tools as you troubleshoot and resolve problems

in the replication network. Obtain the access during the setup process, in advance of needing it. SQL Script Utility You will need to enter SQL commands to resolve certain

types of replication errors. You can use the SQL Script Utility at sites where MS Management Studio isn't installed. However, the SQL Script Utility will be installed only on a server and only on a workstation if Utilities were installed.

If you neglected to install the database utilities on a

workstation, you can do so later by navigating to the CPSQL.1 folder on the workstation's server and running ClientSetup.exe. Select to install just the Utilities.

pduser password You will need to correct certain data conflicts by entering

SQL commands logged in as "pduser". Be sure that you know the pduser's password (if no changes have been made, "PDPassword8" is set as the default).

Counterpoint login You may need to run Counterpoint to research and/or

resolve data conflicts. Be sure that you have a Counterpoint user ID (and password) that provides access to the full menu in Counterpoint.

Stop new users Use "Pause" in SQL Server to prevent users from logging in from logging in to Counterpoint while you are waiting for other users to exit

the software so that you can correct data errors. To pause an SQL Server, from SQL Management Studio,

right-click the server name and select "Pause".


Prevent replication You may want to stop replication from occurring while you are troubleshooting and correcting data errors.

Ways to temporarily stop replication:

In the Controller, select Actions | Available Databases. Highlight the database

and click

At the site where you want to suspend replication, type pdre stop at a command prompt.

To re-enable replication, type pdre start at a command

prompt.


Overview: Identifying and Resolving Errors

Step 1. Scan the status of replication at each site.

Use View | Site Information in the Controller to check for unsynchronized

Last Attempted and Successful Replication date/time

or

Use System / Views / Replication Summary in Counterpoint to look for

"Check log files" message

If problems appear, look at the session's replication log (step 2).

If no problems appear, you may still want to look at the replication log to see

what conflicts were automatically resolved by the replication engine.

Step 2. Obtain the error message and replication logs for the session.

Use Start / Programs / DataXtend / Remote Edition / Site Monitor and select

View / Session Info. Details of each replication session are shown.

Scan the Error column in each row for errors. Make note of the error, as well as

the replication log names for the session (shown in StartLog and EndLog to the

left on the same row).

Step 3. Open the replication log with a text editor.

Replication logs are text files that are located in Program Files \ Progress \

DataXtend \ logs \ Engine.

You can quickly move to that folder

by selecting Replication Engine

Logs from the DataXtend/Remote

Edition program group.

Search for "E 0", matching the case and searching from the

bottom going up. This will show all errors that caused the

particular replication session to fail.

Search for " C 0" if you would like to see conflicts encountered by the replication

engine. Usually, they will be followed by warning messages ("W") indicating that

the replication engine has automatically resolved the data conflict.


Step 4. Correct cause of the error.

The method used to correct an error will vary, depending on the type of error.

The exercises you'll be performing will illustrate some possible errors and how to

correct them.

You can also refer to the descriptions on the following pages for some common

types of errors, how to correct them if they do occur, and how to prevent them

from occurring again.

Step 5. Recover

Anytime replication is interrupted by an error, you can recover by simply

replicating again after the cause of the error is corrected and the Replication

Engine will pick up where it left off.

You can choose to manually initiate replication or wait for the next scheduled

replication to occur.


Exercise 10: Server Rename

Try it Yourself!

In this exercise, you will begin learning how to troubleshoot replication errors.

You will start by renaming a server that is already part of the replication network, which will result in replication errors. You will then complete each of the necessary steps to resolve the error so that replication is again successful.



Identifying and Resolving Errors

Types of errors

Duplicate Primary Key Attempting to insert a new record when one with the same primary key (cust #, item #, etc.) already exists

To correct: Pick the "winning" site, enter queries to remove incorrect data at "losing" site, and replicate again (see example on following pages).

To prevent: Ensure use of unique values for workgroups, batches, etc. Also, users should not log into a workgroup associated with a site different than the actual site at which they are working.

Refer to Appendix 4 for details on how to configure Counterpoint to avoid duplicate primary key errors.

E 080c 0317-10:14:20 ODBC Error -1: (23000) '[Microsoft][ODBC SQL Server Driver][SQL

Server]Violation of PRIMARY KEY constraint 'PK_AR_CUST'. Cannot insert duplicate key in object

'AR_CUST'.' <2627,SQLExecute>

E 080c 0317-10:14:20 ODBC Error -1: (01000) '[Microsoft][ODBC SQL Server Driver][SQL

Server]The statement has been terminated.' <3621,SQLExecute>

E 080c 0317-10:14:20 ODBC statement failed: -1 from function Execute

E 080c 0317-10:14:20 ODBC statement: INSERT INTO "dbo"."AR_CUST"

("CUST_NO","ADRS_1","ADRS_2","ADRS_3","CITY","CNTRY","STATE","ZIP_COD","FST_NAM","FST_NAM_UPR"

,"LST_NAM","LST_NAM_UPR","NAM","NAM_UPR","SALUTATION","CONTCT_1","EMAIL_ADRS_1","FAX_1","PHONE

_1","URL_1","CONTCT_2",

...

... E 080c 0317-10:14:20 Unable to insert new record into table AR_CUST having key:

PDCID(1000003),"MARILYN"

E 080c 0317-10:14:20 FSM:{An ODBC error occurred}: Unable to store next PD29BZ1P002.AR_CUST

record from partner's data list (key:PDCID(1000003))

D 080c 0317-10:14:20 Released lock on table AR_CUST

I 080c 0317-10:14:20 SMSG: (pdre,33236)-Update of AR_CUST in CounterPoint (MultiSite) -

PD29BZ1P002 failed

E 080c 0317-10:14:20 Update of AR_CUST in CounterPoint (MultiSite) - PD29BZ1P002 failed

E 080c 0317-10:14:20 An error occurred in the sync session envelope.

W 080c 0317-10:14:20 Rolling back uncommitted transactions

D 080c 0317-10:14:20 Rolling back transaction for database PD29BZ1P002

I 080c 0317-10:14:20 SMSG: (pdre,33209)-PD29BZ1P002 replication has ended because of an error

- check log for details


Clock Mismatch System time at the sites attempting to replicate is different by more than 10 minutes (besides time zone difference)

To correct: Use Dping to check the time of a remote system: dping /timec <hostname or IP address>. The time zone setting on the 2 sites may be incorrect. Check the system date under Windows to verify this. After synchronizing clocks, replicate again. (May need to restart Replication service after synchronizing clocks.)

To prevent: Use clock synchronization software on all replicating systems

Type 1 Conflict Same fragment updated by multiple sites

To correct: DXRE automatically resolves by using newest fragment

To prevent: (Not applicable)

E 08ac 0427-13:46:18 dsessbas 567 An error occurred in the handshake envelope.

E 08ac 0427-13:46:18 drehand 2030 CLOCK MISMATCH: This site's clock disagrees with the partner

K817(1)'s clock by more than 600 seconds. Please correct the clock which is in error.

This site: 04/27/2004 18:46:18

Difference: 1002

Partner site: 04/27/2004 19:03:00

W 0bbc 0317-09:37:16 CONFLICT: Type I: Fragment 2 for table IM_ITEM has been altered at both sites

(key: PDCID(1000009))

W 0bbc 0317-09:37:16 CONFLICT: Type I: Fragment 20 for table IM_ITEM has been altered at both sites

(key: PDCID(1000009))

D 0bbc 0317-09:37:16 RecoverUnused() has found nothing to recover... resetting the transfer buffer

D 0bbc 0317-09:37:16 Committing transaction for database PD29BZ1P002.

I 0bbc 0317-09:37:16 Local field IM_ITEM.DESCR in conflict with partner value

I 0bbc 0317-09:37:16 Local: Green fee - 18 holes

I 0bbc 0317-09:37:16 Partner: Green fee - 18 holes Jen

I 0bbc 0317-09:37:16 Local field IM_ITEM.DESCR_UPR in conflict with partner value

I 0bbc 0317-09:37:16 Local: GREEN FEE - 18 HOLES

I 0bbc 0317-09:37:16 Partner: GREEN FEE - 18 HOLES JEN

W 0bbc 0317-09:37:16 CONFLICT: Type I: Fragment DESCR for table IM_ITEM has been altered at both

sites (key: PDCID(1000009))

W 0bbc 0317-09:37:16 Type I conflict resolved - fragment DESCR will be updated at partner (Table

IM_ITEM, key: PDCID(1000009))

I 0bbc 0317-09:37:16 Local field IM_ITEM.LST_MAINT_USR_ID in conflict with partner value

I 0bbc 0317-09:37:16 Local: JEN

I 0bbc 0317-09:37:16 Partner: Z

W 0bbc 0317-09:37:16 CONFLICT: Type I: Fragment LSTMNT for table IM_ITEM has been altered at both

sites (key: PDCID(1000009))

W 0bbc 0317-09:37:16 Type I conflict resolved - fragment LSTMNT will be updated at partner (Table

IM_ITEM, key: PDCID(1000009))


Type 1A Conflict Same fragment updated with same data by multiple sites

To correct: DXRE automatically resolves by updating timestamp to most current, if time difference is large enough


Type V Conflict Data already exists in database at remote site when database is activated and initial replication occurs with Hub Site.

To correct: Set "dsetting <DSNName> PD_RESOLVE_TYPEV_CONFLICT Y" on remote system and manually initiate replication from that site to Hub Site. Hub Site's data will "win".

Another alternative is to totally remove the starter data from tables at remote system, using SQL command "Truncate table <table_name>". Remove data from the PDC table first and then the user table.

To prevent: Ensure that no data exists in any table at a remote site when initially activating a database.

W 0474 0308-08:21:15 CONFLICT: Possible Type Ia: Fragment 5 for table dSite has been altered at

both sites (possibly to same value) (key: 1000002)

D 0474 0308-08:21:15 RecoverUnused() has found nothing to recover... resetting the transfer buffer

I 0474 0308-08:21:15 No field differences found in fragment 5 of table dSite

W 0e90 0317-16:32:37 CONFLICT: Type V: Starter data fragment 2 for table IM_CTL is different at

both sites (key: 1)

D 0e90 0317-16:32:37 RecoverUnused() has found nothing to recover... resetting the transfer buffer

I 0e90 0317-16:32:37 Local field IM_CTL.AUTO_ADD_INV_METH in conflict with partner value

I 0e90 0317-16:32:37 Local: !

I 0e90 0317-16:32:37 Partner: *

I 0e90 0317-16:32:37 Local field IM_CTL.LST_MAINT_DT in conflict with partner value

I 0e90 0317-16:32:37 Local: 3/3/2005 1:24:23 PM

I 0e90 0317-16:32:37 Partner: 3/17/2005 4:21:37 PM

W 0e90 0317-16:32:37 CONFLICT: Type V: Starter data in fragment F1 for table IM_CTL is different

at the two sites - conflict must be resolved manually (key: 1)

D 0e90 0317-16:32:37 Acquired lock on table IM_CTL

D 0e90 0317-16:32:37 Committing transaction for database PD29BZ1P001.

D 0e90 0317-16:32:37 Released lock on table IM_CTL

I 0e90 0317-16:32:38 SMSG: (pdre,33092)-Unresolvable conflicts found while replicating

CounterPoint (MultiSite) - PD29BZ1P001

E 0e90 0317-16:32:38 Unresolvable conflicts found while replicating CounterPoint (MultiSite) -

PD29BZ1P001


Type VI Conflict Record inserted or updated by one site and same record deleted by partner site

To correct: DXRE automatically resolves in one of two ways: If the record is inserted or all fragments were updated by one site, DXRE automatically resolves by using the most recent operation (the insert/update or the deletion). If only some fragments were updated, the delete operation must always "win".


Unable to contact partner site

Port 242 is not open on partner site, or is not open for this site's IP address

To correct: Did site's IP address change? If XP SP2 been installed, disable firewall or allow access from specific IP address.


W 0a84 0317-12:35:54 CONFLICT: Type VI: A locally-deleted record in table PS_DRW_CLS has been

updated at the partner site (key: PDCID(1000001)[PS_DRW_CLS]MAIN,JEN,VISA)

Creation date:3/17/2005 5:57:03 PM

Deletion date:3/17/2005 6:35:21 PM

The record will be deleted at the partner site.

D 010c 0317-12:44:42 Network error during connect: No error (netAddr=mcostello).

W 010c 0317-12:44:42 Partner did not respond.

D 010c 0317-12:44:42 SMSG 9: Partner did not respond

I 010c 0317-12:44:42 SMSG: Partner did not respond

D 010c 0317-12:44:42 Network error for outbound session: No error.

E 010c 0317-12:44:42 Session error 2: The connection was refused by the partner. The partner

machine may be temporarily busy, or may be receiving many simultaneous connection requests.

E 010c 0317-12:44:42 The remote site refused the connection, or was not listening.

D 010c 0317-12:44:42 SMSG 9: Session error 2: The connection was refused by the partner.

The partner machine may be temporarily busy, or may be receiving many simultaneous

connection requests.


Resolving Duplicate Primary Key Errors

Decide who "loses"

This is the site at which you will need to delete the duplicate records.

In general, Hub Site's database should "win". Base your decision on the overall impact of correcting the data:

Record type - part of a transaction set? - does table have related MSD table?

Has additional processing been done? Are there also associated transactions?

In the case of a duplicate customer number, if there is also an unposted ticket for that customer, it will be less work if the site with the unposted ticket "wins".

There is no specific method to help determine if there are other

associated records. In the case of a duplicate customer or item, you can attempt to delete the duplicate customer or item first. If there are other records associated with it, you will receive a foreign key error message that shows the names of the tables that contain the associated records.

Has Hub already replicated to other sites? If the same record was added by the Hub Site and a Remote, has the

record already been replicated by the Hub to other remote sites? It may take less time to delete the duplicate record (and any associated records) from the Remote's database.



Correct the data

If data needs to be removed from multiple tables, delete in proper order (enforced by foreign keys)

If needed, use Counterpoint to add a new record to replace record to be deleted

- replacement record will be replicated

Use SQL Management Studio to delete records

- login as pduser so that deletion doesn't replicate

- to remove*: delete from <tablename> where <columnname>='<value>'

- also delete associated PDC record *If the same primary key was used for two different records:

- before removing records, use SQL Management Studio to update foreign keys in dependent records to point to "new" parent


Exercise 11: Duplicate Primary Key

Try it Yourself!

In this exercise, you will continue learning how to troubleshoot replication errors.

You will create a "duplicate primary key" error by adding the same customer at the Hub and remote site. You will then complete each of the necessary steps to resolve the error so that replication is again successful.




Example: Duplicate customer number

Step 1. Use System / Views /

Replication Summary at each site to check replication status.

Step 2. If Status shows "Check

log files", use Start / Programs / DataXtend / Remote Edition / Site

Monitor to get error message and name of log file.

Step 3. Browse to Program Files \ Progress \ DataXtend \ logs \ Engine. Open the replication log with a text editor and search bottom-to-top for "E 0" messages.

W 0854 0325-14:59:18 Optimized insert of AR_CUST record PDCID(1000000) failed, will retry

E 0854 0325-14:59:18 ODBC Error -1: (23000) '[Microsoft][ODBC SQL Server Driver][SQL

Server]Violation of PRIMARY KEY constraint 'PK_AR_CUST'. Cannot insert duplicate key in

object 'AR_CUST'.' <2627,SQLExecute>

E 0854 0325-14:59:18 ODBC Error -1: (01000) '[Microsoft][ODBC SQL Server Driver][SQL

Server]The statement has been terminated.' <3621,SQLExecute>

E 0854 0325-14:59:18 ODBC statement failed: -1 from function Execute

E 0854 0325-14:59:18 ODBC statement: INSERT INTO "dbo"."AR_CUST"

("CUST_NO","ADRS_1","ADRS_2","ADRS_3","CITY","CNTRY","STATE","ZIP_COD","FST_NAM","FST_NAM_UP

R","LST_NAM","LST_NAM_UPR","NAM","NAM_UPR","SALUTATION","CONTCT_1","EMAIL_ADRS_1","FAX_1","P

HONE_1","URL_1","CONTCT_2","EMAIL_ADRS_2","FAX_2","PHONE_2","URL_2","CR_CARD_EXP_DAT_1","CR_

CARD_NAM_1","CR_CARD_NO_1","CR_CARD_PAY_COD_1","CR_LIM","CR_RATE","MAX_CHK_AMT","NO_CR_LIM",

"NO_MAX_CHK_AMT","ALLOW_AR_CHRG","AR_ACCT_NO","BAL_METH","STMNT_COD","TERMS_COD","TAX_EXEMPT

_DAT","TAX_EXEMPT_NO","LST_AGE_AS_OF_DAT","LST_AGE_BAL","LST_AGE_BAL_1","LST_AGE_BAL_2","LST

_AGE_BAL_2_5","LST_AGE_BAL_3","LST_AGE_BAL_3_5","LST_AGE_BAL_4","LST_AGE_BAL_4_5","LST_AGE_B

AL_5","LST_AGE_BAL_OPN","LST_AGE_CUTOFF_DAT","LST_AGE_DAT","LST_AGE_EVENT_NO","LST_AGE_FUTR_

DOCS","LST_AGE_MAX_PRD_1","LST_AGE_MAX_PRD_2","LST_AGE_MAX_PRD_3","LST_AGE_MAX_PRD_4","LST_A

GE_METH","LST_AGE_NON_STD","LST_AGE_NO_CUTOFF","LST_AGE_NO_OF_PRDS","LST_AGE_PAST_CUTOFF","L

ST_STMNT_BAL","LST_STMNT_BAL_1","LST_STMNT_BAL_2","LST_STMNT_BAL_2_5","LST_STMNT_BAL_3","LST

_STMNT_BAL_3_5","LST_STMNT_BAL_4","LST_STMNT_BAL_4_5","LST_STMNT_BAL_5","LST_STMNT_BAL_OPN",

"LST_STMNT_BEG_DAT","LST_STMNT_DAT","LST_STMNT_END_DAT","LST_STMNT_MAX_PRD_1","LST_STMNT_MAX

_PRD_2","LST_STMNT_MAX_PRD_3","LST_STMNT_MAX_PRD_4","LST_STMNT_METH","LST_STMNT_NO_OF_PRDS",

"LST_STMNT_PAST_CTOFF","FST_SAL_DAT","LST_SAL_AMT","LST_SAL_DAT","LST_PMT_AMT","LST_PMT_DAT"

,"PROF_ALPHA_1","PROF_ALPHA_2","PROF_ALPHA_3","PROF_ALPHA_4","PROF_ALPHA_5","PROF_COD_1","PR

OF_COD_2","PROF_COD_3","PROF_COD_4","PROF_COD_5","PROF_DAT_1","PROF_DAT_2","PROF_DAT_3","PRO

F_DAT_4","PROF_DAT_5","PROF_NO_1","PROF_NO_2","PROF_NO_3","PROF_NO_4","PROF_NO_5","ALLOW_ORD

S","ALLOW_TKTS","USE_ORD_SHIP_TO","CATEG_COD","COMMNT","CUST_TYP","DFLT_SHIP_ADRS_ID","PROMP

T_NAM_ADRS","SHIP_VIA_COD","SHIP_ZONE_COD","TAX_COD","STR_ID","SLS_REP","LST_MAINT_DT","LST_

MAINT_USR_ID","WRK_STMNT_ACTIV","USE_LWY_SHIP_TO","ALLOW_LWYS") VALUES

(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?

,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)

. . .

. . .

E 0854 0325-14:59:18 Unable to insert new record into table AR_CUST having key:

PDCID(1000000),"1004"

E 0854 0325-14:59:18 FSM:{An ODBC error occurred}: Unable to store next PD29BZ1P002.AR_CUST

record from partner's data list (key:PDCID(1000000))

D 0854 0325-14:59:18 Released lock on table AR_CUST

I 0854 0325-14:59:18 SMSG: (pdre,33236)-Update of AR_CUST in CounterPoint (MultiSite) -

PD29BZ1P002 failed

E 0854 0325-14:59:18 Update of AR_CUST in CounterPoint (MultiSite) - PD29BZ1P002 failed


Step 4. Pick a "loser" and correct cause of the error. Picking a loser In this example, two sites have added the same customer number (1004).

You must decide whether to remove customer 1004 from the Hub Site database or from the Remote database.

At this point, you do not know if either site also created additional records (such

as transactions or ship-to addresses) for this customer so follow the rule of "Hub Site's database wins".

On the Remote system, open the Query Editor (if MSSQL is installed there) or

the SQL Script Utility. Be sure to login as pduser so that the deletion does not get replicated, and enter the following command:

delete from AR_CUST where CUST_NO='1004'

If associated records exist for the

customer, a foreign key violation error will appear and show the other table(s) that contain the associated records.

In this case, there are also records in

AR_SHIP_ADRS for this customer. You could perform the same tests on the

Hub Site system to determine which site's database will be easier to correct.

You should also check to see if the customer and their ship-to addresses added by the Hub have been replicated yet to other remote servers. The customer added to the Hub Site system has two ship-to addresses that were entered.

After investigating, you determine that the Hub’s customer record with its two

ship-to addresses has been replicated to other remote sites. In this case, you will make the change to the data on the Remote server.

Correcting the cause of the error Customer number 1004 on the Remote server needs to be removed, but it

cannot be deleted until the ship-to address record is deleted. You will also need to set up the new customer again (with a different customer number) and re-enter the ship-to address.


Here are the steps:

A. On the Remote server, start Counterpoint and use Customers / Customers to add the new customer and their ship-to address again.

To avoid encountering the same problem again, be sure that you log in with

the appropriate workgroup and select to auto-assign the customer number.

B. Log in to either the Management Studio or SQL Script Utility as pduser (to prevent these changes from replicating) and select to work with your database.

Delete the shipping address record first, removing it from the PDC control

table and the user table. delete from PDCAR_SHIP_ADRS where CCUST_NO='1004'

delete from AR_SHIP_ADRS where CUST_NO='1004 Then delete the incorrect customer record from the PDC control table and

user table. delete from PDCAR_CUST where CCUST_NO='1004'

delete from AR_CUST where CUST_NO='1004'

Step 5. Recover To recover, simply replicate again. You can manually replicate or wait until the

next scheduled replication.


Exercise 12: Duplicate Primary Key

Try it Yourself!

In this exercise, you will learn how to troubleshoot another duplicate primary key error, this time for two different item records that were created with the same item number.

You will create the "duplicate primary key" error by adding two different items at the Hub and remote site where each uses the same item number. You will then complete each of the necessary steps to resolve the error so that replication is again successful.



Gift Card and Store Credit Problems

Sharing Gift Cards or Store Credits across stores To avoid problems:

Use unique series of gift card and store credit numbers in each workgroup and require auto-assign

Restrict Point of Sale users to a specific workgroup Replicate frequently

Problems you're trying to avoid: Two sites create the same gift card or store credit number This will produce a Duplicate Primary Key conflict during replication, and

you will have to correct it by using SQL commands to change the number in one site's data.

Two sites update/redeem the same gift card or store credit number If two sites redeem the same gift card or store credit between replication

sessions, when they do replicate, the "latest" redemption will automatically be used.

Example: MAIN store redeems gift card #123 for $25.00 at 1:00 pm.

EAST store redeems gift card #123 for $25.00 at 1:40 pm. Replication between two sites occurs at 2:00 pm. Replication

engine 'sees' redemption at EAST store as most current activity and automatically resolves the conflict by using it.

Results: - Gift card #123 reflects as fully redeemed, but not over-redeemed by $25.00.

- Pay code history shows both redemptions. - Ticket history shows both redemptions. - Distributions have been updated for both redemptions.


Most Common Problems and Avoiding Them

1. Create all items and inventory records at one site and let them replicate to other sites.

This avoids Duplicate Primary Key errors when replicating.

2. Look at replication logs frequently and deal with “E 0” errors as soon as they occur.

Also monitor for “E 1”, “E 2”, and “E 3”.

3. Restrict the site ID in each Counterpoint workgroup.

This will prevent someone from logging into the wrong workgroup and using the same ticket numbers as the ‘real’ store, which will cause Duplicate Primary Key errors when replicating.

4. Follow the instructions when deploying Multi-Site.

Shortcuts will cause problems that are not easy to find and may well cause you to have to start back over from the beginning.

5. When making major changes to data (such as changing account numbers), stop replication between all sites until you’re done. Then only allow replication to one site at a time, and check each site before you continue with the next. This way, if you do run into a problem, you can correct it on that server rather than on all servers.

6. If you use any function that employs SQL bulk inserts or DTS fast loads (such as the Data Migration utility in Counterpoint), be sure to run DMEND immediately afterwards before any of that data is changed.

Syntax: DMEND <DSNName> [Optional:<TableName>]

Triggers do not fire when bulk inserts or fast load is done, which means that PDC control records are not created or updated, and the data will not replicate.


7. Deploy the exact same replication rules file to all sites.

Be sure to copy the contents (excluding registration.hub) of the CUSTOM folder from the Hub to the CUSTOM folder on each Remote server. That way, you’re sure that the databases on each server are activated using the same replication rules.


Other Replication Problems

Database changes not replicated Potential causes:

Triggers fired out of sequence

If you have added a custom table and written a trigger to update it or another table, your trigger should fire before the DXRE trigger.

Changes occurred within "window of consideration"

If you replicate shortly after updating data, you may be replicating within the "window of consideration". This is the amount of time that must elapse between the data change and replication. By default, this is 10 minutes. If you replicate less than 10 minutes after making a change, the change will not replicate. You can reduce (or increase) the window of consideration by changing the CLOCKTOLERANCE parameter with the dsetting utility.

Site is not subscribed to work set that contains the changed record (e.g., SY_EVENT)

If a remote site creates data for a work set to which it is not subscribed, the data will not be replicated. (Normally, it would be impossible for a site to create data if it is not subscribed to the corresponding work set.)

Changes were made outside of Counterpoint such that triggers did not fire

Certain SQL operations bypass database triggers, including:

- "Bulk insert" operations - DTS mass inserts, which use "Bulk inserts". (Disable Use fast load

in DTS.) - Truncate table operation - Primary key change - MSSQL backup/restore operations

Views and Stored Procedures are not replicated

These are schema changes. Put them in the CUSTOM directory on each server and then run the Activate or Update Database utility to deploy them.

Anything done as pduser


When to Use pdfixcutoff

Use to view cutoff times for a specific PDC table

Use to change cutoff time to “roll back” last replication date/time for a specific PDC table

Background Specific table cutoff date/times are stored in dActHist table in each local server’s database, and dates/times are encoded.

During replication, sites compare cutoffs and the older of the two is used to determine the PDC1 dates that will qualify for replication.

To view cutoff dates in the local server’s database: pdfixcutoff /USERN=Admin /USERP=password –QUERY /P=partnersiteID

/TA=PS_TKT_HIST_LIN PD29BZ1O001

Leave off /P variable to see cutoff dates for all sites.

Leave off /TA variable to see cutoff dates for all tables.

Data source name can be found in the ODBC Administrator, and will usually resemble PD29BZ1O001.

To update the cutoff time for a table: pdfixcutoff /USERN=Admin /USERP=password /P=1000001

/TA=PS_TKT_HIST_LIN PD29BZ1O001 "1979-12-31 00:00:00"

Site ID of partner to

which data will go

Data Source name New cutoff time; date shown here

sets to initial replication date/time,

resulting in full replication of table

Table name Data Source name

of local database

Table name

Course Evaluation

Course Name Training Date

Trainer Your Name (optional)

Ranking

Please use the following rankings to complete this evaluation:

1 = Unacceptable, 2 = Did Not Meet My Needs, 3 = Meets My Needs, 4 = Exceeded My Expectations

Registration

1. It was easy to enroll in this course. 1 2 3 4

Facilities

2. The workspace available was appropriate for the subject matter being taught. 1 2 3 4

3. The room was set up effectively for the curriculum – if PC’s were supplied, they were loaded with the relevant software.

1 2 3 4

Materials

4. Manual content was appropriate to the subject being taught. 1 2 3 4

5. The format of the manual was easy to understand. 1 2 3 4

Experience

6. The course prerequisites were clearly stated & appropriate to the topic. 1 2 3 4

7. The practice activities complemented the course. 1 2 3 4

8. The time allotted for the course was adequate. 1 2 3 4

9. I was given an opportunity to contribute during discussions. 1 2 3 4

10. What were your expectations for attending this course?

_______________________________________________________________________________________

11. Were your expectations met? Yes No

If yes, how were they met?

_______________________________________________________________________________________

If no, why not?

_______________________________________________________________________________________

Instructor

12. The instructor was prepared. 1 2 3 4

13. The instructor was knowledgeable about the course content. 1 2 3 4

14. The instructor encouraged questions from participants. 1 2 3 4

15. The instructor covered the course objectives. 1 2 3 4

16. What is your overall rating of this Instructor? 1 2 3 4

Comments

17. The best thing about this course was:

______________________________________________________________________________________

18. This course could be improved by:

_______________________________________________________________________________________

19. Another course that I would like offered is:

_______________________________________________________________________________________

20. I would attend another course offered by Retail Training? Yes No

If yes, why?

_______________________________________________________________________________________

If no, why not?

_______________________________________________________________________________________

Thank you for completing this evaluation!

Multi-Site Appendix 1: DataXtend System Tables

Appendix 1: DataXtend System Tables

Contain information needed to manage replication environment Some are replicated and others remain local

Created when site is activated

Table Name Use

dActHist Contains info about last successful replication time and oldest fragment replicated for each table for each partner site. (Table is not replicated.)

Used to calculate replication cutoff time (how far back in time the replication engine will look for updates to the database)

dActSite Contains work set subscription information for subscribed sites

dException Contains all exceptions for all tables

dIDB GUID information for each table at each site. (Table is not replicated.)

dQueue Contains commands that will be executed during replication. Records are deleted as they are processed. (Table is not replicated.)

dSched Contains replication schedule definitions

dSet Contains local and global replication settings (dsetting parameters)

dSite Contains one record for each activated site in the replication network, including the average bandwidth for each site. Base table of the dSite work set.

dSiteLnk One record per partner site containing information about historical replication sessions. (Table is not replicated.)

Source of data for System / Views / Replication Summary function in Counterpoint.

dSiteSet Contains site-specific settings for the last time site was successfully replicated and version of replication engine

Multi-Site Appendix 1: DataXtend System Tables

Multi-Site Appendix 2: Replication Engine Utilities

Appendix 2: Replication Engine Utilities

Use to maintain operation of replication sites

All utilities located in Program Files / Progress / DataXtend / bin at each site

Command line entry

Add “/h” for help with possible parameters for any command

Utility Description

ddumptbl Outputs data in selected table. Decrypts timestamp fields in system tables.

dexpid Before permanently deactivating a site, to export the GUID block that was assigned to the site. GUID block can subsequently be reclaimed with dimpid utility.

dimpid To re-use GUID block previously exported with dexpid utility

dimprule Imports replication rules into database, creates system and control tables in the database, loads system data records, and generates control table records for all application tables

dinst Partners enabled database with replication engine at a site, creates data source name, and performs initial replication if engine is running

dmend Creates missing PDC records, based on records in application table. Records could be missing due to use of DTS fast load, or logging in as pduser when updating application tables, both resulting in application table triggers not firing.

Run after using Counterpoint’s Data Migration or Database Import utilities. (Not necessary after running Data Interchange>Database Import) Contact Support before running for any other reason.

dnareport Produces report about replication engine configuration

dping Checks network connection to target replication engine

dreclid Reclaim missing GUIDs if site is condemned without first exporting GUID block; perform only on Hub server

dregevnt Registers a .dll or .so, used for custom event handling

dresetdb After restoring older database, to reset available GUIDs to avoid introducing duplicates

dsetting Configure settings (site-specific or global) that control behavior of the replication engine when it runs

See list of dsetting parameters in Appendix 3 of this manual.

dtrigger Generates and loads replication engine triggers into database

Multi-Site Appendix 2: Replication Engine Utilities

Utility Description

duninst Deactivates a database at a site, making it unavailable for replication. Removes DSN for database. (Data remains and database can be reactivated later.)

Use at each site if you need to update schema or import new replication rules in a replicating database. Reactivate at each site when completed, using pdactivate.

pdactivate Activates database at a site. Imports replication rules, activates site, and applies replication engine triggers to database.

pdchgpw Change password associated with pduser

pddbstat Make a site's database available, unavailable, or just list it

pddsn Adds, deletes, and lists ODBC data sources. Typically used when migrating to new hardware with same name/IP address as old hardware

pdfixcutoff View/update cutoff date in PDC Control table for specified site and/or table. Typically used to force missed data to replicate by moving the cutoff time back to precede the date/time in the PDC record

pdhorizon Control cleanup of obsolete system and control table records, and determine site and network horizon. Typically used to query why delete records have not been cleaned up.

pdre Install, uninstall, start, restart, and stop replication engine remotely

pdrepl Replicates the specified data source

pdreset Deletes system and control tables and replication triggers from database. Typically used after a site has been condemned and removed from replication network.

pdscanlog Scans replication logs in Program Files / Progress / DataXtend / logs / Engine for error messages. Produces scanlist.pd, listing logs with errors, and copies logs with errors to HoldArea folder.

pdschedadm Manages replication schedule

pdupgrade Upgrades replication rules associated with a database

pdwaitfor Specifies the length of time the replication engine should wait before starting a replication session

regbackup Backs up replication engine's registry. Registry backup can be restored to migrate activated database to a new hardware platform or to rebuild a failed system.

regrestore Restores replication engine's registry from file

replcmd Replicates the specified database

Multi-Site Appendix 3: dsetting Utility

Appendix 3: dsetting Utility

Use to alter configuration settings that change how replication engine works at run-time

Execute at command prompt

Syntax: dsetting <DSNName> [<parameter> [<value>] ] [/siteID=<siteID>] [/clear] <DSNName> is the DataXtend data source name for the database. If <parameter> not specified, displays current values for all parameters. If <value> not specified, displays current value for parameter. Specify /siteID=<siteID> to alter or display a site-specific setting.

(For <siteID>, enter 'local' for the local site or a site ID in base 36.) Specify /clear to remove a setting's value.

Parameter Description

AUTOCOMMIT Forces replication engine to commit every update immediately

CHECKDEADSITES Number of days replication engine waits before contacting a site that has not been replicated in the specified number of days.

Default = 5

CLOCKTOLERANCE How far apart clocks on replicating systems can be, from 1 to 3600 seconds. If difference between clocks on systems is greater than this setting, replication will not occur.

Default = 600 (10 minutes)

CONTINUEIFNEWER Will replication continue if a new update is detected in local database since processing of the table began?

Default = Y (If new update is detected, replication continues but update won't replicate until next session)

CLEANUPACTIVE Whether to remove obsolete records from PD control tables (for records that were previously deleted from master table) and system tables. Answer Y to enable removal of obsolete records for the previous network horizons. Setting can only be modified with pdhorizon utility.

Default = Y (cleanup runs during replication and cleans out obsolete records from system and PD control tables for records that have been obsolete at least 90 days prior to the current network horizon).

LOCKTIMEOUT Number of seconds to wait for lock to be obtained before timing out, after which replication session will end.

Default = (not set)

Multi-Site Appendix 3: dsetting Utility

Parameter Description

MAXPUSHBACKLIMIT How far back in days the replication engine looks for updates to be replicated, to prevent cutoff dates from being too old. Limits how far back cutoff dates can be pushed (due to an old update). Updates with timestamps older than this value result in rollback of the transaction and replication stops.

Default = 0 (no limit)

MAXTRANSACTIONSIZE Maximum number of updates to process before committing to database. Ignored when processing tables in a transaction set.

Default = 0 (DXRE automatically determines when to commit)

MINIMALTABLELOCKING Can tables be replicated in parallel during a replication session? Major performance enhancement by doing so, but could cause deadlock situation in some conditions.

Default = Y

MUSTROLLFORWARDAGE Number of minutes after which cutoff date is rolled forward. Value of 0 means update immediately.

Default = 1440 minutes (1 day)

PD_REPL_PRIORITY Priority of each replication thread, either "Idle", "Low," "Normal," or "High".

Default = Normal

PD_REPL_QUOTA Maximum time, in seconds, to allocate to a replication session and maximum number of bytes that can be transmitted

Default = 0,0 (no time or byte limits)

PD_RESOLVE_TYPEV_

CONFLICT

Whether to automatically resolve Type V conflicts by allowing replication engine to select data from the complete site over an incomplete site.

Default = N

QUERYCACHESIZE Amount of disk cache to allocate to replication queries, between 50000 and 10000000.

Default = 100000 (Counterpoint scripts set to 10000000)

REPLBUFSIZE Size of the data transmission packets used during replication, between 50000 and 10000000.

Default = 100000

REPLICATEUNCHANGED

TABLES

Should unchanged tables be replicated, either "1" or "0"?

Default = 0 (do not replicate if unchanged)

Multi-Site Appendix 4: Avoiding Replication Errors

Appendix 4: Avoiding Replication Errors

You can reduce replication errors by configuring your Counterpoint data properly, and by observing certain guidelines in your use of the software.

This appendix provides the data configuration settings and "best practices" that

help avoid the errors. A blank Site Chart is also provided to assist with recording the setup information for each site.

Data Configuration

Menu Selection Recommended Settings

Setup / System / Company For Gift cards and Store credits, clear the Valid at any store check box. (If you must allow them to be used at any store, set up a manual procedure to permit each gift card and store credit to be used only once.)

Do not use the Set up batches button to create DEFAULT batches.

Setup / System / Users Assign each user to the workgroup for that user's site

Clear the Allow other workgroups check box.

For a user who works at different sites, create an additional user for each site and assign the workgroup for the site.

Click the Set up batches button to create user-specific batches. (Or you can choose to use Workgroup batches, for a single batch per workgroup/site.)

Assign a security code whose menu code either restricts or provides access to the menu selections shown below in Restricted Menu Selections. Access to the restricted selections should be provided only to specific users at a single site.

Setup / System / Workgroups Define a separate workgroup for each site, with the appropriate location and store for the site.

Assign each site to a different workgroup when the site registers with the Hub server.

Click the Set up batches button to create workgroup-specific batches (rather than user-specific batches).

Assign unique series of values to the Next numbers for each workgroup, and select to Always auto-assign each number.

At the Hub, after all remote databases are activated, assign the Hub to its own workgroup and restrict the site ID.

Setup / System / Menu Codes Define a menu code that provides access to the menu selections shown below in Restricted Menu Selections.

Define additional menu codes that do not provide access to the restricted menu selections.

Setup / System / Security Codes

Assign the menu code that provides access to the restricted menu selections to a single security code.

Assign menu codes that do not provide access to restricted selections to other security codes.

Clear the Allow other locations and Allow other stores check boxes for all security codes.


Menu Selection Recommended Settings

Setup / Point of Sale / Stores If you select to assign document numbers from the store, assign unique series of values to the Next document numbers for each store and select to Always auto-assign each number.

Clear the Allow access to other stores' orders check box.

Setup / Point of Sale / Stations

If you selected for a store to assign document numbers from the station, assign unique series of values to the Next document numbers for each station and select to Always

auto-assign each number.

For Offline Ticket Entry, assign unique series of values to the Next document numbers for each station. Use a prefix such as "OFF" to ensure that offline numbers and non-offline numbers do not overlap. Also select to Always auto-assign the numbers.

Restricted Menu Selections Make these menu selections available only at a single site, to avoid data conflicts

during replication. System / Gift Cards / Maintain Gift Cards System / Store Credits / Maintain Store Credits Inventory / Prices / Contract Prices Inventory / Prices / Promotional Prices Inventory / Prices / Special Prices Inventory / Prices / Planned Promotions Customers / Utilities / Maintain A/R Documents Customers / Utilities / Reapply A/R Documents Setup / xxxxxx / Control (all Control functions) Setup / System / Company Setup / System / Tax Codes System / Utilities / Database Import


Best Practices to Avoid Replication Errors Logging in When logging in, restrict a user to the workgroup associated with

the site where the login occurs. This can be done by disallowing other workgroups in workstation

configuration (Setup / System / Workstations) or by restricting the site ID in each workgroup (Setup / System / Workgroups).

Posting If unposted transactions replicate to another site, it is important to prevent them from being posted at the other sites.

This can be achieved by using user-specific batch IDs and by

clearing the Allow other locations and Allow other stores check boxes in the security codes assigned to users. An additional safeguard would be to subscribe each site to only its own location and store history work set slices.

Deletions Deleting or purging items, customers, account numbers can cause replication errors at other sites if the other sites still have open activity for those records.

You can minimize these errors by deleting or purging only after a

successful replication session, and then replicating again right after deleting or purging the records.

Inserting or Avoid adding, deleting or purging large amounts of data at the Deleting same time. This can result in a “replication storm” at your sites and

severely impact performance. Instead, add or delete in chunks over a few days to spread the load out over a longer time period.

Renumbering You can safely renumber items, customers, and vendors using the Counterpoint renumbering utilities. If your own business practices allow it, it is also safe to allow multiple sites to use these utilities – as long as they don't renumber the same item, customer, or vendor.

Be aware that if you develop your own scripts to change/renumber

a primary key, the change will not be replicated. In order for the change to be replicated, your script must delete the original record and insert a new record.

Item Merges Item or Customer merges can only be done on the Hub system. Customer Merges Before merging, replicate first and then merge. Immediately after

merging, replicate again. This ensures that no new data is introduced at a remote site while the merge is occurring.


Gift Cards If you find it necessary to allow gift cards and/or store credits Store Credits to be redeemed at any store in the replication network, consider

replicating frequently during the day. Physical Create physical count transactions at the Hub and let them Count replicate to the remote sites. (Do not create the transactions at the

remote sites.) Enter or import the counts at the remote sites, but do not post the

count transactions. Allow the count transactions to replicate back to the Hub which is

where they should be posted. CPOnline All CPOnline operations (publishing and importing) should be

performed only at a single site. Backups It is important to do regularly scheduled database backups. In

addition to backing up the database itself, also backup the DXRE installation folder (C:\Program Files\Progress\DataXtend, by default) and the DXRE registry entries (using RegBackup.exe).


Blank Site Chart

Print and complete this chart for each site in your replication network.

DXRE site name:

Location:

Store:

Stations:

Next document number:

Next hold ID:

Next quote number:

Next order number:

Next layaway number:

From: Station Store

Station Store

Station Store

Station Store

Station Store

Workgroup:

Next item number:

Next customer #:

Next vendor number:

Next purchase request #:

Next PO number:

Next receiver #:

Next RTV #:

Next transfer #:

Next gift card number:

Next store credit number:

Next event number:

Next barcode:

Next A/R doc #:

Users:

Batches:

Drawers:

Offline Ticket Entry:

Next document number (Offline):

Next hold ID (Offline):

Next quote number (Offline):

Next order number (Offline):

Next layaway number (Offline):

Next store credit number (Offline):

Next gift card number (Offline):

Next customer number (Offline):

Yes No


Multi-Site Appendix 5: Customizing Counterpoint

Appendix 5: Customizing Counterpoint

If you add custom tables or columns to Counterpoint, the schema changes need

to be applied to each database in the replication network. To accomplish this, you will need to produce custom alter scripts that make the

schema changes, and you will need to create custom replication rules to ensure that data in the new tables and columns is replicated. This work will need to be done on a development system that is not part of the replication network.

The custom alter scripts and replication rules can be deployed to all servers and

workstations after the database is initially created and activated, or later when installing a new release or service pack of Counterpoint.

Follow these steps to set up the development system to produce the custom

scripts and replication rules. (Refer to MultiSite.pdf in the Counterpoint PDF Library for details on each step.)

1. Set up the development system.

a) Install MSSQL if the database you will use for development exceeds 4 GB. b) Create the pduser database login (public and db_owner permissions). c) Create C:\CUSTOM and copy Registration.hub to it, renaming it to

Registration.ini. d) Install Counterpoint prerequisites, including SQL Server Express if the

development database is smaller than 4 GB. e) Install Counterpoint, selecting the role of Primary server (not a Hub) and

choose to either create a new database or to use a pre-configured database. For a pre-configured database, prior to installing Counterpoint:

- attach database - set connection string - associate pduser login with MSSQL/MSDE/SSE on development System (sp_change_users_login ‘auto_fix’, ‘pduser’) - if necessary, apply current UpdateFrom8.3.x script to database If pre-configured database was already activated on "live" system: - create a temporary DSN on development system - execute pdreset to remove PDC control tables and triggers - remove temporary DSN f) Install the current Counterpoint service pack. g) Install DataXtend Studio.

2. Import standard replication rules to create PDC control tables, and apply msdelta.sql to create Counterpoint delta tables. Make a backup of the database after performing this step.

Multi-Site Appendix 5: Customizing Counterpoint

3. Build an alter script that includes all schema changes and apply it to the development database until no errors are encountered.

4. Start the DataXtend Designer to produce custom replication rules.

a) Enable replication for custom tables b) Add custom columns to fragments c) Enable delta tracking for custom columns (optional) d) Assign custom tables to work sets (optional) e) Define foreign keys (optional) f) Export replication rules g) Export script (text file) of replication rules (optional)

5. Deploy the alter script and custom replication rules.

a) Copy alter script and custom replication rules to CUSTOM folder on Hub and each Remote server (Program Files \ Radiant Systems \ CounterPoint \

CPSQL.1\CUSTOM) b) On the Hub and each Remote server, execute the Activate or Update

Database utility. c) If any server manages Offline Ticket Entry workstations, also execute the

Provision Database utility (Start / Programs / CounterPoint SQL / Utilities / Provision Database) to re-provision the server’s database. Then use the Management Console and select Rebuild POS to deploy the schema changes to the offline workstation databases.

Multi-Site Appendix 6: Changing the CPServices Port

Appendix 6: Changing the CPServices Port

To change the port assigned for CPServices on a server

1. On the server, select Start / CounterPoint SQL / Utilities / Configure Local

Services.

2. Click the name under Service (there will usually only be one service in the list)

3. Enter the port number that you want CPServices to use and enable the Restart service? check box.

Click OK when done to restart CPServices and apply your change.

Multi-Site Appendix 6: Changing the CPServices Port

Multi-Site 1 Glossary

Glossary

Auto-subscribing Subscribing to all slices of a work set, including new ones created at any

site.

Base Table A table in which each record uniquely identifies a work set slice or transaction

set slice. All other tables in the work set or transaction set are Dependent Tables.

Complete Site A site that has been designated a complete database is auto-subscribed to

all work sets in the database. A complete database contains all of the data in the network and automatically receives any new slices that are created.

Control Table Each replicated table in the database has a control table associated with it.

Control table names begin with "PDC". Control tables store a record for each record

in its corresponding user table and contain associated information, such as the creation date of the record and any transaction set slice and work set slice

information that could be associated with the record. Creating a control table for

each replicated table means that you do not have to make any changes to your existing tables in order to enable replication with the Replication Engine.

Duplicate Key Message that appears when trying to insert a new record in a table when a record with the same primary key already exists.

Fragment The unit of replication, a set of non-primary-key fields in the same record that

should always change together. Every record fragment in the database is uniquely

identified by its table name and record key.

Foreign Key (FK) A single column or combination of columns used to link data between

two tables, to prevent deletion of a record from a table if it is used or referred to in a different table.

Globally Unique ID (GUID) A record ID that is guaranteed to be unique throughout your entire Replication Network, even if some sites create many new records in the same

table between replications. There are 2.1 billion GUIDs allocated to each table.

Partner Site selected for replication.

PD DSN ODBC DSN value assigned at activation time to the database at a site (e.g.,

PD29BZ1P001). Can be seen in the ODBC Administrator, as well as in the

PD_LOCAL_DSN column of the pduser.dCnf table.

Pduser A special user defined specifically for replication that skips firing the delete,

update, or insert triggers when data is updated in a user table. Since the triggers don't fire that would update the associated control tables, changes made as "pduser"

are not replicated.

PD Control Identifier (PDCID) In many Control tables, each record is identified with a

control identifier which is a GUID. For records with PDCID values, the PDCID value is used to determine whether a record already exists when during inserts.


Project A project represents an application database enabled for replication. You can define

many projects as you enable different databases. A project can contain a number of Replication Networks and releases.

Release A release is an attribute of a project or Replication Network that is used to represent each change to your database's replication rules. It is not necessary to

define a new release when updates are made to replication rules. The Replication Engine will not enable databases with non-identical rules to replicate together. Each

project or Replication Network will have one or more releases.

Replication Log Log generated at each site during replication, showing all replication

session information.

Site One activated copy of the database containing all or any part of the data in the

Replication Network. A site can be: • A computer with its own local database • A

local database shared by a local area network • A large client/server database used by hundreds or thousands of users. Each local database is one site regardless of the

number of users accessing it, or the amount of data stored in it.

Site ID GUID value assigned to each replicating site at the time a database is activated at

the site. Hub Site is assigned ID 1000000 (1 million) and each site activated after is assigned an ID that increments by 1 (e.g., 1000001, 1000002, etc.).

Slice A specific row (or record) in a base table and all dependent rows from other tables in a work set or transaction set. For example, in a Counterpoint database, a single

Store's record and its associated Drawer records would constitute a slice.

Sparse Table In the replication rules, control tables are defined to be either "sparse" or

"non-sparse". A control table can be sparse only if it is not part of a work set or

transaction set, or if it has no 'child' tables in a work set or transaction set. When duplicate primary keys are detected for a Sparse table, the Replication Engine

automatically resolves the conflict by using the most current record.

Subscription A request for a slice of data. When subscribing to a new slice the slice’s data

is fully replicated to your site.

Work Set Grouping of common tables, arranged by store or location, that permit parts of

the data ("slices") to be replicated.

Transaction Set Transaction sets are defined in the same way as work sets. A transaction

set must have a base table along with a number of dependent tables. During replication, changes to related records within the defined transaction set are

transmitted and applied to the partner site's database as a single transaction. This transaction is committed in its entirety, or rolled back if an error occurs. For

example, making the Purchase Order Header and Purchase Order Line tables part of

a transaction set would ensure that no site could receive a purchase order header record without its related line item records.

Trigger A special class of stored procedure defined to execute automatically when a record is inserted, deleted, or updated in a table or view. In Counterpoint, triggers are used

to update the corresponding control table when a record is added, updated, or

deleted in a user table.

User Table Counterpoint database tables for a company


Work Set A connected set of related tables rooted at a base table. Each base record in the

base table identifies a slice of the database that sites can request or "subscribe to". When a site subscribes to a record in the base table of a work set, this tells the

Replication Engine that the site is interested in all dependent records. Related

information in all related tables in the work set will be pulled in during the next replication session.


Specialty Retail

6060 Primacy Parkway, Suite 460 � Memphis, TN 38119

(800) 852-5852 � www.CounterPointPOS.com