Multi-Site. for CounterPoint SQL

Transcription

1 Agenda General Information Multi-Site for CounterPoint SQL Table of Contents For Your Information: Overview of class format and training materials Section 1. Overview What are Command Line Deployment and the DataXtend Replication Engine (DXRE)? Discussion of the CounterPoint SQL environment where Command Line Deployment and DXRE would be used, the hardware and sofware requirements, and how licensing and registration of the products are handled. Section 2. Command Line Deployment The terminology and workings of Command Line Deployment, discussion of CounterPoint packages and Deployment Tasks, how to build the Deployment Parameter file, and how to use Deployment Tasks to distribute CounterPoint SQL and other components to all of the systems in your replication network. Section 3. Other Deployment Activities Other things you will use Command Line Deployment to do: install CounterPoint service packs, update to a new CounterPoint version, update your CounterPoint registration, install customizations, 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. Multi-Site

2 Table of Contents Section 6. Appendixes DataXtend System Tables, Replication Engine Utilities, dsetting Utility, Avoiding Replication Errors, Resolving Duplicate Ticket Numbers, Customizing CounterPoint SQL, Changing the Rad Sync Port Section 7. Glossary Terms used in Command Line Deployment and DXRE Exercise Handbook Exercises that illustrate Command Line Deployment and DXRE concepts presented in class Multi-Site

3 SECTION 1: OVERVIEW What are Command Line Deployment and DXRE?...1 Example Multi-Site Configuration...2 Hardware and Software Requirements...3 Licensing and Registration...4 Exercise 1: Configuring the Systems...6 Multi-Site Overview

4 Multi-Site Overview

5 What are Command Line Deployment and DXRE? Command Line Deployment Batch files delivered with CounterPoint SQL Used to distribute and install: Software Scripts Registration files Dictionary changes Customized reports and forms Database schema change scripts Electronic documentation DXRE DataXtend Replication Engine Synchronizes data changes between multiple CounterPoint SQL databases Bi-directional across TCP/IP networks Additional Components Administrator Controller Designer Site Monitor Command line utilities Schedule replication sessions and subscribe sites to data "work sets" (or use Radiant Management Console) Monitor and manage replication sessions, licenses, and site availability Define custom replication rules Part of the DataXtend Studio Display information about replication network partners and sessions Perform administrative and configuration tasks from a command prompt Multi-Site 1-1 Overview

6 Example Multi-Site Configuration First Site Server MS Hub CounterPoint programs & full data Options: MS & Hub (optional) Offline V2 DXRE Radiant Synchronization Service Workstation 1 CounterPoint programs Workstation 2 - Offline CounterPoint programs & (partial) data RadSync High-speed connection Remote Server 1 CounterPoint programs & (partial) data Options: MS (optional) Offline V2 DXRE RadSync Remote Server 2 CounterPoint programs & (partial) data Options: MS (optional) Offline V2 DXRE RadSync Workstation 1 CounterPoint programs Workstation 2 - Offline CounterPoint programs & data (partial) RadSync Workstation 3 - Offline CounterPoint programs & data (partial) RadSync Workstation 1 - Offline CounterPoint programs & (partial) data RadSync Workstation 2 CounterPoint programs Multi-Site 1-2 Overview

7 Hardware and Software Requirements First Site Server Function Primary CounterPoint SQL server (Hub server in MS environment) Required for Multi-Site or Offline Ticket Entry CounterPoint SQL Options: Multi-Site and Hub Offline V2 optional plus others, as desired Hardware and Software Requirements Windows XP Pro*/2003 Server 2 GHz Pentium 4 or better 2 GB memory Internet Explorer 6.0 or later MDAC 2.8 or later MSSQL 2005 with SP2: Standard or Enterprise Edition Named Pipes and TCP/IP with static IP/ network address or DNS-resolvable host name Disable Shared Memory protocol Internet connection Clock synchronization software DXRE: High-availability.NET Framework 1.1 Open port 242 Remote Server Function CounterPoint SQL server at remote location (MS environment) Can also be used a workstation CounterPoint SQL Options: Multi-Site Offline V2 optional Hardware and Software Requirements Windows XP Pro*/2003 Server 2 GHz Pentium 4 or better 2 GB memory Internet Explorer 6.0 or later MDAC 2.8 or later MSSQL or SSE 2005 with SP2 Named Pipes and TCP/IP with static IP/ network address or DNS-resolvable host name Disable Shared Memory protocol Internet connection Clock synchronization software DXRE: High-availability.NET Framework 1.1 Open port 242 * For XP Pro, if network is configured as a workgroup (rather than as a domain), enable Windows networking and disable Simple File Sharing. Multi-Site 1-3 Overview

8 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 SQL registration file, generate and install permanent licenses for DXRE and DataXtend Studio. To create permanent licenses, start CounterPoint SQL at the First Site 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.) Multi-Site 1-4 Overview

9 DataXtend Licenses DXRE License PDLicense.PNL 30-day license automatically installed when DXRE is installed Create permanent DXRE license on First Site Server using Setup / System / Registration if CounterPoint Code type is "Permanent" Creates license file in CounterPoint / Scripts To install permanent DXRE license, on First Site 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 First Site Server using Setup / System / Registration if PDLFXR.PDL CounterPoint Code type is "Temporary" or "Permanent" Creates license file in CounterPoint / 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 Multi-Site 1-5 Overview

10 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 create the Deployment Packages, build the Deployment Parameter file, and use Deployment tasks to install CounterPoint SQL and enable replication across the systems. The FirstSite system has its own monitor, mouse, and keyboard. The other two systems, Remote1 and Offline1, share one monitor, mouse, and keyboard with a KVM switch that will allow you to control which computer is active on the monitor and mouse/keyboard. Name Role KVM Switch # Remote1 Offline1 Remote Server also used as a workstation Offline Workstation connected to Remote1 1 2 You will not perform any work on the Offline1 system in the Multi-Site class. It is part of this configuration so that it will be available for the Offline V2 class which follows the Multi-Site class. In the first exercise, you will pre-configure the servers. Perform Exercise 1 in the Multi-Site/Offline Exercise Handbook. You'll be ready to begin Section 2 in this training manual when finished. Multi-Site 1-6 Overview

11 SECTION 2: COMMAND LINE DEPLOYMENT Deployment Basics...1 How Command Line Deployment Works...2 Pre-defined CounterPoint Packages...3 CounterPoint Deployment Tasks...5 CounterPoint Server Tasks...6 CounterPoint Workstation Tasks...7 Example Diagnostics Log...8 Using UpdateTopLevel.exe...9 Did the Task Complete? Task Log...11 Did the Task Complete? Database Activation Log...12 Building the Deployment Parameter File...13 Using the Deployment File Editor...16 Deployment Parameters: First Site...17 Deployment Parameters: Remote Server/Workstation...18 Deployment Parameters: Remote Server/non-Workstation...19 Deployment Parameters: Offline V1 Workstation...20 Deployment Parameters: Non-offline Workstation...21 Deployment Parameters: Special Notes...22 What Parameters does Each Server Task/Batch File Use?...24 What Parameters does Each Workstation Task/Batch File Use?...26 Exercise 2: Configuring Deployment of CounterPoint SQL...27 Exercise 3: Deploying CounterPoint SQL...28 Radiant Synchronization Service & Management Console...29 Installing Radiant Synchronization Service...30 Exercise 4: Deploying Radiant Synchronization Service...31 Multi-Site Command Line Deployment

12 Multi-Site Command Line Deployment

13 Deployment Basics Terminology Managed Computer Deployment Package Deployment Parameter File (Deployment.ini) Deployment Tasks Deployment Scripts Any computer in a Multi-Site environment Includes First Site Server (the Hub) and Remote Servers, as well as any workstation where you will use deployment tasks to enable CounterPoint for online use Set of files distributed to managed computers Two pre-defined packages maintained on First Site Server: ServerFiles WorkstationFiles Contains separate deployment parameters for each managed computer in the Multi-Site network. Parameters are used by deployment task scripts. Build using the Deployment File Editor Pre-defined batch files, installed with CounterPoint, that execute deployment scripts Use to deploy files from a package on a server, and to perform other operations Scripts (written in Perl) that install specific package files and perform other related tasks, based on settings for each managed computer in the Deployment Parameter file. Deployment Package files Deployment Task Deployment Script Deployment Parameters for computer Multi-Site 2-1 Command Line Deployment

14 How Command Line Deployment Works 1. You create and maintain packages on the First Site Server. 2. You use Deployment Editor on the First Site Server to create parameters in the Deployment Parameter file for each managed computer. 3. You copy the ServerFiles package from the First Site Server to each Remote Server. 4. You copy the WorkstationFiles package from the First Site Server to each server that will be used as a workstation, and to any workstation where deployment task will be run to install CounterPoint. 5. You run the desired deployment task at a command prompt on each server or on each workstation. First Site Server ❸ ❶ ServerFiles package WorkstationFiles package ❹ ❺ ❷ InstallServer.bat Deployment Parameter file Remote Server Offline V1 Workstation ServerFiles package LAN WorkstationFiles package WorkstationFiles package ❺ InstallServer.bat InstallWorkstation.bat ❺ InstallWorkstation.bat Multi-Site 2-2 Command Line Deployment

15 Pre-defined CounterPoint Packages Package = list of files and folders Two pre-defined packages supplied with CounterPoint ServerFiles WorkstationFiles Install Deployment Packages on First Site Server from CounterPoint DVD (CounterPoint SQL Enterprise / Multi-Site / Deployment Packages) Multi-Site 2-3 Command Line Deployment

16 Pre-defined CounterPoint Packages Files and Folders in each package ServerFiles Located in C:\CPSQLPackages\ServerFiles on First Site Server Includes files and directories that are needed to configure First Site Server and Remote Servers CPSQLSP.exe (current Service Pack) Registration.hub (if using Multi-Site Option) or Registration.ini (if using only Offline Ticket Entry or OfflineV2 Option) Setup.exe *.bat (deployment tasks) CounterPoint.ini Radiant.rtf Dealer.rtf (optional) \3RDParty \Acrobat \Custom (manually create) \DeploymentScripts \DXRE \Help \MDAC \PDF \Perl \Scripts \SSE2005 \System \Training \Tutorials (manually copy) \XMLUpdate \<Company> WorkstationFiles Located in C:\CPSQLPackages\WorkstationFiles on First Site Server Includes files needed to install and update workstations Registration.hub (if using Multi-Site Option) or Registration.ini (if using only Offline Ticket Entry Option) *.bat (Workstation deployment tasks) CounterPoint.ini Radiant.rtf Dealer.rtf (optional) \3RDParty \CPDialup \DeploymentScripts \Perl Multi-Site 2-4 Command Line Deployment

17 CounterPoint Deployment Tasks Work with files in package directories to accomplish specific CounterPoint operations Batch files located in ServerFiles folder or WorkstationFiles folder Each task / batch file executes a script Note: As a general rule, avoid running a task when users are working in CounterPoint. Multi-Site 2-5 Command Line Deployment

18 CounterPoint Server Tasks Server Tasks Manually run on each server Located in C:\CPSQLPackages\ServerFiles Uses files in ServerFiles package Run as Windows Administrative user Task / Batch File ActivateServerDatabase Runs This Perl Script ActivateServerDatabase.pl Creates pduser database login, creates (or updates) server database, imports replication rules, and activates (or upgrades) database for replication. CounterPointServerRegistration InstallServer CounterPointServerRegistration.pl Uses Registration.hub (or.ini) to register CounterPoint SQL on a server. InstallServer.pl Installs and updates CPSQL Server files, including Service Pack, on a server. Optionally installs or creates: SSE, DXRE, Database, Predefined data, Activates database for replication. InstallServerDiagnostics InstallServerDiagnostics.pl Simulates the InstallServer task and only logs commands that would be executed by the scripts (in C:\InstallServerDiagnostic.log), based on Deployment Parameter settings. Use to examine parameter settings "in context" so they can be corrected in the Deployment Parameter file before using the InstallServer task. InstallServerServicePack Installs CounterPoint service pack on a server. InstallServerServicePack.pl ResetServerDeltas ResetServerDeltas.pl Resets delta values on a Remote Server, forcing full replication of delta columns from First Site Server in next replication session. UninstallServer UninstallServer.pl Uninstalls CounterPoint SQL from a server. Optionally uninstalls DXRE and SSE. UpdateServerTopLevelFiles UpdateServerTopLevelFiles.pl Updates CounterPoint top-level directory files on a server other than First Site Server. Multi-Site 2-6 Command Line Deployment

19 CounterPoint Workstation Tasks Workstation Tasks Manually run on each Offline V1 workstation Located in C:\CPSQLPackages\WorkstationFiles Uses files in WorkstationFiles package Run as Windows Administrative user, or allow any user by pre-running RunAsSpcAdmin on server Task / Batch File ActivateWorkstationDatabase Runs This Perl Script ActivateWorkstationDatabase.pl Creates pduser database login, creates (or updates) workstation database, imports replication rules, and activates (or upgrades) database for replication. ActivateWorkstationTemplateDatabase ActivateWorkstationTemplateDatabase.pl Creates pduser database login, produces DSN for this workstation, activates copy of existing offline database on this workstation without importing rules or triggers again. CounterPointWorkstationRegistration CounterPointWorkstationRegistration.pl Copies Registration.ini from Remote Server top-level CounterPoint directory to a workstation. InstallWorkstation InstallWorkstation.pl Installs (or updates) CounterPoint on a workstation, using executables on Remote Server. Optionally installs or creates: SSE, DXRE, Database, Activates database for replication. InstallWorkstationDIagnostics InstallWorkstationDiagnostics.pl Simulates the InstallWorkstation task and only logs commands that would be executed by the scripts (in C:\InstallWorkstationDiagnostic.log), based on Deployment Parameter settings. Use to examine parameter settings "in context" so they can be corrected in the Deployment Parameter file before using the InstallWorkstation task. ResetWorkstationDeltas ResetWorkstationDeltas.pl Resets delta values on a workstation, forcing full replication of delta columns from Remote Server in next replication. UninstallWorkstation UninstallWorkstation.pl Uninstalls CounterPoint SQL from a workstation. Optionally uninstalls DXRE and SSE. UpdateWorkstationTopLevelFiles UpdateWorkstationTopLevelFiles.pl Copies top-level directory files from Remote Server to an OfflineV1 workstation (except computer used as First Site Server, if also a workstation). Multi-Site 2-7 Command Line Deployment

20 Example Diagnostics Log InstallServerDiagnostics.log ****************************** Start Time: Wed Oct 15 07:43: DeploymentScripts\InstallServer.pl Configuration values for machine firstsite Using configuration for StandardFirstSiteServer Using configuration for StandardServer Using configuration for StandardMachine CPSQLLogin=cpsql CPSQLPassword=cppassword Comment=Install CPSQL Server and Workstation on FIRST site hub DatabaseNames=DemoHub PDAdminLogin=Admin PDAdminPassword=password PDREServerName=firstsite PDUserLogin=pduser PDUserPassword=pdpassword ProgramsDir=C:\Program Files\CounterPoint RulesFile=msDelta.rul SQLServerName=firstsite SerialNumber= ServerActivateDatabases=Y ServerCreateDatabases=Y ServerInstallSQLX=N ServerInstallDXRE=Y ServerInstallPredefinedData=Y ServerTopLevelDir=\\FirstSite\CounterPoint ShareName=CounterPoint SiteName=FIRSTSITE SiteType=FIRST TopLevelDir=C:\CounterPoint WorkstationInstallDBUtilities=N install_server: starting Executing command Setup /s Server install successful Verify DOTNETFramework version: starting Executing command DeploymentScripts\VerifyDOTNETFramework /s Verify DOTNETFramework: finished Creating Registration.ini from Registration.hub Registration.ini: DEMSClientCount=6 Registration.ini: Name=NFR Hub - For Dealer In-House Testing Only Registration.ini: ExpirationDate=1/31/2009 Registration.ini: Offline V2=1 Registration.ini: DEMSCode=0D885957BC5EE7B07F51E6F56DE6815C Registration.ini: Hub=1 Registration.ini: DealerCode=RADS Registration.ini: PermCode= Registration.ini: Advanced Pricing=1 Registration.ini: Data Interchange=1 Registration.ini: Receivables=1 Registration.ini: LastUpdate=4/24/2008 2:15:09 PM Registration.ini: Multi-Site=1 Registration.ini: SerialNumber= Registration.ini: Serial Numbers=1 Registration.ini: Kits/Bills of Material=1 Registration.ini: UserCount=2 Registration.ini: Version=8.3.8 Registration.ini: Enterprise=1 Registration.ini: TempCode=9B164A237FA2F593FD85F66E0DC79C38 Registration.ini created from Registration.hub Server registration file update successful Copying directory SSE2005 Executing command xcopy "SSE2005" "C:\CounterPoint\WorkstationFiles\SSE2005" /s /e /i /q /r /k /y SSE directory copy successful Copying directory DXRE Executing command xcopy "DXRE" "C:\CounterPoint\WorkstationFiles\DXRE" /s /e /i /q /r /k /y DXRE directory copy successful Copying directory 3RDParty Executing command xcopy "3RDParty" "C:\CounterPoint\WorkstationFiles\3RDParty" /s /e /i /q /r /k /y 3RDParty directory copy successful Copying directory DeploymentScripts Executing command xcopy "DeploymentScripts" "C:\CounterPoint\WorkstationFiles\DeploymentScripts" /s /e /i /q /r /k /y DeploymentScripts directory copy successful Copying Deployment batch files Executing command xcopy "*.bat" "C:\CounterPoint\WorkstationFiles\OfflineFiles" /i /q /r /k /y Multi-Site Deployment batch files copy successful 2-8 Command Line Deployment install_server: finished

21 Using UpdateTopLevel.exe Copies files from company's CounterPoint folders on First Site Server to ServerFiles and WorkstationFiles packages Execute on a server prior to running UpdateServerTopLevelFiles.bat or UpdateWorkstationTopLevelFiles.bat (OfflineV1) Located in CPSQLPackages directory 1. Run UpdateTopLevel.exe if any of these files have changed on the First Site Server*: CounterPoint.ini Registration.hub (or.ini) Radiant.rtf Dealer.rtf \CPDialup \Scripts \System \<Company> Registration.hub (or.ini) \DeploymentScripts Copies from First Site Server's CounterPoint directory to the ServerFiles package on the First Site Server Copies from ServerFiles package on the First Site Server to the WorkstationFiles package on the First Site Server You can instead manually copy any changed files to the corresponding package directory on the First Site Server. * The top-level files on the First Site Server are considered to be the "master" set of files. For that reason, make changes to top-level files on the First Site Server. This includes: - Data Dictionary changes - Text Dictionary change - Zoom customizations - Lookup changes - Filter changes - Custom reports - Custom forms continued Multi-Site 2-9 Command Line Deployment

22 2. Copy the entire ServerFiles package from the First Site Server to C:\CPSQLPackages on each Remote server. Copy the entire WorkstationFiles package from the First Site Server to C:\CPSQLPackages on each Offline V1 workstation. 3. Switch to C:\CPSQLPackages\ServerFiles and run UpdateServerTopLevelFiles.bat on each remote server. Switch to C:\CPSQLPackages\WorkstationFiles and run UpdateWorkstationTopLevelFiles.bat on each Offline V1 workstation. Multi-Site 2-10 Command Line Deployment

23 Did the Task Complete? Task Log Task log created in C:\ on system where deployment task is run Log name = [BatchFileName].log Multi-Site 2-11 Command Line Deployment

24 Did the Task Complete? Database Activation Log If task failed during PDActivate or PDUpgrade step, also check these logs: PDActivate.log PDUpgrade.log Results of activating or upgrading a database Shows all details of activation/upgrade process Creates new.log each time and rotates prior logs (.lo1,.lo2, etc.) Located in C:\ on system where activation/upgrade occurred Tasks that can activate or upgrade a database: InstallServer.bat InstallWorkstation.bat ActivateServerDatabase.bat ActivateWorkstationDatabase.bat (OfflineV1) Example PDActivate.log I 0bdc :42:44 dcmn7000 DataXtend RE Activate a Project Release Version Jul for Win32/Intel Log file started: 4/3/2007 4:42:44 PM I 0bdc :42:44 dcmn7001 Command line parameters: /DA=MSSQL /LOGF=c:\pdactivate.log /ODBCN=pduser ODBCP=***** /Q /SITEN=FIRSTSITE /FI /PN=PD30DayLicense.pnl /DB=firstsite:DemoHub /RU=msDelta.rul D 0be :42:44 insa5054 Current progress is 0 (of 100) I 0be :42:44 internal Trying to connect to MSSQL:firstsite:DemoHub as pduser I 0be :42:44 dom Creating 'DataXtend SQL Server' datasource 'PD Temporary DSN' with connection string DSN=PD Temporary DSN\0 AutoTranslate=No\0 Database=DemoHub\0 QuotedID=Yes\0 Regional=No\0 SERVER=firstsite I 0be :42:44 internal Successfully connected to ODBC DSN PD Temporary DSN I 0be :42:44 internal Setting reference time for activation: 4/3/2007 9:42:44 PM D 0be :42:44 pddb7072 Checking for duplicate data source name PD Temporary DSN I 0be :42:44 pddb7074 Data source PD Temporary DSN already exists, it E = error (problems that cause replication to fail) W = warning (potential "problems" that do not cause replication to fail) I = information (events that occurred on a per table basis) D = debug (used by Progress when troubleshooting problems with PD system tables) Multi-Site 2-12 Command Line Deployment

25 Building the Deployment Parameter File Parameters used by deployment task scripts Separate set of parameters for each managed computer Filename = Deployment.ini, located in C:\CPSQLPackages\ ServerFiles\DeploymentScripts on First Site Server Click on the desktop of First Site Server, or run DeploymentEditor.exe in C:\CPSQLPackages\ServerFiles\ DeploymentScripts. Standard Templates Managed computers Typical parameters for different types of computers. Include Use=Standardxxxx to incorporate in parameters for a new managed computer. Changes and additions can be made to the Standard parameters. Pre-defined sets of parameters for specific types of managed computers. Copy and paste parameters into new managed computer definition. No changes or additions are allowed to the Templates. Displays each managed computer for which parameters are already defined. Multi-Site 2-13 Command Line Deployment

26 Deployment Parameter File Adding parameters for a managed computer Click Managed computers in the left pane. Click to add a new managed computer. Enter the hostname or IP address of a managed computer. The first parameter for the computer, SiteName, automatically displays in the right pane. To build the other parameters for this computer, use any combination of these methods: 1. Click a Template in the left pane that corresponds to the type of managed computer you are defining. In the right pane, highlight the parameters that you want to copy for your new computer and drag them to the name of your managed computer in the left pane. (You can also copy and paste the parameters, using Ctrl+C and Ctrl+V.) 2. Add a "Use" parameter, following the above method, and set its value to one of the Standard computer types (e.g., Use=StandardServer) or to an alreadydefined managed computer. This allows you to use the parameters already defined for one of the "standard" computers or any managed computer, without specifically adding them again for the managed computer you are defining. Only one Use parameter can exist for each managed computer. 3. Click anywhere in the right pane and click to select a new parameter from the list. Refer to the following pages for suggested parameter settings for each type of managed computer. Multi-Site 2-14 Command Line Deployment

27 Deployment Parameter File = displays as parameter is being added = parameter setting is valid = parameter setting is invalid (cause of error displays here) Click to see all parameters for this computer, including those from "Use" parameters as well as defaults for parameters that are not specifically set otherwise. Multi-Site 2-15 Command Line Deployment

28 Using the Deployment Editor Special Notes on the Deployment Editor Includes full online help Installs on First Site Server when packages are installed from CounterPoint DVD Use to move a parameter up or down in the list. These changes are temporary and are not saved. You cannot alphabetize the list of managed computers or the list of parameters. The Deployment file is a text file where the information exists in the order it was entered. You can use on the toolbar as a quick way to move to the parameters for an already-defined managed computer. When adding a new parameter, you can identify the name by typing the starting characters of the parameter name, or you can select it from a list You can add your own parameters and make changes to the parameters in the 'Standard' definitions, but not to the 'Template' definitions You can use the "Use" parameter to point to another managed computer, when you want to share the same parameter settings If you use nested "Use" parameters, the last used section's parameters will override the same parameters from an earlier used section. For example: StandardFirstSiteServer StandardServer StandardMachine Use Standard Server SiteType=FIRST Use Standard Machine ServerInstallDXRE=Y SiteType=HIGH In this example, SiteType is repeated in two of the Standard sections. If you "Use = StandardFirstSiteServer", SiteType will result in HIGH because it is set that way in the last used section. (This example infers that you modified StandardFirstSiteServer to add SiteType=FIRST.) Multi-Site 2-16 Command Line Deployment

29 Deployment Parameters First Site Server These parameters can be set initially and left alone, regardless of the task. SystemType = Hub SiteName = Hostname or IP address of this computer ServerTopLevelDir = \\computer_name\counterpoint (if First Site Server is also a workstation) TopLevelDir = Path to top-level CounterPoint, if different than C:\CounterPoint ProgramsDir = If also used as a workstation, path to CounterPoint program files directory, if different than C:\Program Files\CounterPoint ShareName = Share name for server CPSQL top-level, if different than CounterPoint SiteType = FIRST (availability level for replication) SerialNumber = CounterPoint serial number for this server DatabaseNames = Database_name; alias (if different than database name) ServerActivateDatabases = Y (do not enable until initial data exists on this server) PDUserLogin = DataXtend database login, if different than pduser PDUserPassword = DataXtend database password, if different than pdpassword RulesFile = Name of custom replication rules file, if different than msdelta.rul ServerCreateDatabases = Y CPSQLLogin = CounterPoint database login, if different than cpsql CPSQLPassword = CounterPoint database password, if different than cppassword SQLServerName = Hostname or IP address of SQL server, if different than this Server DXREServerName = Hostname or IP address of DXRE server, if different than this Server ServerInstallSQLX = N (you must use MSSQL on the First Site Server) ServerInstallDXRE = Y ServerInstallPredefinedData = Y Comment = Any comments or remarks to explain settings (only one comment) These parameters can be set initially, but you will need change them to "Y" prior to using the associated task. ServerResetDeltas = N (Change to "Y" for ResetServerDeltas.bat) PDAdminLogin = DataXtend login for use with ResetDeltas; set to ADMIN PDAdminPassword = DataXtend password for use with ResetDeltas; set to password ServerUninstallSQLX = N (Change to "Y" for UninstallServer.bat task if you also want to uninstall SSE) ServerUninstallDXRE = N (Change to "Y" for UninstallServer.bat task if you also want to uninstall DXRE) These parameters need to be set only if you have custom scripts, or if you want to apply different "dsetting" options when using a task that activates or upgrades a database for replication. Put custom scripts in C:\CPSQLPackages\ServerFiles\Custom on First Site Server. ExtraCreateSchemaScripts = Custom script(s) to run after mssql.sql for new CPSQL database. For multiple scripts: script1,script2,script3 (comma-separated, no spaces) ExtraUpdateSchemaScripts = Custom script(s) to run after UpdateFrom8xx.sql for existing CounterPoint database ExtraPredefinedDataScripts = Custom script(s) to run after updating predefined data ExtraPostPDActivateScripts = Custom script(s) to run after msdelta.sql when activating a database ExtraPostPDUpgradeScripts = Custom script(s) to run after msdelta.sql when upgrading a database ExtraPostPDActivateDSettings = Additional PD "dsetting" options to apply when activating a database ExtraPostPDUpgradeDSettings = Additional PD "dsetting" options to apply when upgrading a database Multi-Site 2-17 Command Line Deployment

30 Deployment Parameters Remote Server also used as a Workstation These parameters can be set initially and left alone, regardless of the task. SystemType = Remote SiteName = Hostname or IP address of this computer ServerTopLevelDir = Top-level CounterPoint directory on this server (\\computer_name\counterpoint) TopLevelDir = Path to top-level CounterPoint, if different than C:\CounterPoint ProgramsDir = If also used as a workstation, path to CounterPoint program files directory, if different than C:\Program Files\CounterPoint ShareName = Share name for server CPSQL top-level, if different than CounterPoint SiteType = HIGH (availability level for replication) SerialNumber = CPSQL serial number for this server DatabaseNames = Database_name; alias (if different than database name) PartnerAddress = Hostname or IP address of First Site Server ServerActivateDatabases = Y (do not enable until initial data exists on First Site Server) PDUserLogin = DataXtend database login, if different than pduser PDUserPassword = DataXtend database password, if different than pdpassword RulesFile = Name of custom replication rules, if different than msdelta.rul ServerCreateDatabases = Y CPSQLLogin = CounterPoint database login, if different than cpsql CPSQLPassword = CounterPoint database password, if different than cppassword SQLServerName = Hostname or IP address of SQL server, if different than this server DXREServerName = Hostname or IP address of DXRE server, if different than this server ServerInstallSQLX = Y to install SSE (N if this server has MSSQL installed instead) ServerInstallDXRE = Y ServerInstallPredefinedData = N (should never be set to "Y" anywhere except First Site) WorkstationInstallDBUtilities = Y Comment = any comments or remarks to explain settings These parameters can be set initially, but you will need change them to "Y" prior to using the associated task. ServerResetDeltas = N (Change to "Y" for ResetServerDeltas.bat) PDAdminLogin = DataXtend login for use with ResetDeltas; set to ADMIN PDAdminPassword = DataXtend password for use with ResetDeltas; set to password ServerUninstallSQLX = N (Change to "Y" for UninstallServer.bat task if you also want to uninstall SSE) ServerUninstallDXRE = N (Change to "Y" for UninstallServer.bat task if you also want to uninstall DXRE) These parameters need to be set only if you have custom scripts or if you want to apply different "dsetting" options when using a task that activates or upgrades a database for replication. Put custom scripts in C:\CPSQLPackages\ServerFiles\Custom on First Site Server. ExtraCreateSchemaScripts = Custom script(s) to run after mssql.sql for new CPSQL database. For multiple scripts: script1,script2,script3 (comma-separated, no spaces) ExtraUpdateSchemaScripts = Custom script(s) to run after UpdateFrom8xx.sql for existing CP database ExtraPredefinedDataScripts = Custom script(s) to run after updating predefined data ExtraPostPDActivateScripts = Custom script(s) to run after msdelta.sql when activating a database ExtraPostPDUpgradeScripts = Custom script(s) to run after msdelta.sql when upgrading a database ExtraPostPDActivateDSettings = Additional PD "dsetting" options to apply when activating database ExtraPostPDUpgradeDSettings = Additional PD "dsetting" options to apply when upgrading database Multi-Site 2-18 Command Line Deployment

31 Deployment Parameters Remote Server NOT used as a Workstation These parameters can be set initially and left alone, regardless of the task. SystemType = Remote SiteName = Hostname or IP address of this computer TopLevelDir = Path to top-level CounterPoint, if different than C:\CounterPoint ShareName = Share name for server top-level CPSQL, if different than CounterPoint SiteType = HIGH (availability level for replication) SerialNumber = CounterPoint serial number for this server DatabaseNames = Database_name; alias (if different than database name) PartnerAddress = Hostname or IP address of First Site Server ServerActivateDatabases = Y (do not enable until initial data exists on First Site Server) PDUserLogin = DataXtend database login, if different than pduser PDUserPassword = DataXtend database password, if different than pdpassword RulesFile = Name of custom replication rules, if different than msdelta.rul ServerCreateDatabases = Y CPSQLLogin = CounterPoint database login, if different than cpsql CPSQLPassword = CounterPoint database password, if different than cppassword SQLServerName = Hostname or IP address of SQL server, if different than this server PDREServerName = Hostname or IP address of DXRE server, if different than this server ServerInstallMSDE = Y (N if this server has MSSQL installed instead) ServerInstallPDRE = Y ServerInstallPredefinedData = N (should never be set to "Y" anywhere except First Site) Comment = Any comments or remarks to explain settings (only one comment) These parameters can be set initially, but you will need change them to "Y" prior to using the associated task. ServerResetDeltas = N (Change to "Y" for ResetServerDeltas.bat) PDAdminLogin = DataXtend login for use with ResetDeltas; set to ADMIN PDAdminPassword = DataXtend password for use with ResetDeltas; set to password ServerUninstallSQLX = N (Change to "Y" for UninstallServers.bat task if you also want to uninstall SSE) ServerUninstallDXRE = N (Change to "Y" for UninstallServers.bat task if you also want to uninstall DXRE) These parameters need to be set only if you have custom scripts, or if you want to apply different "dsetting" options when using a task that activates or upgrades a database for replication. Put custom scripts in C:\CPSQLPackages\ServerFiles\Custom on First Site Server. ExtraCreateSchemaScripts = Custom script(s) to run after mssql.sql for new CPSQL database. For multiple scripts: script1,script2,script3 (comma-separated, no spaces) ExtraUpdateSchemaScripts = Custom script(s) to run after UpdateFrom8xx.sql for existing CounterPoint database ExtraPredefinedDataScripts = Custom script(s) to run after updating predefined data ExtraPostPDActivateScripts = Custom script(s) to run after msdelta.sql when activating a database ExtraPostPDUpgradeScripts = Custom script(s) to run after msdelta.sql when upgrading a database ExtraPostPDActivateDSettings = Additional PD "dsetting" options to apply when activating database ExtraPostPDUpgradeDSettings = Additional PD "dsetting" options to apply when upgrading database Multi-Site 2-19 Command Line Deployment

32 Deployment Parameters Offline V1 Workstation (including those connected via Terminal Services Server) These parameters can be set initially and left alone, regardless of the task. SystemType = OfflineWorkstation SiteName = Hostname or IP address of this computer TopLevelDir = Path to top-level CounterPoint, if different than C:\CounterPoint ProgramsDir = Path to CounterPoint program files directory, if different than C:\Program Files\CounterPoint ServerTopLevelDir = Top-level CounterPoint directory on server to which this workstation is connected (e.g., \\computer_name\counterpoint or G:\CounterPoint) For Terminal Services: use top-level CP directory on FirstSite server SiteType = LOW (availability level for replication) PartnerAddress = Hostname or IP address of First Site Server (with Internet) DatabaseNames = Database_name; alias, if different than database name SQLServerName = Hostname or IP address of SQL server, if different than this workstation; Must be default instance name of MSSQL DXREServerName = Hostname or IP address of DXRE server, if different than this wkstation WorkstationCreateDatabases = Y CPSQLLogin = CounterPoint database login, if different than cpsql CPSQLPassword = CounterPoint database password, if different than cppassword WorkstationActivateDatabases = Y (do not enable until initial data exists on First Site Server) PDUserLogin = DataXtend database login, if different than pduser PDUserPassword = DataXtend database password, if different than pdpassword RulesFile = name of custom replication rules, if different than msdelta.rul WorkstationInstallDashboard = Y WorkstationInstallDBUtilities = Y WorkstationInstallSQLX = Y to install SSE (N if this workstation has MSSQL installed instead) WorkstationInstallDXRE = Y WorkstationInstallPredefinedData = N (should never be set to "Y" anywhere except First Site) Comment = any comments or remarks to explain settings (only one comment) These parameters can be set initially, but you will need change them to "Y" prior to using the associated task. WorkstationResetDeltas = N (Change to "Y" for ResetWorkstationDeltas.bat) PDAdminLogin = DataXtend Administrator login; set to ADMIN PDAdminPassword = DataXtend Administrator password; set to password WorkstationUninstallSQLX = N (Change to "Y" for UninstallWorkstation.bat task to uninstall SSE) WorkstationUninstallDXRE = N (Change to "Y" for UninstallWorkstation.bat task to uninstall DXRE) These parameters need to be set only if you have custom scripts, or if you want to apply different "dsetting" options when using a task that activates or upgrades a database for replication. Put custom scripts in C:\CPSQLPackages\ServerFiles\Custom on First Site Server. ExtraCreateSchemaScripts = Custom script(s) to run after mssql.sql for new CPSQL database. For multiple scripts: script1,script2,script3 (comma-separated, no spaces) ExtraUpdateSchemaScripts = Custom script(s) to run after UpdateFrom8xx.sql for existing CounterPoint database ExtraPredefinedDataScripts = Custom script(s) to run after updating predefined data ExtraPostPDActivateScripts = Custom script(s) to run after msdelta.sql when activating a database ExtraPostPDUpgradeScripts = Custom script(s) to run after msdelta.sql when upgrading a database ExtraPostPDActivateDSettings = Additional PD "dsetting" options to apply when activating database ExtraPostPDUpgradeDSettings = Additional PD "dsetting" options to apply when upgrading database Multi-Site 2-20 Command Line Deployment

33 Deployment Parameters Workstation (Offline V2 or not Offline) or Terminal Services Server These parameters can be set initially and left alone, regardless of the task. SystemType = Workstation SiteName = Hostname or IP address of this computer ProgramsDir = Path to CounterPoint program files directory, if different than C:\Program Files\CounterPoint ServerTopLevelDir = Top-level CounterPoint directory on server to which this workstation is connected (e.g., \\computer_name\counterpoint or G:\CounterPoint) For Terminal Services Server: use top-level CP directory on FirstSite server WorkstationActivateDatabases = N WorkstationCreateDatabases = N WorkstationInstallDashboard = Y WorkstationInstallDBUtilities = N WorkstationInstallSQLX = N WorkstationInstallDXRE = N WorkstationInstallPredefinedData = N Comment = Any comments or remarks to explain settings (only one comment) No other parameters need to be set for an Offline V2 or non-offline workstation or for a Terminal Services Server. Multi-Site 2-21 Command Line Deployment

34 Deployment Parameters Special Notes Parameter Name PartnerAddress Serial Number ServerCreateDatabase WorkstationCreateDatabases ServerActivateDatabases WorkstationActivateDatabases CPSQLLogin CPSQLPassword PDUserLogin PDUserPassword ServerInstallPredefinedData WorkstationInstallPredefinedData ServerTopLevelDir ShareName SystemType SiteName SiteType SQLServerName DXREServerName ServerInstallDXRE WorkstationInstallDXRE ServerInstallSQLX WorkstationInstallSQLX DatabaseNames Note Only used for initial replication. Set to First Site Server for all Remote Servers and any Offline V1 workstation with an internet connection. Set to Remote Server for Offline V1 workstations without an internet connection. Don t set on First Site Server, Offline V2 workstations, or non-offline workstations. For First Site and Remote Servers, serial number must match serial number in Registration.hub for each site. Don't set for any workstation. If database already exists, updates it by running UpdateFrom8.x.x script. Don't set for an Offline V2 or non-offline workstation. If database is already activated, upgrades database (reimports new rules file so that PDC Control tables are updated). When installing CP the first time, it's okay to create the database (ServerCreateDatabases=Y), but don't activate it unless the complete database exists on the First Site Server. Don't create or activate for an Offline V2 or non-offline workstation. Automatically creates user ID/password, unless database already exists and is owned by a different SQL user. Set to SQL user who owns database, if database already exists. Used only if ServerActivateDatabases or WorkstationActivateDatabases is enabled. Automatically creates user if necessary. Always set to N for a Remote Server or Workstation. Use UNC names, not drive letters. To install on drives other than C:, map a share to the desired drive and use the share name in the value you enter here (e.g., "\\ServerName\ShareName"). Use only for server-level computers, not workstations. Set to "Hub" if this is a server used only for Offline V1 (non-ms). Treats as IP address if hostname does not contain alpha characters FIRST, HIGH, or LOW. Can only have one FIRST site, which should be the First Site Server. Use HIGH for Remote Servers and LOW for Offline V1 Workstations. To designate a specific instance of the SQL server, add "\InstanceName" to value entered as ServerName. Max of 30 characters. Must be default instance name of MSSQL on offline workstation (V1 or V2). Path name cannot contain spaces or be longer than 8 characters Installs DXRE on server or workstation; auto-installs.net Framework 1.1 if missing. Installs SSE on server or offline workstation (V1 or V2). Name of the CounterPoint.mdf file. If alias is different name, follow database name with a semi-colon (;) and then the alias name. No spaces in database name. Multi-Site 2-22 Command Line Deployment

35 Deployment Parameters Special Notes Parameter Name WorkstationInstallDashboard ServerResetDeltas WorkstationResetDeltas PDAdminLogin PDAdminPassword ExtraCreateSchemaScripts ExtraUpdateSchemaScripts RulesFile ServerUninstallDXRE WorkstationUninstallDXRE Note Installs Dashboard programs and utilities on workstation; requires access to Internet. Automatically installs.net Framework 3.0 if missing. Dashboard is automatically installed on servers, but DashboardDemo database is not. User needs to configure Dashboard on server to use live database, or manually install DashboardDemo database. Use only when directed to do so by Technical Support. Used only if ServerResetDeltas or WorkstationResetDeltas is enabled. Automatically creates user if necessary. Custom script to alter database schema when database is created or updated to new release. Separate multiple scripts with semi-colon. Only list those that haven t already been applied to database Locate scripts in C:\CPSQLPackages\ServerFiles\Custom. If set to custom rules file, rules file must be located in C:\CPSQLPackages\ServerFiles\Custom. Uninstalls DXRE. Multi-Site 2-23 Command Line Deployment

36 Deployment Parameters What parameters does each Server task/batch file use? Install Server Install ServerDiagnostics Required: TopLevelDir ShareName SerialNumber Optional: ServerInstallSQLX ServerInstallDXRE ServerCreateDatabases CPSQLLogin CPSQLPassword DatabaseNames SQLServerName ExtraCreateSchemaScripts ExtraUpdateSchemaScripts ServerInstallPredefinedData SQLServerName DatabaseNames ExtraPredefinedDataScripts ServerActivateDatabases SQLServerName DXREServerName DatabaseNames PDUserLogin PDUserPassword SiteName RulesFile SiteType PartnerAddress ExtraPostPDActivateScripts ExtraPostPDUpgradeScripts ExtraPostPDActivateDSettings ExtraPostPDUpgradeDSettings InstallServerServicePack Required: TopLevelDir UpdateServerTop-LevelFiles Required: TopLevelDir DatabaseNames SerialNumber SiteType Multi-Site 2-24 Command Line Deployment

37 Deployment Parameters What parameters does each Server task/batch file use? (continued) ActivateServerDatabase Required: TopLevelDir ServerActivateDatabases SQLServerName DXREServerName DatabaseNames PDUserLogin PDUserPassword SiteName RulesFile SiteType PartnerAddress Optional: ServerCreateDatabases CPSQLLogin CPSQLPassword ExtraCreateSchemaScripts ExtraUpdateSchemaScripts ExtraPostPDActivateScripts ExtraPostPDUpgradeScripts ExtraPostPDActivateDSettings ExtraPostPDUpgradeDSettings CounterPointServerRegistration Required: TopLevelDir SerialNumber ServerTopLevelDir (if server is also a workstation) UninstallServer Required: TopLevelDir Optional: ServerUninstallDXRE ServerUninstallSQLX ResetServerDeltas Required: TopLevelDir SQLServerName PDREServerName DatabaseNames PDUserLogin PDUserPassword PDAdminLogin PDAdminPassword SiteType Multi-Site 2-25 Command Line Deployment

38 Deployment Parameters What parameters does each Workstation task/batch file use? InstallWorkstation InstallWorkstationDiagnostics Required: Optional: TopLevelDir ProgramsDir ServerTopLevelDir WorkstationInstallDashboard WorkstationInstallSQLX WorkstationInstallDXRE WorkstationInstallDBUtilities WorkstationCreateDatabases CPSQLLogin B) CPSQLPassword test DatabaseNames SQLServerName ExtraCreateSchemaScripts ExtraUpdateSchemaScripts WorkstationActivateDatabases SQLServerName DXREServerName DatabaseNames PDUserLogin PDUserPassword SiteName RulesFile SiteType PartnerAddress ExtraPostPDActivateScripts ExtraPostPDUpgradeScripts ExtraPostPDActivateDSettings ExtraPostPDUpgradeDSettings CounterPointWorkstationRegistration Required: ResetWorkstationDeltas Required: TopLevelDir SQLServerName DXREServerName DatabaseNames PDUserLogin PDUserPassword PDAdminLogin PDAdminPassword SiteType UninstallWorkstation Required: Optional: (None) TopLevelDir ServerUninstallDXRE ServerUninstallSQLX UpdateWorkstationTop-LevelFiles Required: ActivateWorkstationDatabase Required: Optional: ActivateWorkstationTemplate Database Required: Optional: TopLevelDir DatabaseNames ServerTopLevelDir SiteType TopLevelDir WorkstationActivateDatabases SQLServerName DXREServerName DatabaseNames PDUserLogin PDUserPassword SiteName RulesFile SiteType PartnerAddress WorkstationCreateDatabases CPSQLLogin CPSQLPassword DatabaseNames SQLServerName ExtraCreateSchemaScripts ExtraUpdateSchemaScripts ExtraPostPDActivateScripts ExtraPostPDUpgradeScripts ExtraPostPDActivateDSettings ExtraPostPDUpgradeDSettings TopLevelDir WorkstationCreateDatabases CPSQLLogin CPSQLPassword DatabaseNames SQLServerName WorkstationActivateDatabases SQLServerName DXREServerName DatabaseNames PDUserLogin PDUserPassword SiteName SiteType PartnerAddress ExtraPostPDActivateDSettings Multi-Site 2-26 Command Line Deployment

39 Exercise 2: Configuring Deployment of CounterPoint SQL Try it Yourself! In this exercise, you will define Deployment parameters for each managed computer, copy and attach the company database, copy the CounterPoint registration file and service pack, and install Deployment script updates. Perform Exercise 2 in the Exercise Handbook. The exercise consists of three primary steps. Each member of your class team should perform the entry work in a different step so that you each have an opportunity to participate. Multi-Site 2-27 Command Line Deployment

40 Exercise 3: Deploying CounterPoint SQL Try it Yourself! In this exercise, you will use two different Deployment Tasks tasks to deploy CounterPoint SQL and any needed components (such as SSE and DXRE) on the servers. After the InstallServer task installs CounterPoint SQL on a server, it will activate your company database for replication, which will automatically initiate the first replication session. After the InstallWorkstation task is completed on a server, you will be able to run CounterPoint SQL on that system. To ensure that users at each site log in to the proper CounterPoint workgroup, you will then identify the appropriate site for each workgroup on the FirstSite system. Perform Exercise 3 in the Exercise Handbook. Multi-Site 2-28 Command Line Deployment

41 Radiant Synchronization Service ( RadSync ) and Radiant Management Console Radiant Synchronization Service ( Rad Sync ) Required in order to use Radiant Management Console on a system Run Prerequisites installer before installing Rad Sync Manually install Rad Sync on First Site server and any system where Radiant Management Console will be used SQL user password must be saved in CP connection string in order for Rad Sync service to start Communicates on port 1968 (see Appendix 7 to configure for a different port) Radiant Management Console Connects to Rad Sync and allows authorized CounterPoint user to perform specific tasks: Workset Subscriptions for any managed computer Replication Schedule configuration for any managed computers Manually start replication from Remote servers to First Site server Radiant Management Console can be used for these tasks instead of using DataXtend Administrator. Authorize CounterPoint user to access Management Console by enabling Allow management console in System Security Code. Multi-Site 2-29 Command Line Deployment

42 Installing Radiant Synchronization Service ( RadSync ) Install on each server after CounterPoint SQL has been installed. 1. In company s CounterPoint connection string, enter SQL user s password and select to save it. CounterPoint connection string is automatically built and set for SQL authentication by InstallServer deployment task. The SQL user ID is retained in the connection string, but the password is not. Rad Sync service cannot start until SQL user s password has been saved in company s connection string. 2. Install prerequisites needed for Rad Sync. Microsoft components required by Rad Sync:.NET Framework 3.0 SQL Native Client SQL Server Management Objects SQLXML4 Log in to Windows as an administrative user. Run CPSQLPrereqs.exe from the root directory on the CounterPoint DVD on each system to install missing components prior to installing Rad Sync. You can also download CPSQLPrereqs.exe from the Support / Software Downloads area of the CounterPoint web site. 3. Open Radiant Synchronization Service port (1968). 4. Install Rad Sync and provision server s database. Execute RadSyncInstall.exe, located in top-level CounterPoint / OfflineFiles folder on server. At Installation Complete window, enable Provision Site Controller check box. After system reboots, enter Provision Database settings. When provision completes, Rad Sync Service is running and Radiant Management Console is ready to use. Multi-Site 2-30 Command Line Deployment

43 Exercise 4: Deploying Radiant Synchronization Service Try it Yourself! In this exercise, you will prepare each server for the Radiant Synchronization Service ( Rad Sync ) by installing the prerequisites. In addition, you will ensure that the SQL user s password is saved in the CounterPoint connection string for the company. You will then install the Rad Sync service and provision the server s database. The process of installing Rad Sync will also install the Radiant Management Console. Only CounterPoint users whose System Security Code allows access to the Management Console can use that function, so you will also enable that authorization in the exercise. You will use the Radiant Management Console in later exercises to subscribe your servers to specific replication worksets and to define their replication schedules. Perform Exercise 4 in the Exercise Handbook. Multi-Site 2-31 Command Line Deployment

44 Multi-Site 2-32 Command Line Deployment

45 SECTION 3: OTHER DEPLOYMENT ACTIVITIES Installing a CounterPoint Service Pack...3 Updating to a New CounterPoint Version...5 Updating a CounterPoint Registration...7 Installing a Permanent DXRE License...9 Delivering CounterPoint Customizations...11 Adding a Store or Location...15 Multi-Site Other Deployment Activities

46 Multi-Site Other Deployment Activities

47 Other Deployment Activities After CounterPoint SQL is installed, you will use other Deployment tasks as needed to deploy other CounterPoint changes. Some of the additional activities that you will deploy include: Installing a CounterPoint Service Pack Updating to a New CounterPoint Version Updating a CounterPoint Registration Installing a Permanent DXRE License Delivering CounterPoint Customizations Adding or Removing a Store or Location Each of these tasks is described on the following pages. Multi-Site 3-1 Other Deployment Activities

48 Multi-Site 3-2 Other Deployment Activities

49 Installing a CounterPoint SQL Service Pack 1. Download the current CounterPoint SQL service pack from the CounterPoint web site ( Multi-Site 2. Copy the service pack file CPSQLSP.EXE to C:\CPSQLPackages\ServerFiles on the First Site Server and each Remote Server. 3. On the First Site Server and each Remote Server, exit to a command prompt and navigate to C:\CPSQLPackages\ServerFiles. Run the deployment task InstallServerServicePack.bat. Note: Service Packs are automatically updated on a workstation the next time the workstation connects to its server to start CounterPoint SQL. 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. Offline Workstations (V1 or V2) If a workstation is also configured for Offline V1, you will have the option to also apply the service pack to the offline files on the workstation. If you select to skip the automatic offline file update, you will need to run the InstallWorkstation.bat deployment task to update the files. If a workstation is instead configured for Offline V2, the service pack will automatically be applied to the offline files on the workstation. Multi-Site 3-3 Other Deployment Activities

50 Multi-Site 3-4 Other Deployment Activities

51 Updating to a New CounterPoint SQL Version When you receive a new CounterPoint SQL DVD 1. On the First Site Server, use the Deployment Editor to ensure the Deployment parameters include these settings: For First Site Server only For First Site Server and Remote Servers For each Offline V1 workstation ServerInstallPredefinedData=Y ServerInstallDXRE=Y ServerCreateDatabases=Y ServerActivateDatabases=Y WorkstationInstallDXRE=Y WorkstationCreateDatabases=Y WorkstationActivateDatabases=Y 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. To re-deploy the schema changes and custom replication rules, ensure that these Deployment parameters are also set: For First Site Server, Remote Servers, and each Offline V1 workstation ExtraUpdateSchemaScripts=<CustomScript> RulesFile=<CustomRulesFile> 2. At the First Site Server, insert the CounterPoint SQL DVD and select CounterPoint SQL Enterprise Multi-Site/Offline Deployment Packages. This updates the Server files and some Workstation files on the First Site Server by copying them from the DVD to the corresponding directories on the First Site Server. 3. Copy the Registration.hub or Registration.ini file that you downloaded (or received from your CounterPoint partner) to both C:\CPSQLPackages\ ServerFiles and C:\CPSQLPackages\WorkstationFiles on the First Site Server. 4. Download the latest CounterPoint SQL Service Pack from Radiant's web site and put CPSQLSP.exe in C:\CPSQLPackages\ServerFiles directory on the First Site Server. 5. If one exists, download the latest update to the Deployment scripts (DeploymentScriptsUpd.exe) from Radiant's web site. Execute the download file and select to install the update in C:\CPSQLPackages on the First Site Server. Multi-Site 3-5 Other Deployment Activities

52 6. Copy CounterPoint.ini, Radiant.rtf, and the full \DeploymentScripts directory from C:\CPSQLPackages\ServerFiles to C:\CPSQLPackages\WorkstationFiles on the First Site Server. Updating the Servers 7. On each remote server, delete the contents of C:\CPSQLPackages\ServerFiles and C:\CPSQLPackages\WorkstationFiles package directories. This ensures that no old files are deployed. 8. Copy both the ServerFiles and WorkstationFiles packages from the First Site Server to C:\CPSQLPackages on each remote server. If this is the first time you have deployed a new release of CounterPoint, it's possible that there may not already be a WorkstationFiles package present on the remote server. 9. At the command prompt on the First Site Server and each remote server, switch to the C:\CPSQLPackages\ServerFiles directory. Run InstallServer.bat on each server when no one is logged in to CounterPoint. Updating the Workstations 10. After CounterPoint has been updated on the server, log in to CounterPoint on each workstation. The software will prompt to automatically update the workstation's CounterPoint files. The user who logs in will need to have Administrator rights, unless you have already run the RunAsAdminSPC utility to allow InstallWorkstation.exe to be run by non-administrative users. 11. If the workstation is also used for offline ticket entry V1, the software will prompt to update the offline CounterPoint files after the regular workstation files have been updated. The automatic update process will upgrade the offline database to the new release's schema and copies updated top-level files (including the new CounterPoint registration file) from the remote server. Administrator rights are also required to update the offline ticket entry files, unless you have already run the RunAsAdminSPC utility to allow InstallWorkstation.bat (different than InstallWorkstation.exe) to be run by nonadministrative users. Multi-Site 3-6 Other Deployment Activities

53 Updating a CounterPoint Registration Reasons for updating your CounterPoint registration You have purchased a new CounterPoint Option(s) for your system. You have increased the number of users in your CounterPoint license. You have added a new Remote Server to your CounterPoint system. You have received your permanent registration file and need to replace the temporary one. You have already updated your managed computers to a new version of CounterPoint SQL and did not have the updated registration file at that time. Updating the Servers 1. Copy the Registration.hub or Registration.ini file that you either received from your CounterPoint partner or that you downloaded from Radiant's website to both the C:\CPSQLPackages\ServerFiles and C:\CPSQLPackages\ WorkstationFiles directories on the First Site Server and each remote server. 2. At the command prompt on the First Site Server and each remote server, switch to the C:\CPSQLPackages\ServerFiles directory. Run CounterPointServerRegistration.bat on each server. Updating the Offline V1 Workstations 3. On each Offline V1 workstation, copy the new Registration.hub or Registration.ini file to the C:\CPSQLPackages\WorkstationFiles directory. 4. At the command prompt on each offline workstation, switch to the C:\CPSQLPackages\WorkstationFiles directory. Run CounterPointWorkstationRegistration.bat on each Offline V1 workstation. Multi-Site 3-7 Other Deployment Activities

54 Multi-Site 3-8 Other Deployment Activities

55 Installing a Permanent DXRE License Temporary license expires 30 days after installing DXRE Cannot create permanent DXRE license until permanent CounterPoint SQL registration is installed and updated on all servers and Offline V1 workstations Creating the permanent DXRE license 1. On the First Site Server, or a workstation connected to that server, start CounterPoint SQL 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 C:\CounterPoint\Scripts. Installing the license 3. To add the permanent DXRE license, select Start / Programs / DataXtend / Remote Edition / Controller on the First Site server. Select Available Databases from the Actions menu. Multi-Site 3-9 Other Deployment Activities

56 Select the First Site's database from the list of Available Databases, and click. Browse to C:\CounterPoint\Scripts on the First Site system. Select the PDLicense.PNL file and click Open. Click OK when completed and close the DataXtend Controller utility. Restart the DataXtend Replication Engine service. Multi-Site 3-10 Other Deployment Activities

57 Delivering Customizations and Images To deliver customizations made to: Data Dictionary Text Dictionary Zooms Lookups Filters Forms (PS receipts, POs, etc.) Reports Images (Customer and Item) HTML Make all changes on First Site Server (or copy changed files to First Site Server's directories see chart below) Note: These instructions will NOT deliver database schema changes. Type of customization Data Dictionary Text Dictionary Zooms, Lookups, Filters Zoom Style Sheets Custom Toolbar Buttons PS Forms Other Forms and Reports Quick Reports Label Files and Queries Saved PS Device Groups Images (Customer) (Items) Location of customized files \CounterPoint\<company>\Dictionary \CounterPoint\<company<\CustomForms \CounterPoint\<company>\Dictionary \CounterPoint\<company>\Dictionary \CounterPoint\<company>\Zooms \CounterPoint\<company>\Actions \CounterPoint\<company>\PSForms \CounterPoint\<company>\Reports \CounterPoint\<company>\QuickReports \CounterPoint\<company>\Labels \CounterPoint\<company>\Devices \CounterPoint\<company>\CustomerImages \CounterPoint\<company>\ItemImages 1. On the First Site Server, execute UpdateTopLevel.exe, located in C:\CPSQLPackages. Ensure that no one is running CounterPoint SQL on the First Site Server before you run this program. This program copies the top-level files (including the <Company>\Dictionary folder) from the First Site Server to C:\CPSQLPackages\ServerFiles on the First Site Server, and then copies certain files from the ServerFiles package to the WorkstationFiles package. Multi-Site 3-11 Other Deployment Activities

58 Click dialog. at the Welcome Click when asked for the Deployment Package Directory, to accept the default of C:\CPSQLPackages. Enter the name/alias for your CounterPoint company. If you are using Offline V2 on the workstation where you are running UpdateTopLevel.exe, the top-level files will also be copied from the First Site server to the workstation. When asked for the name of the First Site Server computer, enter the hostname of that system. Click when done. Use the button to browse to the top-level CounterPoint directory on the First Site Server. This correctly replaces the hostname you entered on the previous dialog with the drive letter of the First Site Server. Multi-Site 3-12 Other Deployment Activities

59 Click when done. When the Start Installation dialog displays, click. The following CounterPoint top-level files and directories are copied from the First Site server to the appropriate package directory on the First Site Server: Copied to ServerFiles from First Site system: Copied to WorkstationFiles from ServerFiles: CounterPoint.ini Registration.hub (or.ini) Radiant.rtf Dealer.rtf (if present) \CPDialup \Scripts \System \<your company directory> Registration.hub (or.ini) \DeploymentScripts Updating the remote servers 3. After UpdateTopLevelFiles has completed, copy both the ServerFiles and WorkstationFiles packages from the First Site Server to C:\CPSQLPackages on each remote server. 4. At the command prompt on each remote server, switch to the C:\CPSQLPackages\ServerFiles directory. Run UpdateServerTopLevelFiles.bat on each server when no one is running CounterPoint. Updating the Offline V1 workstations 5. Copy the WorkstationFiles packages from the First Site Server or remote server to C:\CPSQLPackages on each Offline V1 workstation. 6. At the command prompt on each Offline V1 workstation, switch to the C:\CPSQLPackages\WorkstationFiles directory. Run UpdateWorkstationTopLevelFiles.bat on each Offline V1 workstation. This copies updated top-level files from the workstation's Remote server to the local top-level directory. Multi-Site 3-13 Other Deployment Activities

60 Multi-Site 3-14 Other Deployment Activities

61 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. Install MDAC 2.8 on each managed computer at the new remote site, including the server and any workstations. 2. On the First Site Server, use the Deployment Editor to add parameters for the new remote server and each new workstation to the Deployment Parameter file. 3. Copy the Deployment Scripts folder from the C:\CPSQLPackages\ServerFiles to C:\CPSQLPackages\WorkstationFiles. 4. Copy both the ServerFiles and WorkstationFiles packages from the First Site Server to C:\CPSQLPackages on the new remote server. 5. At the command prompt on the new remote server, switch to the C:\CPSQLPackages\ServerFiles directory. Run InstallServer.bat on each server to deploy CounterPoint. 6. Copy the WorkstationFiles packages from the First Site Server or remote server to C:\CPSQLPackages on each Offline V1 workstation. 7. At the command prompt on each offline workstation, switch to the C:\CPSQLPackages\WorkstationFiles directory. Run InstallWorkstation.bat on each Offline V1 workstation. 8. Use the Radiant Management Console (or DataXtend Administrator) to subscribe the new remote server and offline workstations to the appropriate work sets for replication. 9. If you defined specific replication schedules for each managed computer (rather than a single replication schedule for 'All Sites'), use the Radiant Management Console or DataXtend Administrator to set up replication schedules for the new managed computers. Multi-Site 3-15 Other Deployment Activities

62 Multi-Site 3-16 Other Deployment Activities

63 SECTION 4: DXRE CONCEPTS What Data is Replicated: Replication Rules...1 Exercise 5: 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 Management Console...13 Subscribing to Work Sets Using DataXtend Administrator...17 Exercise 6: Subscribing to Work Sets...19 Saving the Custom Replication Rules...20 When and How Often to Replicate...21 Scheduling Replication Using Management Console...22 Scheduling Replication Using DataXtend Administrator...24 Exercise 7: Scheduling Replication...27 Database Activation Process...28 Q&A: Initial Replication and Subscriptions...30 Exercise 8: Viewing the Results of Activation...32 PDC Control Tables...33 Fragments and PDC Control Tables...34 Delta Update Tables...37 Delta Tracking Example...38 Delta Update Tables and Triggers...39 Delta Update Tables...40 Exercise 9: Replication in Action...41 Ways to Start Replication...42 Replication Partner Selection...44 Multi-Site DXRE Concepts

64 Making a Site Unavailable Temporarily...45 Deactivating a Remote or Offline Database...46 Moving a Replicating Database First Site...48 Moving a Replicating Database Remote/Offline V Correcting a Replicating Database on a Different System...52 Condemn vs Pdreset vs Duninst...54 Multi-Site DXRE Concepts

65 What Data is Replicated? First Site ("Hub") Remote Server CP database replication CP database Online access replication Online access replication Workstation Workstation Offline V1 CP database Offline V1 CP database Determined by Replication Rules and Site Subscriptions Replication Rules Pre-defined for CounterPoint SQL (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 Multi-Site 4-1 DXRE Concepts

66 Exercise 5: Installing DataXtend Studio Try it Yourself! Skip this exercise if you did not bring your own computer to class or if your computer does not have a DVD drive. In this exercise, you will install the DataXtend Studio on your own computer, which includes the DataXtend Designer. 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 SQL 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 SQL DVD and the CounterPoint MS Training CD. Perform Exercise 5 in the Exercise Handbook. Multi-Site 4-2 DXRE Concepts

67 Replication Rules For CounterPoint SQL, 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. Multi-Site 4-3 DXRE Concepts

68 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. Multi-Site 4-4 DXRE Concepts

69 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. Multi-Site 4-5 DXRE Concepts

70 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 If data in any of these fields changes, all of the fields in the "CATEG" fragment are replicated. 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. Multi-Site 4-6 DXRE Concepts

71 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 Multi-Site 4-7 DXRE Concepts

72 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) Multi-Site 4-8 DXRE Concepts

73 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. Multi-Site 4-9 DXRE Concepts

74 Replication Rules: Work Sets Work Set Name DM_STR_HIST_SUBSCRIBE (Dashboard data) Aggregated Dashboard data for a store IM_LOC_SUBSCRIBE (Inventory data) Primary data for a location. Includes the location record, inventory records, and unposted inventory transactions. IM_LOC_HIST_SUBSCRIBE (Inventory history data) History of all posted inventory transactions for a location. PS_STR_SUBSCRIBE (Point of Sale data) Primary data for a store, including store record, unposted PS documents and credit card transactions, customer data, and unposted A/R transactions. PS_STR_HIST_SUBSCRIBE (Misc store history data) History of drawer closing, A/R transactions, and timecard data. PS_STR_DAY_SUBSCRIBE (Point of Sale history data) History of all posted Point of Sale documents and associated credit card transactions, and commissions. SY_EVENT (Distributions) History of all posting events and distributions. Description of Data Subscribe to view aggregated data in Dashboard. Each remote server can subscribe to their own store s slice, if First Site is aggregating data for all stores. Remote servers who aggregate the data for their own store do not need to subscribe to any of this data. (Offline workstations do not need this work set.) Subscribe to view inventory information, or to enter inventory transactions. Each remote server and Offline V1 workstation should subscribe to their own location's slice. Subscribe to post inventory transactions, or to view or report on history for a location. Each remote server should subscribe to their own location's history work set slice. (Offline workstations do not need this work set.) 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 and Offline V1 workstation should subscribe to their own store's slice. 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 their own store's history work set slice. (Offline workstations do not need this work set.) 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 their own store's work set slice and for the number of days to retain history. (Offline workstations do not need this work set.) Subscribe to post any kind of transaction, or to work with distributions. No slices. Each remote server should auto-subscribe. (Offline workstations do not need this work set.) Note: After Multi-Site is configured and operating, new stores or locations can only be created Multi-Site at the Hub (First Site), and existing 4-10 stores can only be deleted at DXRE the Hub. Concepts

75 Replication Rules: Work Sets Work Set Example Base table First Dependent table Foreign keys in this table, back to parent table (IM_XFER_IN_LIN) Multi-Site 4-11 DXRE Concepts

76 Subscribing to Work Sets Use Radiant Management Console to subscribe each site to work sets Select Start CounterPoint SQL Radiant Management Console Connect to First Site server Enter subscriptions for all sites at First Site (Hub) Can subscribe a site to just data for its own location and/or store (a "slice" of a work set), or to multiple locations/stores PS history subscriptions for remote servers can be for specific number of days of history Radiant Management Console is alternative to using DataXtend Administrator to manage subscriptions Subscriptions entered via Management Console display in DataXtend Administrator SQL query in DataXtend Administrator handles number of days subscription for PS history SQL query entered in DataXtend Administrator does not update PS history subscription information in Management Console Multi-Site 4-12 DXRE Concepts

77 Subscribing to Work Sets using Radiant Management Console Select Start Programs CounterPoint SQL Radiant Management Console Click Site server. to connect with the First Enter the server s name or IP address, and the port used for the Rad Sync service. Enter the ID and password of a CounterPoint user who has authority (in their system security code) to access the management console. The server information appears on the Summary tab, including the name and version of the database that can be administered by the management console. Multi-Site 4-13 DXRE Concepts

78 Switch to the MultiSite Configuration tab and select Manage Work Set Subscriptions. Log in with the DataXtend administrator user name (ADMIN) and password (password). Select a work set for which you want to assign subscriptions. Then click to load the current subscriptions. Multi-Site 4-14 DXRE Concepts

79 The First Site server is always Auto-subscribed to all slices of all work sets (a Complete database). Initially, remote servers are not subscribed to any work set and will usually need to be subscribed to at least their own store s or location s work set slice. In order to sell to any customer, a remote server will need to subscribe to all slices of the Point of Sale data work set. Click after changing a subscription. 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 to limit the number of days of ticket history that will be retained on the remote server. 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. Multi-Site 4-15 DXRE Concepts

80 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. Remote servers always need to auto-subscribe to the Distributions work set, in order to assign event numbers to each posting operation. Multi-Site 4-16 DXRE Concepts

81 Subscribing to Work Sets using DataXtend Administrator Select Start Programs DataXtend Remote Edition Administrator Alternate way to view or change subscriptions entered using Management Console Each time you run the Administrator, you login with the DataXtend Administrator name and password (ADMIN and password). Select a site from the left pane. Then switch to the Subscription tab, to enter or view subscriptions for that site.. Work sets (complete database) appears for the First Site server, since this site is automatically auto-subscribed to every work set. Only the First Site should have the complete database. Multi-Site 4-17 DXRE Concepts

82 Remote Servers To see the subscriptions for a remote server, expand Work sets and then expand an individual work set to see the Subscribed base records and "Unsubscribed base records". Select a location or store under Unsubscribed base records and click subscribe to a new slice. The location or store name will move to Subscribed base records. to To subscribe to all of the base records in a work set (including any new ones that may be added in the future), highlight the work set name and click. The limited days of ticket history entered through the Management Console can be viewed by clicking. Changes you make in this SQL window are not reflected in the Management Console. Multi-Site 4-18 DXRE Concepts

83 Exercise 6: Subscribing to Work Sets Try it Yourself! In this exercise, you will use the Radiant Management Console at the First Site to subscribe the Remote Server to the work set slices that represent the location and store for this site. You will also subscribe this server to retain the latest 90 days of ticket history. Perform Exercise 6 in the Exercise Handbook. Multi-Site 4-19 DXRE Concepts

84 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. 2. Save verified rules Select File / Save. Correct any errors and reverify until no errors are reported. 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 in the ServerFiles package.* 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 use the Deployment Editor to add parameters for each server and offline workstation: RulesFile=CustomRulesFileName ExtraCreateSchemaScripts=CustomSQLScriptName (for new databases) or ExtraUpdateSchemaScripts=CustomSQLScriptName (for existing databases) use one of these deployment tasks to deploy your custom scripts and rules file: InstallServer.bat InstallWorkstation.bat (Offline V1 only) ActivateServerDatabase ActivateWorkstationDatabase (Offline V1 only) Multi-Site 4-20 DXRE Concepts

85 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 at First Site (Hub) Default replication schedule: Servers: Every 30 minutes, Monday - Friday 8:00 am to 7:00 pm Offline V1 workstations: Every 1 hour, Mon - Fri 8:00 am to 7:00 pm Use Radiant Management Console or DataXtend Administrator to create your own schedules Multi-Site 4-21 DXRE Concepts

86 Scheduling Replication using Radiant Management Console Select Start Programs CounterPoint SQL Radiant Management Console Click and connect with the First Site server. Switch to the MultiSite Configuration tab and select Manage Site Servers. Then select the server for which you will build a schedule. Multi-Site 4-22 DXRE Concepts

87 A Default schedule means that the normal replication schedule will be used for the site. Server: Every 30 minutes Mon Fri 8:00 am to 7:00 pm Offline V1 workstation: Every 1 hour Mon Fri 8:00 am to 7:00 pm A Disabled schedule means that the server s schedule is disabled and the server will no longer be included in scheduled replication. A Custom schedule is one that you define. When using the Management Console for scheduling replication, only one replication schedule can be defined for a site. Use the DataXtend Administrator to define multiple or more complex schedules for a site. Defining a Custom Schedule Replicate between Identify the times, in military format, during which replication should occur. Frequency Select the frequency that replication will occur during the specified time. Days of week Identify the days of the week to which this schedule will apply. Multi-Site 4-23 DXRE Concepts

88 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 at First Site (Hub) Select a specific site from the left pane. To include multiple sites in a single schedule, select All Sites, Complete Sites (First Site server), High Sites (Remote servers), or Low Sites (Offline V1 workstations). Then switch to the Schedule tab. Click enter a new schedule. to Multi-Site 4-24 DXRE Concepts

89 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. To disable the schedule without deleting it To restrict partner for bandwidth cycles 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 should 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. Other choices: Replicate at least Push Local Changes Pull Remote Changes Every [hh:mm] Retry every [hh:mm] If site hasn't replicated at all within the specified time frame, start a session. If it fails, retry after specified "repeat every" time. 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. 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. Specified time frame For failures, retry after "retry every" interval Click when completed. Multi-Site 4-25 DXRE Concepts

90 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 First Site 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). Multi-Site 4-26 DXRE Concepts

91 Exercise 7: Scheduling Replication Try it Yourself! In this exercise, you will build replication schedules at the First Site. You will begin by using the Radiant Management Console 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. Perform Exercise 7 in the Exercise Handbook. Multi-Site 4-27 DXRE Concepts

92 Database Activation Process What happens when a database is activated for replication? Deployment scripts execute pdactivate if parameter ServerActivateDatabases=Y or WorkstationActivateDatabases=Y Separate activation at each site 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 CPSQL 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. Multi-Site 4-28 DXRE Concepts

93 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") - at First 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 (First Site) 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 = 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) Multi-Site 4-29 DXRE Concepts

94 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. Q: What initially causes the database to be activated at a site? A: Q: What determines the "partner site" for initial replication? A: Unlike other sites, when the First Site's database is activated the first time, it does not automatically perform the initial replication. Q: Why doesn't the First Site automatically perform the initial replication when its database is activated? A: During setup, the initial replication typically occurs prior to subscribing sites to work sets or setting schedules for normal replication. Q: Without subscription information to control it, what data is replicated? A: Subscriptions to work sets for all sites and the replication schedule(s) are entered on the First Site, using the Radiant Management Console or DataXtend Administrator. Q: How do other sites "find out" the work sets they are subscribed to and the schedule for replication for their site? A: Q: How do other sites get the actual data in the tables that belong to work sets to which they are subscribed? A: Multi-Site 4-30 DXRE Concepts

95 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. Q: What's the difference between auto-subscribing and subscribing to all "slices" of a work set? A: After defining replication schedules on the First Site system and applying them, the First Site system will honor the schedule and attempt to replicate at the next scheduled time. Q: What can you do to replicate the information from the First Site system sooner than the next scheduled time? A: Multi-Site 4-31 DXRE Concepts

96 Exercise 8: 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 8 in the Exercise Handbook. Multi-Site 4-32 DXRE Concepts

97 PDC Control Tables At each site, for every CounterPoint SQL table that can be replicated IM_ITEM 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. PDCIM_ITEM PDC control tables are created in a site's database when the replication rules are imported. Multi-Site 4-33 DXRE Concepts

98 Fragments and PDC Control Tables PDCIM_ITEM Separate control tables maintained at each site PD control ID 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 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). Multi-Site 4-34 DXRE Concepts

99 Fragments and PDC Control Tables Start replication Site #1 Site #2 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 Multi-Site 4-35 DXRE Concepts

100 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. Multi-Site 4-36 DXRE Concepts

101 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 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 Multi-Site 4-37 DXRE Concepts

102 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 IM_INV_MSD (#1, 0) (#2, 0) (#3, 0) TRX QTY IM_INV.QOH 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 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 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 IM_INV_MSD (#1, +1) (#2, +2) (#3, +3) (#2, +2) (#1, +1) (#2, +2) (#3, +3) (#3, +3) (#1, +1) Multi-Site 4-38 DXRE Concepts

103 Delta Update Tables and Triggers AR_CUST Maintenance Add customers Edit customers Delete customers Transactions BAL UNPSTD_BAL ORD_BAL NO_OF_ORD LWY_BAL NO_OF_LWY PDx_ARCUST trigger PDCAR_CUST What fragment changed? When did it change? TR_AR_CUST_xxx trigger TR_AR_CUST_xxx trigger (run as pduser) AR_CUST_MSD BAL UNPSTD_BAL ORD_BAL NO_OF_ORD LWY_BAL NO_OF_LWY PDx_ARCUSTMSD trigger PDCAR_CUST_MSD What fragment changed? When did it change? <trigger_name> trigger <trigger_name> trigger = fires during processing in CounterPoint = fires during replication Multi-Site 4-39 DXRE Concepts

104 Delta Update Tables Table AR_CUST (Customers) IN_INV (Inventory) IM_INV_CELL (Inventory Cell) PO_RECVR_HIST (Received PO History Header) PO_RECVR_HIST_LIN (Received PO History Lines) PO_RTV_HIST (RTV History Header) SY_GFC (Gift Certificates) SY_STC (Store Credits) BAL NO_OF_ORDS ORD_BAL LOY_PTS_BAL TOT_LOY_PTS_ADJ GL_VAL QTY_COMMIT QTY_ON_BO QTY_ON_HND QTY_ON_PO QTY_COMMIT QTY_ON_BO QTY_ON_HND QTY_ON_PO QTY_ON_XFER_IN 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 Delta Columns 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 VCHR_MISC_AMT_1 VCHR_MISC_AMT_2 VCHR_MISC_AMT_3 VCHR_MISC_AMT_4 CURR_AMT CURR_AMT UNPSTD_BAL LWY_BAL NO_OF_LWYS TOT_LOY_PTS_EARND TOT_LOY_PTS_RDM QTY_ON_XFER_IN QTY_ON_XFER_OUT QTY_ON_ORD QTY_ON_LWY QTY_ON_SO QTY_ON_XFER_OUT QTY_ON_ORD QTY_ON_LWY QTY_ON_SO 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 ADJ_COST ADJ_EXT_COST ADJ_RECVD_COST ADJ_RECVD_EXT_COST ADJ_TOT_COST_CORR VCHR_MISC_AMT_5 VCHR_TOT_MISC VCHR_SUB_TOT VCHR_TOT Multi-Site 4-40 DXRE Concepts

105 Exercise 9: Replication in Action Try it Yourself! In this exercise, you will make changes to CounterPoint data at multiple sites and then perform replication. At each step of the exercise, you will examine the corresponding PDC control records and delta change records to see how the change is tracked and applied at each site. You will run CounterPoint SQL to make the data changes on two different systems. You will also use SQL Server Management Studio on the each system to examine the contents of the control and delta records. Perform Exercise 9 in the Exercise Handbook. Multi-Site 4-41 DXRE Concepts

106 Ways to Start Replication 1) Schedule replication 2) Manually run Management Console 3) Manually run DataXtend Synchronizer 4) Manually run DataXtend Controller 2) Manually run Management Console. Use this method to start replication between a remote server and the First Site server. The First Site server is always selected as the replication partner. Select Start / Programs / CounterPoint SQL / Management Console. Connect to your server. Switch to the MultiSite Configuration tab and select Manage Site Servers. Then select the remote server that will replicate with the First Site server. 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. Replication engine 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 Can start Synchronizer on a remote system, using remote control software. Multi-Site 4-42 DXRE Concepts

107 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 displays. Select the other site to replicate with, and then click. Changes made since the last replication session between the two sites are replicated. Multi-Site 4-43 DXRE Concepts

108 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 (First Site) 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 (Offline V1 Workstations): 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 Multi-Site 4-44 DXRE Concepts

109 Making a Site Unavailable Temporarily To temporarily make a site unavailable for replication Start the replication engine at the site to be made unavailable. 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. Multi-Site 4-45 DXRE Concepts

110 Deactivating a Remote or Offline V1 Database To permanently remove a site's database from replication network 1. Finish processing and posting all transactions in CounterPoint SQL 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 First Site, 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 First Site 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 or offline database for DatabaseDSN. pdreset /odbcn=pduser /odbcp=pdpassword 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 Multi-Site 4-46 DXRE Concepts

111 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). Multi-Site 4-47 DXRE Concepts

112 Moving a Replicating Database First Site Moving a replicating database to a new First Site system Follow these steps: - Install MDAC 2.8 on new First Site server. - Install MSSQL 2005 on new First Site server. - Install clock synchronization software on new First Site server. - Run UpdateTopLevel.exe on the old First Site server to ensure that current top-level files are included in ServerFiles and WorkstationFiles package directories. - Copy C:\CPSQLPackages directory and subdirectories from old First Site server to the new First Site server. - On the new First Site server, use the Deployment Editor to add parameters for the new First Site server to the Deployment Parameter file. Ensure that: ServerInstallPredefinedData=N SiteType=HIGH ServerTopLevelDir=new FirstSite Sever's hostname or IP address SerialNumber=serial number (same as old First Site Server) Add any other parameters that you want to use (such as DatabaseNames). - Delete the old First Site server from the Deployment Parameters file. - At a command prompt on the new First Site server, switch to C:\CPSQLPackages\ ServerFiles and run the deployment task InstallServer.bat. - If the new First Site server will also be used as a workstation, switch to C:\CPSQLPackages\WorkstationFiles and run the deployment task InstallWorkstation.bat. - On new First Site server, switch to \CounterPoint\Scripts and deactivate the new database that was created by running: duninst NewFirstSiteDSN - On new First Site server, activate by partnering with the old First Site and specifying to subscribe to all other sites: pdactivate /SITETYPE=COMPLETE /SUB=Y /PARTNER=OldFirstSSiteID /DA=MSSQL /ODBCN=pduser /ODBCP=pdpassword /RU=msdelta.rul /SITEN=NewFirstSiteID /PN=PDLicense.pnl /DB=SQLServerName:DatabaseName If you have custom tables and columns, use your custom rules file name in the /RU parameter. - Use the DataXtend Controller to replicate the old First Site database with the new First Site database. Do this twice. Multi-Site 4-48 DXRE Concepts

113 - On new First Site server, use the DataXtend Administrator to unsubscribe the old First Site from each managed computer's dsite work set, and subscribe new First Site server to each. Do this for all Remote servers and offline workstations. - Once again, use the DataXtend Controller to replicate the old First Site database with the new First Site database, to obtain updated subscriptions. - Use the DataXtend Controller to manually replicate each remote server and offline workstation with the new First Site server. Ensure that all remote servers and offline workstations have successfully replicated with the new First Site Server before continuing. - Replicate the old First Site database with the New First Site database to get any other data changes. - On the new First Site server, use the DataXtend Administrator to condemn old First Site database. This will deactivate the database and remove it from the replication network. - At a command prompt on the old First Site server, switch to the \CounterPoint\ Scripts folder and execute duninst OldFirstSIteDSN to remove the DataXtend DSN from the system. - On the new First Site server, use the Deployment Editor to make the following changes to the parameters for the new First Site server: SiteType=FIRST ServerInstallPredefinedData=Y - Copy the updated Deployment.ini file to C:\CPSQLPackages\ServerFiles\ DeploymentPackages and C:\CPSQLPackages\WorkstationFiles\Deployment Packages on the new First Site server, each Remote server, and each offline V1 workstation. Also make a backup of the updated Deployment.ini file. Multi-Site 4-49 DXRE Concepts

114 Moving a Replicating Database Remote/Offline V1 Moving a replicating database to a new Remote/Offline V1 system 1. At First Site, use the DataXtend Administrator to condemn the old site. 2. At the old Remote/Offline V1 system, execute duninst DatabaseDSN. These two steps deactivate the database and removes the old site from the replication network. On the new system at the Remote/Offline V1 site: 3. Install MDAC 2.8, and install SSE or MSSQL Copy the database files (.mdf and.ldf) to the MSSQL\Data directory and attach the database, or restore the database from backup. 5. 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' 6. Execute pddsn to create a temporary DSN named "test". pddsn /da=mssql /db=<computername>:<databasename> /odbcn=pduser /odbcp=pdpassword test 7. Execute pdreset utility to remove the PDC control tables, system tables, and triggers from the database. pdreset /odbcn=pduser /odbcp=pdpassword test This step is required so that when the database is re-activated, it recreates these tables and triggers with the correct site ID. 8. Execute drop procedure SQL command to drop the DataXtend stored procedures from the database: drop procedure PDGetNextID, PDGetSiteID, PDisPDUser 9. Execute msdropdelta.sql script to drop the delta tables from the database. Multi-Site 4-50 DXRE Concepts

115 10. Execute duninst to remove the temporary DSN. (If the database were still activated, duninst would also deactivate it.) duninst test 11. If necessary, use the Deployment Editor to remove parameters for the old managed computer and add parameters for the new managed computer. 12. Run the deployment task InstallServer.bat and/or InstallWorkstation.bat to install CounterPoint and activate the database. Note that during its initial replication with the First Site, you may see Type V "starter data" conflicts which will need to be resolved in the normal manner. Multi-Site 4-51 DXRE Concepts

116 Correcting a Replicating Database on a Different System Correcting a replicating database on a different system Correcting a replicating database on an entirely different system is not recommended. Because you will not have access to the GUID pool on the other system, the PDC control values that it assigns to your changes will be incorrect when the database is returned to the replication network. This will require that you remove all PDC control values from the database and regenerate them by re-activating the database. This will also require that the databases be replaced at all remote and offline V1 sites. And because the databases will be replaced at all sites, it is important to not introduce any data changes or new data in the other sites' databases that will need to be replicated. If corrections must be made on a different system, here are the instructions: At the First Site: 1. Use the DataXtend Controller to make the database unavailable. 2. Detach the database and copy the physical database files to the other system. 3. After correcting the database on the other system, return the physical database files to the First Site system and attach the database. At each Remote/Offline V1 site: 4. Execute duninst utility to remove the DataXtend DSN from the system. 5. Detach the database from the SQL Server. 6. Delete the physical database files (.mdf and.ldf). At the First Site: 7. After returning and attaching the database to the First Site, execute pdreset to remove the PDC control tables, system tables, and triggers from the database. This step is required so that when the database is re-activated, the correct site ID is used when the tables and triggers are recreated. Multi-Site 4-52 DXRE Concepts

117 8. Execute msdropdelta.sql script to drop the delta tables from the database. 9. Execute duninst utility to remove the DSN. On each Server (including First Site): 10. Switch to C:\CPSQLPackages\ServerFiles and execute the deployment task ActivateServerDatabase.bat. On each Offline V1 workstation: 11. Switch to C:\CPSQLPackages\WorkstationFiles and execute the deployment task ActivateWorkstationDatabase.bat. Multi-Site 4-53 DXRE Concepts

118 Condemn vs Pdreset vs Duninst Utility condemn pdreset duninst Description 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. Deletes PDC control tables, system tables, and triggers from database To run, execute from command prompt: pdreset /odbcn=pduser /odbcp=pdpassword DataSourceName Use when permanently removing database from replication network, when moving database to a new server or offline V1 workstation, or when bringing the database back after correcting it on a different system. 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 or Offline V1 workstation, or when bringing the database back after correcting it on a different system. Multi-Site 4-54 DXRE Concepts

119 SECTION 5: DXRE TROUBLESHOOTING Monitoring Replication...1 Data Xtend Site Monitor...2 DataXtend Logs...4 Replication Logs...5 Configuring Replication Engine Logs...6 Reading a Replication Engine Log...7 Key Segments of Replication Engine Log...8 Troubleshooting Tools...11 Identifying and Resolving Errors...13 Types of Errors...15 Resolving Duplicate Primary Key Errors...19 Gift Certificate and Store Credit Problems...25 Most Common Problems and Avoiding Them...26 Other Replication Problems...27 Slow Replication...28 When to Use pdfixcutoff...29 Changing Replication Performance...30 Multi-Site DXRE Troubleshooting

120 Multi-Site DXRE Troubleshooting

121 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 Displays replication information for each site used as a replication partner with this site. Watch for "Last Attempted " date that is later than "Last Successful " date. Replication Summary in CounterPoint From the CounterPoint menu, select System / Views / Replication Summary. Displays replication information for each site used as a replication partner with this site. Watch for "Status" of Check log files. Multi-Site 5-1 DXRE Troubleshooting

122 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 comma-delimited file Multi-Site 5-2 DXRE Troubleshooting

123 DataXtend Site Monitor Replication Partner Information Replication Session Information Multi-Site 5-3 DXRE Troubleshooting

124 DataXtend Logs Type of Log Log Name Location Replication Details of replication session Administrator Record of activity using Administrator Configuration setting Separate log for each dsetting applied Designer Record of activity using Designer PDActivate Record of database activation rsla0000#s01.log rsla0000#s02.log da.log da.lo2 dsetting.log dsetting.lo2 prd.log prd.lo2 pdactivate.log pdactivate.lo2 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 Program Files \ Progress \ DataXtend \ logs To view: Start \ Programs \ DataXtend \ Remote Edition \ Administrator Log Program Files \ Progress \ DataXtend \ logs Program Files \ Progress \ DataXtend \ logs Use View/Preferences (Logging tab) in DataXtend Designer to configure logs C:\ Multi-Site 5-4 DXRE Troubleshooting

125 Replication Logs For each replication session, replication engine logs show: Events that occurred during replication 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) = 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) Multi-Site 5-5 DXRE Troubleshooting

126 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) Total Log Size (50M) Max Number of Old Files (100) Max Age for Old Files (14) 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. All replication logs from all sessions can only occupy up to 50MB disk space before logs are removed. Maximum number of logs to keep prior to current session's logs. Maximum number of days to keep logs prior to current session's logs. Multi-Site 5-6 DXRE Troubleshooting

127 Reading a Replication Engine Log 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 with version DXRE 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 Multi-Site 5-7 DXRE Troubleshooting

128 Key Segments of Replication Engine Log Version of the Replication Engine and date/time the log file was created DataXtend RE Replication Engine Version Nov for Win32/Intel Log file started: 10/30/2006 7:15:09 AM Initiation of a replication session I 03c :36:03 dses2017 SEVT 2710: NewSession(1): 0 Information about each thread, including site ID, site name, session ID, and database to be replicated D 12d :56:51 dcmn41007 Thread started [id:000010ec] D 10ec :56:51 dcmn41000 DThread::Execute calling Run() I 12d :56:51 dses2017 SEVT 27022: NewSession(1): 0 D 10ec :56:51 dses17002 DSessionManager::Run start (_psession=010de510) I 12d :56:51 dses2013 SMSG: Session started () D 10ec :56:51 dses23000 Session Replication Session (0): Using zlib Compression D 10ec :56:51 dses1001 Session Replication Session (0): Using Triple DES Encryption D 10ec :56:51 dses6001 DJobManager: Added job "Repl Recv" (#27022). S 10ec :56:52 dcmn1 Setting PARTNER_IP_ADDRESS=server8 D 10ec :56:56 pdre7024 Connection to site 1 is authenticated D 10ec :56:56 pdre22036 DREH:Entering INIT S 10ec :56:56 dcmn1 Setting PARTNER_SITE_ID= D 10ec :56:56 dom New connection to PD29BZ1V002 created. S 10ec :56:56 dcmn1 Setting LOCAL_SITE_ID= S 10ec :56:56 dcmn1 Setting LOCAL_SITE_NAME=Server9 S 10ec :56:56 dcmn1 Setting CURRENT_SESSION_ID=27022 S 10ec :56:56 dcmn1 Setting CURRENT_DATABASE_NAME=PD29BZ1V002 Replication session begins I 10ec :56:56 dses2015 SMSG: (pdre,22042)-attempting replication on network 29LCWS. Local database is CounterPoint (MultiSite) - PD29BZ1V002 I 10ec :56:56 pdre22043 Session 27022: Attempting replication on network 29LCWS. Local database is CounterPoint (MultiSite) - PD29BZ1V002 Establish a connection with other site to perform replication I 10ec :56:56 pdre22077 Successful replication handshake completed for PD29BZ1V002 with partner site server8( ) Last successful replication with partner I 10ec :56:56 pdre66021 Current replication history record for partner site scandiumsql-fs(00lfls): I 10ec :56:56 10/29/2006 3:35:00 PM How far back the Replication Engine will look for changes to be replicated to the site I 10ec :56:56 pdre66021 Current replication history record for partner site serversql-s(00lfls): I 10ec :56:56 10/29/2006 3:35:00 PM D 10ec :56:57 internal Thread 10EC(Replication history for partner 00LFLS) released lock on PD29BZ1V002.dActHist D 10ec :56:57 dom 2013 Committing transaction for database PD29BZ1V002(03B0B5C0). D 10ec :56:57 pdre66046 Fuzziness for window of consideration: 600 seconds Multi-Site 5-8 DXRE Troubleshooting

129 Identifies local site, partner site, and negotiated cutoff date/time used in replication session. (Negotiated cutoff = how far back replication engine will look for updates) I 10ec :56:57 pdre34080 Resynchronizing CounterPoint (MultiSite) - PD29BZ1V002 (MS SQLServer) I 10ec :56:57 Local site: Server9 server9(00lflt) I 10ec :56:57 Partner site: serversql-fs server8(00lfls) I 10ec :56:57 Negotiated cutoff: 10/29/2006 2:51:09 PM(UTC) I 10ec :56:57 10/29/2006 6:51:09 AM(local) I 10ec :56:57 SessionID: Note: This is a global cutoff date since each table also has its own cutoff date. Identifies tables that have not changed since the previous replication session. I 10ec :56:57 pdre81061 Quick scan of AR_CTL indicated no changes A 10ec :56:57 pdre34081 AUDIT: 112 tables have no changes and will not be replicated For each table, determines the timestamp of the oldest fragment I 10ec :56:59 pdre66034 Oldest fragment found during replication of table PSSTR with site serversql-fs(00lfls) was timestamped 10/30/2006 3:56:43 PM For each table, identifies table that was replicated, number of bytes sent and received, amount of time replication of table took. A :30:05 pdre34217 AUDIT TSET IM_ADJ_TRX: Xmit: 0 bytes, Recv: 0 bytes A :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. D :30:05 dses2016 SMSG : (pdre,34219)-tset:im_adj_trx-snt:0 of 0,Upd:0,Ins:0,Del:0 A :30:05 pdre34220 AUDIT TSET: Records Sent: 0/0, Updated: 0, Inserted: 0, Deleted: 0, Transactions: 0) 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 :39:03 pdre34315 AUDIT TOTAL: Xmit: 558 bytes, Recv: 334 bytes A :39:03 Time: 6.204s ( Mb/min) A :39:03 SessionID: 2711 A :39:03 pdre34316 AUDIT TOTAL: 7 keys sent, 4 records sent A :39:03 pdre34317 AUDIT TOTAL: 3 records updated, 0 inserted, 0 deleted D :39:03 pdre34318 PerfAudit Total: DL:0ms, UL:0ms, RL:0ms, CL:0ms I :39:03 dses2015 SMSG: (pdre,34320)-replication of PD29BZ1P001 with OFFLINE1(00LFLU) has ended successfully with 3 conflicts resolved I :39:03 dses2015 SMSG: (pdre,34321)-pd29bz1p001 replication statistics: 558/334 bytes sent/recv'd in 6.204s D :39:03 dses2016 SMSG 2711: (pdre,34180)-updating link history I :39:03 pdre66057 Oldest fragment found during replication with site OFFLINE1(00LFLU) was timestamped 6/30/2005 5:36:18 PM Multi-Site 5-9 DXRE Troubleshooting

130 Multi-Site 5-10 DXRE Troubleshooting

131 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 if the WorkstationInstallDBUtilities=Y parameter is set for a site in the Deployment Parameter file. If you neglected to set the configuration parameter, you can install the database utilities on a workstation by navigating to the top-level CounterPoint folder on the workstation's server and running WorkstationSetup.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, "pdpassword" is set as the default). CounterPoint login You may need to run CounterPoint SQL to research and/or resolve data conflicts. Be sure that you have a CounterPoint SQL user ID (and password) that provides access to the full menu in CounterPoint. Stop new users from logging in Use "Pause" in SQL Server to prevent users from logging in to CounterPoint SQL 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". Multi-Site 5-11 DXRE Troubleshooting

132 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. Multi-Site 5-12 DXRE Troubleshooting

133 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 SQL 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. Multi-Site 5-13 DXRE Troubleshooting

134 Step 4. Correct cause of the error. The method used to correct an error will vary, depending on the type of error. Refer to the descriptions on the following pages of the 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. Multi-Site 5-14 DXRE Troubleshooting

135 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 E 080c :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 :14:20 ODBC Error -1: (01000) '[Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been terminated.' <3621,SQLExecute> E 080c :14:20 ODBC statement failed: -1 from function Execute E 080c :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"," _ADRS_1","FAX_1","PHONE_1","URL_1","CONTCT_2", E 080c :14:20 Unable to insert new record into table AR_CUST having key: PDCID( ),"MARILYN" E 080c :14:20 FSM:{An ODBC error occurred}: Unable to store next PD29BZ1P002.AR_CUST record from partner's data list (key:pdcid( )) D 080c :14:20 Released lock on table AR_CUST I 080c :14:20 SMSG: (pdre,33236)-update of AR_CUST in CounterPoint (MultiSite) - PD29BZ1P002 failed E 080c :14:20 Update of AR_CUST in CounterPoint (MultiSite) - PD29BZ1P002 failed E 080c :14:20 An error occurred in the sync session envelope. W 080c :14:20 Rolling back uncommitted transactions D 080c :14:20 Rolling back transaction for database PD29BZ1P002 I 080c :14:20 SMSG: (pdre,33209)-pd29bz1p002 replication has ended because of an error - check log for details To correct: To prevent: Pick the "winning" site, enter queries to remove incorrect data at "losing" site, and replicate again (see example on following pages). 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 SQL to avoid duplicate primary key errors. Clock Mismatch System time at the sites attempting to replicate is different by more than 10 minutes (besides time zone difference) E 08ac :46:18 dsessbas 567 An error occurred in the handshake envelope. E 08ac :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/ :46:18 Difference: 1002 Partner site: 04/27/ :03:00 To correct: To prevent: 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.) Use clock synchronization software on all replicating systems Multi-Site 5-15 DXRE Troubleshooting

136 Type 1 Conflict Same fragment updated by multiple sites W 0bbc :37:16 CONFLICT: Type I: Fragment 2 for table IM_ITEM has been altered at both sites (key: PDCID( )) W 0bbc :37:16 CONFLICT: Type I: Fragment 20 for table IM_ITEM has been altered at both sites (key: PDCID( )) D 0bbc :37:16 RecoverUnused() has found nothing to recover... resetting the transfer buffer D 0bbc :37:16 Committing transaction for database PD29BZ1P002. I 0bbc :37:16 Local field IM_ITEM.DESCR in conflict with partner value I 0bbc :37:16 Local: Green fee - 18 holes I 0bbc :37:16 Partner: Green fee - 18 holes Jen I 0bbc :37:16 Local field IM_ITEM.DESCR_UPR in conflict with partner value I 0bbc :37:16 Local: GREEN FEE - 18 HOLES I 0bbc :37:16 Partner: GREEN FEE - 18 HOLES JEN W 0bbc :37:16 CONFLICT: Type I: Fragment DESCR for table IM_ITEM has been altered at both sites (key: PDCID( )) W 0bbc :37:16 Type I conflict resolved - fragment DESCR will be updated at partner (Table IM_ITEM, key: PDCID( )) I 0bbc :37:16 Local field IM_ITEM.LST_MAINT_USR_ID in conflict with partner value I 0bbc :37:16 Local: JEN I 0bbc :37:16 Partner: Z W 0bbc :37:16 CONFLICT: Type I: Fragment LSTMNT for table IM_ITEM has been altered at both sites (key: PDCID( )) W 0bbc :37:16 Type I conflict resolved - fragment LSTMNT will be updated at partner (Table IM_ITEM, key: PDCID( )) To correct: To prevent: DXRE automatically resolves by using newest fragment (Not applicable) Type 1A Conflict Same fragment updated with same data by multiple sites W :21:15 CONFLICT: Possible Type Ia: Fragment 5 for table dsite has been altered at both sites (possibly to same value) (key: ) D :21:15 RecoverUnused() has found nothing to recover... resetting the transfer buffer I :21:15 No field differences found in fragment 5 of table dsite To correct: To prevent: DXRE automatically resolves by updating timestamp to most current, if time difference is large enough (Not applicable) Multi-Site 5-16 DXRE Troubleshooting

137 Type V Conflict Data already exists in database at remote site when database is activated and initial replication occurs with First Site. W 0e :32:37 CONFLICT: Type V: Starter data fragment 2 for table IM_CTL is different at both sites (key: 1) D 0e :32:37 RecoverUnused() has found nothing to recover... resetting the transfer buffer I 0e :32:37 Local field IM_CTL.AUTO_ADD_INV_METH in conflict with partner value I 0e :32:37 Local:! I 0e :32:37 Partner: * I 0e :32:37 Local field IM_CTL.LST_MAINT_DT in conflict with partner value I 0e :32:37 Local: 3/3/2005 1:24:23 PM I 0e :32:37 Partner: 3/17/2005 4:21:37 PM W 0e :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 0e :32:37 Acquired lock on table IM_CTL D 0e :32:37 Committing transaction for database PD29BZ1P001. D 0e :32:37 Released lock on table IM_CTL I 0e :32:38 SMSG: (pdre,33092)-unresolvable conflicts found while replicating CounterPoint (MultiSite) - PD29BZ1P001 E 0e :32:38 Unresolvable conflicts found while replicating CounterPoint (MultiSite) - PD29BZ1P001 To correct: To prevent: Set "dsetting <DSNName> PD_RESOLVE_TYPEV_CONFLICT Y" on remote system and manually initiate replication from that site to First Site. First 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. Ensure that no data exists in any table at a remote site when initially activating a database. Type VI Conflict Record inserted or updated by one site and same record deleted by partner site W 0a :35:54 CONFLICT: Type VI: A locally-deleted record in table PS_DRW_CLS has been updated at the partner site (key: PDCID( )[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. To correct: To prevent: 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". (Not applicable) Multi-Site 5-17 DXRE Troubleshooting

138 Unable to contact partner site Port 242 is not open on partner site, or is not open for this site's IP address D 010c :44:42 Network error during connect: No error (netaddr=mcostello). W 010c :44:42 Partner did not respond. D 010c :44:42 SMSG 9: Partner did not respond I 010c :44:42 SMSG: Partner did not respond D 010c :44:42 Network error for outbound session: No error. E 010c :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 :44:42 The remote site refused the connection, or was not listening. D 010c :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. To correct: To prevent: Did site's IP address change? If XP SP2 been installed, disable firewall or allow access from specific IP address. (Not applicable) Multi-Site 5-18 DXRE Troubleshooting

139 Resolving Duplicate Primary Key Errors Decide who "loses" This is the site at which you will need to delete the duplicate records. In general, First 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 First Site and a Remote, has the record already been replicated to the First Site's offline V1 workstations? It will probably take less time to delete the duplicate record (and any associated records) from the Remote's database. Multi-Site 5-19 DXRE Troubleshooting

140 Resolving Duplicate Primary Key Errors Correct the data No easy way to find all affected tables If data needs to be removed from multiple tables, must delete in proper order (enforced by foreign keys) Check associated tables (sort by Table Name) in Management Studio and start with last table - delete record from corresponding PDC table first - then delete record from user table If needed, use CounterPoint SQL to add a new record to replace record to be deleted - do not delete "old" parent record until foreign keys in dependent records are updated to point to "new" parent If record is part of a transaction or involves MSD values, renumbering the records may be a better solution than deleting them Use SQL Management Studio to delete or renumber records - login as pduser so that deletion/renumber doesn't replicate (triggers won't fire to update PDC control tables) - To remove: delete from <tablename> where <columnname>='<value>' - To renumber: update <tablename> set <columnname>='<newvalue>' where <columnname>='<oldvalue>' Multi-Site 5-20 DXRE Troubleshooting

141 Resolving Duplicate Primary Key Errors 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 :59:18 Optimized insert of AR_CUST record PDCID( ) failed, will retry E :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 :59:18 ODBC Error -1: (01000) '[Microsoft][ODBC SQL Server Driver][SQL Server]The statement has been terminated.' <3621,SQLExecute> E :59:18 ODBC statement failed: -1 from function Execute E :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"," _ADRS_1","FAX_1","P HONE_1","URL_1","CONTCT_2"," _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 :59:18 Unable to insert new record into table AR_CUST having key: PDCID( ),"1004" E :59:18 FSM:{An ODBC error occurred}: Unable to store next PD29BZ1P002.AR_CUST record from partner's data list (key:pdcid( )) D :59:18 Released lock on table AR_CUST I :59:18 SMSG: (pdre,33236)-update of AR_CUST in CounterPoint (MultiSite) - PD29BZ1P002 failed E :59:18 Update of AR_CUST in CounterPoint (MultiSite) - PD29BZ1P002 failed Multi-Site 5-21 DXRE Troubleshooting

142 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 First 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 "First 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 should also check to see if this customer and their ship-to addresses have been replicated yet to the offline V1 workstation connected to the Remote server. You could perform the same tests on the First Site system to determine which site's database will be easier to correct. After investigating, you determine that one ship-to address has been added for customer 1004 at the Remote server and that the change has not yet replicated to the offline V1 workstation. The customer added to the First Site system has two ship-to addresses that were entered. In this case, you will make the change to the data on the Remote server. Multi-Site 5-22 DXRE Troubleshooting

143 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 SQL 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 first and then 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 4. Recover To recover, simply replicate again. You can manually replicate or wait until the next scheduled replication. Multi-Site 5-23 DXRE Troubleshooting

144 Resolving Duplicate Primary Key Errors Example: Duplicate ticket number Examine the logs and pick a 'loser' as usual. To correct the cause of the conflict, develop a stored procedure that renumbers the 'losing' ticket. An example stored procedure is provided in Appendix 5 of this manual. The example will change the ticket number value only in the unposted ticket tables and requires that you edit the script prior to executing it to specify the 'old ticket number' and 'new ticket number' values. Execute the script in either Management Studio or the SQL Script Utility. A second script example is also supplied to change the ticket number value in the PDC control tables for the ticket tables. Multi-Site 5-24 DXRE Troubleshooting

145 Gift Certificate and Store Credit Problems Sharing Gift Certificates or Store Credits across stores To avoid problems: Use unique series of gift certificate 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 certificate 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 certificate or store credit number If two sites redeem the same gift certificate or store credit between replication sessions, when they do replicate, the "latest" redemption will automatically be used. Example: MAIN store redeems gift certificate #123 for $25.00 at 1:00 pm. EAST store redeems gift certificate #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 certificate #123 reflects as fully redeemed, but not over-redeemed by $ Paycode history shows both redemptions. - Ticket history shows both redemptions. - Distributions have been updated for both redemptions. Multi-Site 5-25 DXRE Troubleshooting

146 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 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. Double-check your Deployment.ini settings before running InstallServer.bat. One small typo can result in you have to spend a lot of time reading through logs to find the error and then correcting it. 5. 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. 6. 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. 7. 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. 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. 8. Deploy the exact same replication rules file and deployment file to all sites. If the package directories are identical at all sites, you won t encounter problems caused by activating databases using different rules or deployment settings. Multi-Site 5-26 DXRE Troubleshooting

147 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 that need to be delivered with Deployment tasks. Anything done as pduser Multi-Site 5-27 DXRE Troubleshooting

148 Other Replication Problems Slow Replication Potential causes: Improper tuning parameters (dsetting) QUERYCACHESIZE Amount of disk cache allocated to replication queries (CounterPoint's deployment scripts set this to ) Default bytes REPLBUFSIZE Size of data transmission packets in replication MINIMALTABLELOCKING Whether tables can be replicated simultaneously bytes Y Pushing back cutoff date of table If cutoff date of a table is pushed back (using PDFIXCUTOFF utility), it may result in many more records replicating than usual in the next replication session. MAXPUSHBACKLIMIT 0 (no limit) dsetting utility parameter used to set limit in days of how far back cutoff date can be changed. Updates older than that many days are rolled back and cause replication to stop with an error. Multi-Site 5-28 DXRE Troubleshooting

149 When to Use pdfixcutoff Use to set cutoff time in PDC table Log file message: D 10ec :57:11 pdre81042 Stamp field DDBT:PS_TKT_HIST_LIN-PDC1F1 indicates fragment F1(2) is older than cutoff time. Fragment will not be replicated (record: PDCID( )[PS_TKT_HIST_LIN]104930,0010,104, ,2). To correct: Table name pdfixcutoff /USERN=Admin /USERP=password /TA=PS_TKT_HIST_LIN PD29BZ1P001 " :00:00" Data Source name New cutoff time; this date sets to initial replication date/time, resulting in full replication of table Multi-Site 5-29 DXRE Troubleshooting

150 Changing Replication Performance Default registry settings work for 99% of all cases Consult with technical support before changing Windows Registry keys HKEY_LOCAL_MACHINE\SOFTWARE\DataXtendRE\Settings PKCONNECT_TIMEOUT PDIGNORE_NULLS_IN_CHAR_FIELDS PDMAX_REPLICATION_SESSIONS PDMAXTRANSPKTSIZE PDREPL_TIMEOUT Archive Log Directory Duration of time that DXRE should wait to establish connection to data source (default = no time-out) Whether replication session should end if an embedded NULL is detected in a CHAR or VARCHAR column (default = do not end if NULL is detected Maximum number of replication sessions that can be run simultaneously (default = no limit) Maximum packet size that can be transmitted at one time using TCP/IP (default = maximum of 1024 bytes) Amount of time that connection to another site should remain active without receiving data from that site (default = 5 minutes) Specifies the directory where expired log files containing errors are automatically archived. (default = delete and do not archive expired log files) DataXtend dsettings dsetting Utility to configure settings for replication engine See Appendix 3 for list of dsetting parameters Multi-Site 5-30 DXRE Troubleshooting

151 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 dacthist dactsite dexception didb dqueue dsched dset dsite dsitelnk dsiteset Multi-Site Use 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) Contains work set subscription information for subscribed sites Contains all exceptions for all tables GUID information for each table at each site. (Table is not replicated.) Contains commands that will be executed during replication. Records are deleted as they are processed. (Table is not replicated.) Contains replication schedule definitions Contains local and global replication settings (dsetting parameters) 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. 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. Contains site-specific settings for the last time site was successfully replicated and version of replication engine Appendix 1: DataXtend System Tables

152 Multi-Site Appendix 1: DataXtend System Tables

153 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 Utility ddumptbl dexpid dimpid dimprule dinst dmend dnareport dping dreclid dregevnt dresetdb dsetting dtrigger Description Outputs data in selected table. Decrypts timestamp fields in system tables. 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. To re-use GUID block previously exported with dexpid utility 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 Partners enabled database with replication engine at a site, creates data source name, and performs initial replication if replication engine is running 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. Produces report about replication engine configuration Checks network connection to target replication engine Reclaim missing GUIDs if site is condemned without first exporting GUID block; perform only at First Site Registers a.dll or.so, used for custom event handling After restoring older database, to reset available GUIDs to avoid introducing duplicates 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. Generates and loads replication engine triggers into database Multi-Site Appendix 2: Replication Engine Utilities

154 Utility duninst pdactivate pdchgpw pddbstat pddsn pdfixcutoff pdhorizon pdre pdrepl pdreset Description 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. Activates database at a site. Imports replication rules, activates site, and applies replication engine triggers to database. Change password associated with pduser Make a site's database available, unavailable, or just list it Adds, deletes, and lists ODBC data sources. Typically used when migrating to new hardware with same name/ip address as old hardware View or 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 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. Install, uninstall, start, restart, and stop replication engine remotely Replicates the specified data source Deletes system and control tables and replication triggers from database. Typically used after a site has been condemned and removed from the 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 pdupgrade pdwaitfor regbackup regrestore replcmd Manages replication schedule Upgrades replication rules associated with a database Specifies the length of time the replication engine should wait before starting a replication session Backs up replication engine's registry keys. Registry backup can be restored to migrate activated database to a new hardware platform or to rebuild a failed system. Restores replication engine's registry key from backup file. Replicates the specified database Multi-Site Appendix 2: Replication Engine Utilities

155 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 AUTOCOMMIT CHECKDEADSITES CLOCKTOLERANCE CONTINUEIFNEWER CLEANUPACTIVE LOCKTIMEOUT Description Forces replication engine to commit every update immediately Number of days replication engine waits before contacting a site that has not been replicated in the specified number of days. Default = 5 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) 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) 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). 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

156 Parameter MAXPUSHBACKLIMIT MAXTRANSACTIONSIZE MINIMALTABLELOCKING MUSTROLLFORWARDAGE PD_REPL_PRIORITY PD_REPL_QUOTA PD_RESOLVE_TYPEV_ CONFLICT QUERYCACHESIZE REPLBUFSIZE REPLICATEUNCHANGED TABLES Description 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) 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) 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 Number of minutes after which cutoff date is rolled forward. Value of 0 means update immediately. Default = 1440 minutes (1 day) Priority of each replication thread, either "Idle", "Low," "Normal," or "High". Default = Normal 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) Whether to automatically resolve Type V conflicts by allowing replication engine to select data from the complete site over an incomplete site. Default = N Amount of disk cache to allocate to replication queries, between and Default = (CounterPoint scripts set to ) Size of the data transmission packets used during replication, between and Default = Should unchanged tables be replicated, either "1" or "0"? Default = 0 (do not replicate if unchanged) Multi-Site Appendix 3: dsetting Utility

157 Appendix 4: Avoiding Replication Errors You can reduce replication errors by configuring your CounterPoint SQL 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 Setup / System / Company Setup / System / Users Setup / System / Workgroups Recommended Settings For Gift certificates 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 certificate and store credit to be used only once.) Do not use the Set up batches button to create DEFAULT batches. If you turn on passwords and select to use Windows authentication, use Setup / System / Workgroups to specify a different Domain Path for any workgroup whose domain path is different from the one you enter for the company. 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. Define a separate workgroup for each site, with the appropriate location and store for the site. Click the Set up batches button to create workgroupspecific 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 First Site, after all remote databases are activated, set "Site ID" for each workgroup to match the DataXtend site name. Also enable "Restrict site ID". Identify the Domain Path to use for verification of Windows passwords, if you enabled use of them in Setup / System / Company. Multi-Site Appendix 4: Avoiding Replication Errors

158 Menu Selection Setup / System / Menu Codes Setup / System / Security Codes Setup / Point of Sale / Stores Setup / Point of Sale / Stations Recommended Settings 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. 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. 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. 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 V1, 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. For Offline V2, select to auto-assign numbers. Restricted Menu Selections Make these menu selections available only at a single site, to avoid data conflicts during replication. System / Gift Certificates / Maintain Gift Certificates 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 Multi-Site Appendix 4: Avoiding Replication Errors

159 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 preferences (Setup / System / Configuration / Workstation Preferences) 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. Renumbering To avoid replication errors and database conflicts, perform all renumbering at the First Site. Be sure to replicate immediately before renumbering, and then again after renumbering. If remote or offline V1 sites update a record that references the old item number after the First Site has renumbered, you can expect replication errors. 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. Gift Certificates Store Credits CPOnline If you find it necessary to allow gift certificates and/or store credits to be redeemed at any store in the replication network, consider replicating frequently during the day. All CPOnline operations (publishing and importing) should be performed only at a single site. Multi-Site Appendix 4: Avoiding Replication Errors

160 Blank Site Chart Print and complete this chart for each site in your replication network. DXRE site name: Machine name: Location: Store: Stations: Next ticket number: Next hold ID: Next quote number: Next order number: Next layaway number: From: Station Store Station Store Station Store Station Store Station Store Multi-Site Workgroup: Next item number: Next customer #: Next vendor number: Next purchase request #: Next PO number: Next receiver #: Next RTV #: Next transfer #: Next gift certificate number: Next store credit number: Next event number: Next barcode: Users: Batches: Drawers: Offline V1 Ticket Entry: Next ticket number (OfflineV1): Next hold ID (OfflineV1): Next quote number (OfflineV1): Next order number (OfflineV1): Next layaway number (OfflineV1): Next store credit number (OfflineV1): Next gift certif number (OfflineV1): Next customer number (OfflineV1): Yes No Appendix 4: Avoiding Replication Errors

161 Appendix 5: Resolving Duplicate Ticket Numbers This is an example stored procedure that renumbers a duplicate ticket number in all unposted ticket tables. Following it is an example script that changes the ticket number in the associated PDC control tables. The script reflects the tables involved in V8.2.9 software, so there may be additional tables to consider for later versions. Prior to executing the stored procedure or using the PDC control script, you will need to modify the values of the 'OLD' ticket number and 'NEW' ticket numbers. -- Delete existing stored procedure if it exists page 1 if exists(select 1 from sysobjects where name = 'USP_RENUMBER_TKT') begin drop procedure USP_RENUMBER_TKT end go create procedure USP_RENUMBER_TKT -- Renumber a ticket --!!!!!!!!!!!!!!!!!! ASSUMES that ticket #'s are T_SQL_FLG = 0 as begin int set nocount on -- Old ticket must be on file if not exists (Select 1 from PS_TKT_HDR where TKT_NO begin = 'Old ticket (' + ') not on file' raiserror(@msg, 18, 1) -- For testing syntax, allow not on file values to be used = 0 return end = 'PS_TKT_HDR, ' + 'PS_TKT_PMT, ' + 'PS_TKT_GFC, ' + 'PS_TKT_LIN, ' + 'PS_TKT_CELL, PS_TKT_SER, PS_TKT_TAX, PS_TKT_TAX_LIN' Multi-Site Appendix 5: Resolving Duplicate Ticket Numbers

162 -- Now we start doing the work page 2 = 'N' = 0 begin begin transaction = 'Y' = 1 print 'Started transaction...' end = 1 print 'Calling USP_DORENUMBER...' = <> 0 begin = 1 print '...error in USP_RENUMBER' = 'Y' begin = 1 print 'Rolling back' rollback end return end = 'Y' begin = 1 print 'Committing' commit end end go select * from PS_TKT_HDR select * from PS_TKT_LIN select * from PS_TKT_PMT select * from PS_TKT_TAX select * from PS_TKT_TAX_LIN select * from PS_TKT_GFC select * from PS_TKT_CELL select * from PS_TKT_SER select * from PS_TKT_PROF_COD exec = = 'NEW' select * from PS_TKT_HDR select * from PS_TKT_LIN select * from PS_TKT_PMT select * from PS_TKT_TAX select * from PS_TKT_TAX_LIN select * from PS_TKT_GFC select * from PS_TKT_CELL select * from PS_TKT_SER Change 'OLD' to the incorrect ticket number and 'NEW' to the correct ticket number. Multi-Site Appendix 5: Resolving Duplicate Ticket Numbers

163 Script that updates the PDC control tables for unposted tickets: select * from PDCPS_TKT_TAX_LIN where CTKT_NO='OLD' update pduser.pdcps_tkt_tax_lin set CTKT_NO='NEW' where CTKT_NO='OLD' Change 'OLD' to the incorrect ticket number and 'NEW' to the correct ticket number for each table. select * from PDCPS_TKT_TAX where CTKT_NO='OLD' update pduser.pdcps_tkt_tax set CTKT_NO='NEW' where CTKT_NO='OLD' select * from PDCPS_TKT_GFC where CTKT_NO='OLD' update pduser.pdcps_tkt_gfc set CTKT_NO='NEW' where CTKT_NO='OLD' select * from PDCPS_TKT_PMT where CTKT_NO='OLD' update pduser.pdcps_tkt_pmt set CTKT_NO='NEW' where CTKT_NO='OLD' select * from PDCPS_TKT_CELL where CTKT_NO='OLD' update pduser.pdcps_tkt_cell set CTKT_NO='NEW' where CTKT_NO='OLD' select * from PDCPS_TKT_SER where CTKT_NO='OLD' update pduser.pdcps_tkt_ser set CTKT_NO='NEW' where CTKT_NO='OLD' select * from PDCPS_TKT_LIN where CTKT_NO='OLD' update pduser.pdcps_tkt_lin set CTKT_NO='NEW' where CTKT_NO='OLD' select * from PDCPS_TKT_HDR where CTKT_NO='OLD' update pduser.pdcps_tkt_hdr set CTKT_NO='NEW' where CTKT_NO='OLD' Multi-Site Appendix 5: Resolving Duplicate Ticket Numbers

164 Multi-Site Appendix 5: Resolving Duplicate Ticket Numbers

165 Appendix 6: Customizing CounterPoint SQL If you add custom tables or columns to CounterPoint SQL, 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 SQL. Follow these steps to set up the development system to produce the custom scripts and replication rules. (Refer to the Multi-Site online help for details on each step.) 1. Set up the development system. a) Install MSSQL 2005 or SSE b) Create the pduser database login (public and db_owner permissions) c) Install CounterPoint SQL and current service pack d) Install DataXtend Studio e) Create a new database (and apply the current mssql.sql script to it) or Copy the existing database from a "live" system - attach database - set connection string - associate pduser login with MSSQL/SSE on development system - if necessary, apply current UpdateFrom8.2.x script to database If 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) Copy Registration.hub to development system and rename it to Registration.ini g) Use System / Registration to generate the DataXtend Studio license files 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 6: Customizing CounterPoint SQL

166 3. Build an alter script that includes all schema changes and apply it to the development database until no errors are encountered. 4. Use 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 5. Deploy the alter script and custom replication rules. a) Copy alter script and custom replication rules to CPSQLPackages / ServerFiles / Custom on the First Site Server b) Copy Custom subdirectory to CPSQLPackages / WorkstationFiles on the First Site Server c) Set Deployment file parameters - ExtraCreateSchemaScripts or ExtraUpdateSchemaScripts - RulesFile d) On each server, including First Site, run the ActivateServerDatabase.bat Deployment task e) On each offline V1 workstation, run the ActivateWorkstationDatabase.bat Deployment task Multi-Site Appendix 6: Customizing CounterPoint SQL

167 Appendix 7: Changing the Rad Sync Port To use other than port 1968 on server for RadSync Change after Rad Sync service is installed on Server 1. Use Notepad to edit Radiant.Retail.Sync.Service.exe.config in CounterPoint / Sync directory on server. 2. Replace 1968 with the port number you want to use in the following two keys: <add key= ServicePort value= 1968 /> <add key= RemoteServicePort value= 1968 /> Multi-Site Appendix 7: Changing the Rad Sync Port

168 Multi-Site Appendix 7: Changing the Rad Sync Port

169 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. Multi-Site 1 Glossary

170 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. First Site is assigned ID (1 million) and each site activated after is assigned an ID that increments by 1 (e.g., , , 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 SQL 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 SQL, triggers are used to update the corresponding control table when a record is added, updated, or deleted in a user table. User Table CounterPoint SQL database tables for a company Multi-Site 2 Glossary

171 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. Multi-Site 3 Glossary

172 Multi-Site 4 Glossary

173 Multi-Site / Offline V2 Changes for V8.3.9 Both Multi-Site & Offline V2 CPSQL Prerequisites installable directly from DVD Launch menu Now includes.net Framework 3.5 SP1 Radiant hardware now shipped with all prerequisites, except SSE RadSync renamed to CP Services CP Services automatically installed on every CPSQL server, even non-ms/offline servers CP Services default port = view and change in Management Console When using SQL authentication for CPSQL company, must save SQL user password in connection string Management Console has additional tabs On Maintenance tab, configure a sleep window for CPServices and DXRE to allow database maintenance REV