TM-1400 AVEVA Plant (12.1) Administering Global Projects Rev 2.0

AVEVA Plant
(12.1)
Administering Global
Projects
TM-1400
www.aveva.com
AVEVA Plant (12.1)
Administering Global Projects TM-1400
www.aveva.com
2
© Copyright 1974 to current year.
AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
AVEVA Plant (12.1)
Revision Log
Date Revision Description of Revision Author Reviewed Approved
04/11/2011 0.1 Issued for Review PDMS 12.1.SP2 BT
13/03/2012 0.2 Reviewed BT OZK
14/03/2012 1.0 Approved for Training PDMS 12.1.SP2 BT OZK NG
14/05/2013 1.1 Issued for Review PDMS 12.1.SP4 BT
1.2 Reviewed BT
13/08/2013 2.0 Approved for Training PDMS 12.1.SP4 BT LB
Updates
In general, all headings containing updated or new material will be highlighted. However, highlighting has
not been employed at Revision 1.0 due to significant alterations to training material warranted by the release
of PDMS 12.1.
Suggestion / Problems
If you have a suggestion about this manual or the system to which it refers please report it to AVEVA
Training & Product Support at tps@aveva.com
This manual provides documentation relating to products to which you may not have access or which may
not be licensed to you. For further information on which products are licensed to you please refer to your
licence conditions.
Visit our website at http://www.aveva.com
Disclaimer
1.1 AVEVA does not warrant that the use of the AVEVA software will be uninterrupted, error-free or free
from viruses.
1.2 AVEVA shall not be liable for: loss of profits; loss of business; depletion of goodwill and/or similar
losses; loss of anticipated savings; loss of goods; loss of contract; loss of use; loss or corruption of
data or information; any special, indirect, consequential or pure economic loss, costs, damages,
charges or expenses which may be suffered by the user, including any loss suffered by the user
resulting from the inaccuracy or invalidity of any data created by the AVEVA software, irrespective of
whether such losses are suffered directly or indirectly, or arise in contract, tort (including negligence)
or otherwise.
1.3 AVEVA's total liability in contract, tort (including negligence), or otherwise, arising in connection with
the performance of the AVEVA software shall be limited to 100% of the licence fees paid in the year
in which the user's claim is brought.
1.4 Clauses 1.1 to 1.3 shall apply to the fullest extent permissible at law.
1.5 In the event of any conflict between the above clauses and the analogous clauses in the software
licence under which the AVEVA software was purchased, the clauses in the software licence shall
take precedence.
www.aveva.com
3
AVEVA Plant (12.1)
Copyright
Copyright and all other intellectual property rights in this manual and the associated software, and every part
of it (including source code, object code, any data contained in it, the manual and any other documentation
supplied with it) belongs to, or is validly licensed by, AVEVA Solutions Limited or its subsidiaries.
All rights are reserved to AVEVA Solutions Limited and its subsidiaries. The information contained in this
document is commercially sensitive, and shall not be copied, reproduced, stored in a retrieval system, or
transmitted without the prior written permission of AVEVA Solutions Limited. Where such permission is
granted, it expressly requires that this copyright notice, and the above disclaimer, is prominently displayed at
the beginning of every copy that is made.
The manual and associated documentation may not be adapted, reproduced, or copied, in any material or
electronic form, without the prior written permission of AVEVA Solutions Limited. The user may not reverse
engineer, decompile, copy, or adapt the software. Neither the whole, nor part of the software described in
this publication may be incorporated into any third-party software, product, machine, or system without the
prior written permission of AVEVA Solutions Limited, save as permitted by law. Any such unauthorised
action is strictly prohibited, and may give rise to civil liabilities and criminal prosecution.
The AVEVA software described in this guide is to be installed and operated strictly in accordance with the
terms and conditions of the respective software licences, and in accordance with the relevant User
Documentation.
Unauthorised or unlicensed use of the software is strictly prohibited.
Copyright 1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved. AVEVA
shall not be liable for any breach or infringement of a third party's intellectual property rights where such
breach results from a user's modification of the AVEVA software or associated documentation.
AVEVA Solutions Limited, High Cross, Madingley Road, Cambridge, CB3 0HB, United Kingdom
Trademark
AVEVA and Tribon are registered trademarks of AVEVA Solutions Limited or its subsidiaries. Unauthorised
use of the AVEVA or Tribon trademarks is strictly forbidden.
AVEVA product/software names are trademarks or registered trademarks of AVEVA Solutions Limited or its
subsidiaries, registered in the UK, Europe and other countries (worldwide).
The copyright, trademark rights, or other intellectual property rights in any other product or software, its
name or logo belongs to its respective owner.
www.aveva.com
4
Contents
1 Introduction .............................................................................................................................................. 7
1.1 Aim..................................................................................................................................................... 7
1.2 Objectives ......................................................................................................................................... 7
1.3 Prerequisites .................................................................................................................................... 7
1.4 Course Structure.............................................................................................................................. 7
1.5 Using this guide ............................................................................................................................... 7
1.1 Setting up the Training Course ...................................................................................................... 8
2 Concepts and Terminology .................................................................................................................. 11
2.1 Overview of AVEVA Plant Global ................................................................................................. 11
2.2 Locations ........................................................................................................................................ 11
2.3 Communications ............................................................................................................................ 11
2.4 Global Daemon............................................................................................................................... 12
2.5 Database Allocation....................................................................................................................... 12
2.6 Primary and Secondary Databases.............................................................................................. 12
2.7 Database Propagation ................................................................................................................... 13
2.8 Hub Administration........................................................................................................................ 13
2.9 Local (Location) Administration................................................................................................... 13
2.10 Non-propagating Files ................................................................................................................... 14
3 Setting Up a Global Project .................................................................................................................. 15
3.1 Installation and Set-up .................................................................................................................. 15
3.2 System Ping.................................................................................................................................... 15
3.3 Project Data .................................................................................................................................... 15
3.3.1 Project Variables ...................................................................................................................... 16
3.4 Creating a Transfer Folder ............................................................................................................ 17
3.5 Making the Project Global ............................................................................................................. 18
3.6 Global Extract Range..................................................................................................................... 19
3.7 Configure the Hub Location.......................................................................................................... 20
3.9 Creating a New Location and Location Files .............................................................................. 22
3.10 Copy Project to Satellite................................................................................................................ 23
3.11 Sharing folders on the Satellite .................................................................................................... 24
3.12 Testing Satellite Access ................................................................................................................ 25
3.13 Primary and Secondary databases at the Satellite..................................................................... 25
3.14 Satellite Users, MDS, and Extracts............................................................................................... 25
3.15 The Global Daemon ....................................................................................................................... 26
3.15.1 Checking / Updating the Global Client Configuration file ......................................................... 26
3.15.2 Daemon Start ........................................................................................................................... 27
3.15.3 Daemon Stop ........................................................................................................................... 27
3.15.4 Start and Stop the Daemons.................................................................................................... 27
3.15.5 Troubleshooting Daemon Start-up ........................................................................................... 29
3.15.6 Troubleshooting Daemon Stopping.......................................................................................... 30
3.16 Satellite Initialisation and Set-up.................................................................................................. 30
3.17 Check Global Communications.................................................................................................... 30
3.19 Initialising the Satellite Location .................................................................................................. 31
3.20 The Transaction Database ............................................................................................................ 31
3.20.1 Transaction Messages ............................................................................................................. 32
3.22 Transaction Timings ...................................................................................................................... 33
3.23 Creating an Update Event ............................................................................................................. 33
3.24 Creating Transfer Scripts .............................................................................................................. 34
3.25 Daemon Automatic Updates ......................................................................................................... 35
3.26 Transfer of Other Data ................................................................................................................... 35
3.27 Update Order .................................................................................................................................. 35
3.28 Update and Timing Considerations ............................................................................................. 35
3.29 Pending File.................................................................................................................................... 36
Exercise 1 - Making a Project Global.......................................................................................................... 37
4 Satellite Project Structure ..................................................................................................................... 39
4.1 Creating Satellite Users and MDBs Manually ............................................................................. 39
4.2 www.aveva.com
Remote Administration ................................................................................................................. 40
4.2.1 Manual Remote Access to a Satellite ...................................................................................... 40
5
AVEVA Plant (12.1)
4.2.2 Copying Admin Element to a Satellite Location ....................................................................... 41

4.3 Replicating the Project Structure ................................................................................................. 42
Exercise 2 – Creating Satellite Admin Elements ........................................................................................ 42
5 Unscheduled Database Updates .......................................................................................................... 43
5.1 Unscheduled Database Updates - System Databases ............................................................... 43
5.2 Unscheduled Database Updates - User Databases................................................................... 43
Exercise 3 – Unscheduled Updates ............................................................................................................. 44
6 Transaction Database Administration ................................................................................................. 45
6.1 Automatic Purging the Transaction Database............................................................................ 45
6.2 Manual Purging the Transaction Database ................................................................................. 45
6.3 Transaction Database Administration Summary........................................................................ 46
Exercise 4 – Transaction Database Administration................................................................................... 46
7 Databases in a Global Project .............................................................................................................. 47
7.1 Database Allocation....................................................................................................................... 47
7.3 Changing the Primary Location.................................................................................................... 49
Exercise 5 – Global Databases..................................................................................................................... 50
8 Testing AVEVA Plant Global Access in Design.................................................................................. 51
8.1 Creating a Zone at the Cambridge Hub ....................................................................................... 51
8.2 Checking Satellite Propagation .................................................................................................... 51
8.3 Database Status ............................................................................................................................. 52
Exercise 6 – Testing Global in Design......................................................................................................... 52
9 Global Daemon Service......................................................................................................................... 53
9.1 Single Project Service ................................................................................................................... 53
9.1.1 Desktop Interaction .................................................................................................................. 54
9.3 Multiple ProjectPservice ............................................................................................................... 55
9.4 Removing the Daemon Service .................................................................................................... 56
Exercise 7 – Global Daemon Service........................................................................................................... 56
10 Extract Databases.............................................................................................................................. 57
10.1 Standard Extracts .......................................................................................................................... 57
10.2 Working Extracts............................................................................................................................ 57
10.3 Creating an Extract Database ....................................................................................................... 58
Exercise 8 – Creating Extract databases in a Global Project ................................................................... 60
11 Working with Extract Databases in a Global Project ..................................................................... 61
11.1 Extracting Design Items in a Global Project ............................................................................... 61
11.3 User Claims .................................................................................................................................... 63
11.4 Flushing or Issuing Items in a Global Project............................................................................. 63
11.5 Updating the Extract Database..................................................................................................... 64
Exercise 9 - Working with Extract Databases in a Global Project ............................................................ 64
12 Data Access Control in a Global Project ......................................................................................... 65
13 Managing Databases in a Global Project ........................................................................................ 67
13.1 The Global System Database........................................................................................................ 67
13.2 The Local System Database ......................................................................................................... 67
13.3 Database Management .................................................................................................................. 67
13.3.1 Database Stamps..................................................................................................................... 67
13.4 Merging Changes in a Global Project .......................................................................................... 67
13.4.1 Remote Change Management ................................................................................................. 68
13.5 Backtrack Changes in a Global Project ....................................................................................... 69
13.6 Database De-allocation ................................................................................................................. 69
13.7 Backing Up and Restoring Global Projects ................................................................................ 69
13.8 Using Global to Distribute Catalogue Data ................................................................................. 70
Exercise 10 - Remote Merge......................................................................................................................... 70
14 Transaction Failures.......................................................................................................................... 71
14.1 Remote Merge ................................................................................................................................ 71
14.2 Allocation........................................................................................................................................ 72
14.3 De-allocation................................................................................................................................... 72
14.4 Claim ............................................................................................................................................... 72
14.5 Changing Primary Location .......................................................................................................... 73
14.6 Creating a Child Satellite of a Parent Satellite ............................................................................ 73
14.7 Correcting Reverse Propagation Errors ...................................................................................... 73
Exercise 11 - Correcting Reverse Propagation Errors .............................................................................. 76
www.aveva.com
6
CHAPTER 1
1 Introduction
This course is designed to familiarise AVEVA Plant Administrators with Global terminology and to give
detailed instruction of how to set-up an AVEVA Plant Global project with more than one location.
1.1 Aim
At the end of this Training Course the AVEVA Plant Administrator will have enough knowledge and
understanding to administer an AVEVA Plant Global Project.
1.2 Objectives
 Configure a Project for Global

 Create Locations.
 Test updating between Locations.
1.3 Prerequisites
All Trainees should have a good working knowledge of AVEVA Plant Administration or should have attended
AVEVA Plant Admin Basic and Advanced Training Courses.
It is assumed that the participants are familiar with the module ADMIN and have themselves administered a
project in PDMS.
1.4 Course Structure
Training will consist of oral and visual presentations, demonstrations and set exercises. Each workstation
will have a training project, populated with model objects. This will be used by the trainees to practice their
methods, and complete the set exercises.
1.5 Using this guide
Certain text styles are used to indicate special situations throughout this document, here is a summary;
Menu pull downs and button press actions are indicated by bold dark turquoise text.
Information the user has to key-in will be in bold red text.
Where additional information is presented, or reference is made to other documentation the following
annotation will be used:
 Additional information
 Refer to other documentation
System prompts should be bold and italic in inverted commas i.e. 'Choose function'
Example files or inputs will be in the courier new font, colours and styles used as before.
www.aveva.com
7
AVEVA Plant (12.1)
1.1 Setting up the Training Course
Use the Project Creation Wizard to create a new Training Project
Select Start > All Programs > AVEVA Plant > Design > PDMS 12.1.SP4 > Project Creation Wizard to
display the Project Creation Wizard form:
Click the Browse button to display the

Browse For Folder form.
Navigate to the C: Drive
Click the Make New Folder button.
Name the New Folder Globalproject
Click the OK button on the Browse For Folder

form to enter the new folder path and name in
the Address textbox of the Project Creation
Wizard form.
Enter the following data into the relevant

textboxes:
Project: Training
Code: TRA
Click the Create button.
The Project Creation Wizard create the

project and, if successful displays a message:
Click the Dismiss button on the Project

Creation Wizard form.
www.aveva.com
8
AVEVA Plant (12.1)
Login to PDMS Admin as the SYSTEM user using the details provided by the Trainer, for example:
Start > All Programs > AVEVA Plant > Design > PDMS 12.1 > Admin
Project: Training
Username: SYSTEM
Password: XXXXXX
MDB: <leave blank>
Click the Login button.
In Admin select Utilities >.Training Setup… from the main menu to display the Training Admin form.
Select the Training Setup Tab.
Enter 1 in the Number of Designers textbox.
Click the Create Project button.
The progress ar is display and textual feedback is

displayed on the Command Line.
Click the Close button on the Training Admin form.
Select Admin > Exit from the main menu and click the Yes button to confirm exiting Admin.
The Training project is now ready for the training course.
www.aveva.com
9
AVEVA Plant (12.1)
www.aveva.com
10
CHAPTER 2
2 Concepts and Terminology
2.1 Overview of AVEVA Plant Global
AVEVA Plant Global allows designers at different geographical sites to work on the same Project. Data is
automatically kept up to date using the best available communication method. The communication traffic is
kept to a minimum as only database changes are sent between these geographical locations. Global
projects can be administered centrally or locally.
2.2 Locations
Each geographical site is known as a Location and the main administration Location is the Hub.
There can only be one Hub, all the other Locations are Satellites. There can be many Satellites.
The network configuration for global is a tree structure and not fully connected. There is only one path
available between each location.
2.3 Communications
Communications between Locations are handled by the Global Daemon.
www.aveva.com
11
AVEVA Plant (12.1)
Unsuccessful Communications are stored in the transaction db or the project “pending” file, for future
execution.
A remote command traversing the Global network may be held up at a particular location. For example, due
to a communications fault. For most commands, the stalled command is placed in a transaction database at
that location.
The transaction database records the state of the command so that it can be processed later. This means
that commands are guaranteed to succeed at some time in the future, but that this time cannot be predicted.
More information about Monitoring the Global Command Progress in the transaction database is given later
in the course.
A small number of commands, known as ‘kernel’ commands, bypass the transaction database and are
stored in a pending file for later processing. An example is the RENEW command, which initialises a corrupt
transaction database.
Other kernel commands are ISOLATION; LOCK and UNLOCK and, in relation to a Satellite’s transaction
database, the ALLOCATE and CHANGE PRIMARY commands.
More information about the “Pending File” is given in the Global User Guide.
The pending file may be read in the project directory:
%PDMSEXE%/glbpend pending
2.4 Global Daemon
It is recommended that the daemon be run on the server, but it is not essential.
The daemon must remain running when updates across the network are made. The implication of this is that
a user must be logged on when the daemon needs to be running and the machines cannot be switched off
while daemon communications are required.
The normal way of running the global daemon is as a background service but it can be run as a batch file.
2.5 Database Allocation
 All databases are must exist at the Hub.
 Databases are allocated to locations that need read or write access to them
 Databases allocated to child Satellites are automatically allocated to their parents locations.
 Extract databases must have their parent database allocated.
2.6 Primary and Secondary Databases
As previously mentioned for a database to be accessible at a Location it must be allocated to the Location.
For Designers to be able to write to a Database, it must be Primary at the Location.
A Database can only be Primary at one Location. It will be Secondary at all other Locations to which it has
been allocated.
www.aveva.com
12
AVEVA Plant (12.1)
2.7 Database Propagation
Databases are updated with complete Sessions. Designers write to the Database at its Primary Location
and Savework (so creating new sessions).
The new sessions will be propagated to all Secondary Locations of the Database, only complete sessions
will be propagated.
Designers reading the database will not see any changes until the transfer is complete and they have done
a “Getwork”.
2.8 Hub Administration
The Hub is the only Location that can perform the following AVEVA Plant Administration tasks:
 Create Teams
 Create Master Database
 Create other Locations
 Create Roles
2.9 Local (Location) Administration
Any Location can carry out the following AVEVA Plant Administration Tasks:
 Create Users and MDBs

 Create extract Databases
 Create Update Events (normally only done at the owning Location to avoid overlaps)
 Unscheduled Updated which are two way.
 Note: Working Extracts can only be created and seen at the location they are required.
Remember all databases must and will exist at the HUB.
www.aveva.com
13
AVEVA Plant (12.1)
2.10 Non-propagating Files
The following files are not propagated by the Global Daemon
 Foreign Databases
 Isodraft Files
 External Plot files
 Copy databases
Any database can be non-propagating. For example, the administrator may not want to propagate DRAFT
picture files as these can be very large, with the exception of those used for symbol libraries.
www.aveva.com
14
CHAPTER 3
3 Setting Up a Global Project
In this chapter the following tasks will be completed:
 Install Global if not already installed.
 Create the Training Project (or the project that is to be made global)
 Create and use the Environment Variable for the Transfer Directory for each location.
 Lock Project and Make Global.
 Generate the Locations and allocate the DBs.
 Modify the PDMS batch file and create a batch file for the Global Daemon,
 Start the Daemon and Initialise HUB
 Copy the Project in the Transfer Directories to the Locations
 Start the Daemon at the Hub and Satellite Location, and Initialise Satellite Location
 Check Communications
 Set-up User-Defined Automatic Updates
3.1 Installation and Set-up
Install the global release on top of the PDMSEXE directory on hub and all satellites. The forms used in
Admin by Global are already included with standard AVEVA Plant. The extra items that are installed are the
Global Daemon (admind), the manuals, the Global daemon service executables and some example bat files.
3.2 System Ping
Perform system ping from the Hub to each location, i.e. open a dos command window at the HUB and enter:
ping sat_pc_1 (if sat_pc_1 is the machine name for satellite).
Do the same from satellite to HUB.
ping hub_pc (if hub_pc_1 is the machine name for satellite).
3.3 Project Data
A directory named Globalproject was created earlier at the root of the C: drive
Navigate to the C:\Globalproject\Training\tra000 directory and create a copy of the trasys file.
www.aveva.com
15
AVEVA Plant (12.1)
3.3.1 Project Variables
Navigate to the C:\Globalproject\Training directory, edit the Project batch file evarsTraining.bat. This file
sets all the project environment variables.
 The number of variables will change depending on what AVEVA products are loaded
set TRA000=C:\Globalproject\Training\tra000
set TRAPIC=C:\Globalproject\Training\trapic
set TRAMAC=C:\Globalproject\Training\tramac
set TRAISO=C:\Globalproject\Training\traiso
set TRADWG=C:\Globalproject\Training\tradwg
set TRADIA=C:\Globalproject\Training\tradia
set TRASTE=C:\Globalproject\Training\traste
set TRATPL=C:\Globalproject\Training\tratpl
set TRADFLTS=C:\Globalproject\Training\tradflts
set TRAINFO=C:\Globalproject\Training\trainfo
set TRAREPORTS=C:\Globalproject\Training\trainfo\REPORTS\tra
set TRA000ID=Training
The evarsTraining.bat file is called from the AVEVA Plant system batch file evars.bat; this file can be
found in the AVEVA Plant installed directory, typically C:\AVEVA\plant\PDMS12.1.SP4
Edit the evars.bat file. The line call C:\Globalproject\Training\evarsTraining.bat can be found at the
bottom of the file.
The project variable tra000 can be checked in AVEVA Plant by entering Q EVAR ‘TRA000’ on the
Command Line. This will return environment variable TRA000 C:\Globalproject\Training\tra000
www.aveva.com
16
AVEVA Plant (12.1)
3.4 Creating a Transfer Folder
A transfer folder is used to hold the satellite database files prior to copying them to the new location.
Create a transfer folder named oxf in C:\Globalproject\Training.
In the oxf folder create a sub-folder named Training
 Note: In earlier versions of PDMS it was necessary to create the standard directory structure i.e. tra000,
tramac, trapic traiso and tradflts. This is NOT required when using AVEVA Plant (12 Series).
Set an environment variable pointing to this directory of the form:-
set XXX_LOC=<transfer project directory location>
Where XXX is the project code, e.g.TRA, and LOC is the location identifier.
If the transfer directory for location OXF is C:\Globalproject\Training\oxf\Training the variable TRA_OXF
must be set to TRA_OXF=C:\Globalproject\Training\oxf\Training
Edit the Project batch file evarsTraining.bat and modify it to include the new satellite transfer directory.
www.aveva.com
17
AVEVA Plant (12.1)
3.5 Making the Project Global
Login to PDMS Admin as the SYSTEM user using the details provided by the Trainer, for example:
Project: Training
Username: SYSTEM
Password: XXXXXX
MDB: <leave blank>
Click the Login button.
 The MDB must always be unset when administering Global.
In Admin, lock the project by select Project > Lock from the main menu.
The Project status on the menu bar changes from Unlocked to Locked
Open the command window by selecting Display > Command Window … from the main menu.
 Don’
t forget to make a copy of the trasys file in case of any problems.
Enter Expunge in the Command Window to remove any users.
Enter Make Global in the Command Window to make the project Global. This may take a few seconds.
At this point the system database is written to and the global database (traglb) is created. The MAKE
GLOBAL command is irreversible. The project is now a Single Location Global Project.
An error message is displayed to exit AVEVA Plant.
Clcik the OK button.
Select Admin > Exit and restart AVEVA Plant as described earlier to activate the new Global Appware.
On entry to Admin an error message is displayed.
Click the OK button.
The Admin elements form is displayed with new choices in the

Elements options list, i.e. Locations, Location Groups and Update
Events. www.aveva.com
18
AVEVA Plant (12.1)
3.6 Global Extract Range
In order for Primary and Working Extracts to be created, AVEVA Plant needs to know the extract ranges, for
example, 0001 to 3000 will be used for Primary Extracts whilst 3001 to 3101 will be used for Working
Extracts at satellite location HUB and 3102 to 3202 will be used for working extracts at satellite location
OXF.
 Note: All global extracts are given an identifying number when they are created. Before starting to
create extracts an extract numbering system should be decided.
Before the working extracts are created the Global (Primary) Extract Range must be set.
Select Settings > Global Extract Range from the main menu to
display the Global Extract Range form.
Set the range From 1 To 3000
Click the Apply button and then the Dismiss button.
www.aveva.com
19
AVEVA Plant (12.1)
A question form is displayed asking if the hub should be initialised
Click the Yes button
A message form is then displayed stating that a transaction

database has been created.
Click the OK button
Exit and re-enter Admin with the same loin details used previously.
3.7 Configure the Hub Location
Select Locations from the Elements options list on the Admin elements form.
Select PROJECTHUB from the list and

click the Modify button to display the
Modify Location form.
A warning message is displayed
Click the OK button.
www.aveva.com
20
AVEVA Plant (12.1)
Enter CAMBRIDGE in the Name textbox (by default it is

named /PROJECTHUB)
Location ID is HUB
 In this case the Location is greyed out as the Hub is
initialised.
Enter Cambridge in the Description textbox (optional).
Connection will normally be left as On-line
Hostname is the identifier of the machine the Global

daemon will be run on at the Hub (HubServer).
Enter From 3001 and To 3101 for the Working Extract

Number Range.
Enter Cambridge Hub in the Description textbox at the

bottom of the form.
When the Apply button is clicked, the information is written to the global database, in this case “traglb”, and
a prompt to initialise the Hub is displayed, if it has not yet been initialised.
 The User Guide states:

Once the Hub has been initialised, it is not possible to change the following settings: Location
ID and Hostname.
However, it is possible to Modify these attributes by doing the following.
Stop the daemons at hub and satellites and in Admin navigate to the LOC element (/CAMBRIDGE in
this case) and set the LINIT flag to false. Modify the attribute and then change the LINIT flag back to
true).
 Note: The HUB must be initialised at some point.
www.aveva.com
21
AVEVA Plant (12.1)
3.9 Creating a New Location and Location Files
Before a new location can be created all the steps under the title of “Creating a Transfer Directory” must
have been completed for that satellite name.
Select Locations from the Elements option list on the Admin elements form. Select Create…
Enter OXFORD in the Name textbox.
Enter OXF In the Location ID textbox.
Enter Oxford in the Description textbox (optional)
Connection will normally be left as On-line
The Hostname is the identifier of the machine on which the

Global daemon will be running at the location. Enter the
name used when the ping hostname was entered, as
described earlier in System Ping.
The Check button can be used to check the Satellite

location
The Parent option will be set to the Hub name, i.e CAMBRIDGE, as this is the only option at this stage.
Group is unset as this is a concept for updates between children that is not fully implemented yet.
Enter From 3102 and To 3202 for the Working Extract Number Range.
Enter Oxford Satelite in the Description textbox at the bottom of the form.
Disable extract creating is discussed later.
When Apply is clicked, the Location is created
A question form is displayed to ask if all the Databases that exist at

the Hub are to be copied to the Transfer directory, ready for being
copied to the Location, is displayed. In this example, it is assumed
that this is confirmed and all databases are required at the satellite.
(If it is not then no databases will be allocated to the new satellite
location).
Click the Yes button.
 The Locid can contain numbers, but it must then be enclosed in quotes. e.g. Locid ‘
OX2’
www.aveva.com
22
AVEVA Plant (12.1)
The Databases will be transferred to the Satellite as Secondary Databases. The Primary Location can be
changed later after the following has been done:
 The files in the Transfer directory have been installed at the Satellite
 The Global daemons have been started at the hub and the Satellite
 The Satellite has been initialised.
If location generation includes copying all Databases that exist at the Hub to the transfer area, it can take
some time, according to the amount of data being copied.
 When the Apply button is clicked the information is written to the global database for the location, in this
case traglb. Once the communication link has been initialised (see Satellite Initialisation later in the
guide), the only safe way to change the machine specified for the daemon i.e. OXF is to copy the global
database manually to the Location. i.e. manually copy traglb from the HUB to the satellite OXF. The
same must be done if the name or the hostname of the satellite is changed.
This is exactly what would be done in a real project environment when the HUB and the Satellite are a
long distance apart. It is easier to set up the HUB and Satellite in the HUB office and then change the
hostname of the Satellite, copy the global database (e.g. traglb) from the HUB project directory to the
Satellite project directory.
3.10 Copy Project to Satellite
Copy the whole satellite project directory (OXF\Training) to the new satellite location into a directory called
C:\Globalproject (C:\Globalproject\Training).
The environment variable batch file (evarsTraining.bat) should also be copied to the satellite; this should not
need modification.
Copy any foreign projects to the satellite location as well and include the environment variables in the
evars.bat file.
 Note: The C: drive may need to be shared at the Satellite.
www.aveva.com
23
AVEVA Plant (12.1)
3.11 Sharing folders on the Satellite
In Windows Explorer navigate to the C:\Globalproject folder. From the the right click menu select Share with
> Specific people…
Select Everyone from the options list and click

the Add button.
Click the Share button at the bottom of the form.
The folder is now shared with everyone.
Click the Done button at the bottom of the form.
Navigation to the satellite from the hub can now be achieved using syntax similar to:
\\sat_pc_1\Globalproject
For example \\ukchel3604\Globalproject
www.aveva.com
24
AVEVA Plant (12.1)
3.12 Testing Satellite Access
Test that the satellite has been created correctly by entering Admin in the Training project on the satellite.
 Note when a satellite is created the System User name and password will have been reset to SYSTEM
password XXXXXX
The satellite location is displayed at the top of the main menu bar.
3.13 Primary and Secondary databases at the Satellite
If Databases & Extracts are displayed using the Admin elements form, it can be seen that all the databases
with the exception of the local transaction database have been displayed with a “-“ sign indicating that they
are Secondary at this location.
Databases that are Primary at this location are indicated with a “+” sign.
In order to write to a database it must be Primary at the Location.
With the exception of Create, the buttons are greyed out. If Create is selected it is onlyn possible to create
an extract database as all databases are created at the hub.
3.14 Satellite Users, MDS, and Extracts
As described above at the Satellite Users, MDS, Normal and Working Extract databases and Scopes can be
created.
Looking at Teams on the Admin elements form, the teams will be shown but they cannot be modified.
No Users, MDS or Scopes have been transferred from the Hub.
These items can be created or transferred from the Hub once the Daemons are running.
www.aveva.com
25
AVEVA Plant (12.1)
3.15 The Global Daemon
A pair of Global Daemons is required for each Global Project.
Prior to the PDMS 12.1.SP4 release Global was using the older style of Global Communication normally
called RPC for the Global Server (daemon).
RPC has low security and is prone to hacking.
The more modern way is to use the configurable WCF protocol for PDMS Global.
WCF is fully configurable, a set of example configuration files are supplied in the Global folder, by default
Global Server using WCF requires port 8000 open.
Changes to the firewall are not normally required when testing Global on a LAN inside the company firewall.
Typically users accessing the project using a VPN will require port 8000 open on the VPN and their PDMS
Global Client Config file set to WCF
3.15.1 Checking / Updating the Global Client Configuration file
Open the File globalWCFclient.config in the %pdmsexe% folder typically C:\AVEVA\Plant\PDMS12.1.SP4
search for the tag:-
<add key="GLOBAL_PROTOCOL" value="WCF" />
The value can be set to RPC or WCF, the value should be set to WCF; if it is set to RPC then the PDMS
session will be trying to use RPC to talk to the Global Server Daemons.
This must be done on every PC being used to administer a Global project.
 On the LAN inside the firewall it will probably work without doing this as the WCF daemon does receive
RPC calls form PDMS.
www.aveva.com
26
AVEVA Plant (12.1)
3.15.2 Daemon Start
A batch file should be created in the following format:-
set AVEVA_DESIGN_EXE=<Location of The Global folder>

set AVEVA_DESIGN_WORK=<Location of pdmswk folder>
call "<project variable file>"
"<Location of The Global folder>\admindwcf" start <Project Name>
pause
Create a batch file to start the Global Daemon named start.bat and place it in the Training directory
C:\Globalproject\Training.
In the file enter the environment variables for the global project:
set AVEVA_DESIGN_EXE=C:\Program Files (x86)\AVEVA\GlobalServer12.1.SP4;

set AVEVA_DESIGN_WORK=C:\TEMP
call "C:\GlobalProject\Training\evarsTraining.bat"
REM set DEBUG_ADMIND=1023
"C:\Program Files (x86)\AVEVA\GlobalServer12.1.SP4\admindwcf" start tra
pause
To allow for tracing of problems etc. replace the last line with the following:
Set DEBUG_ADMIND=1023
%PDMSEXE%\admind start TRA bef 1>> C:\ Globalproject\logfilename 2>&1
 If the output is set to go to a file the Location Hub and Ready message will not be displayed. If this
method is used when setting up a project the daemon it will need to be started manually when logging
in and will stop when logged out. It is advisable to set the Global daemon up as a service which is
described later.
3.15.3 Daemon Stop
Create a Daemon stop batch file named stop.bat. This is the same as the Start batch file with the start
replaced by stop.
3.15.4 Start and Stop the Daemons

www.aveva.com
27
AVEVA Plant (12.1)
A useful way of testing the Daemons is to start and stop them.
Double click the start.bat file
The Daemon will start and wait with the prompt

Ready…
Double click the stop.bat file
If the daemon does not stop there might be a problem with the IT Configuration. Information on IT
configuration for Global is given on the AVEVA web site and later in the document.
Repeat the process at the at the Satellite
 Examples of the start and stop batch files can be found in the Global Training Directory, typically
C:\AVEVA\Plant\Training\Global
www.aveva.com
28
AVEVA Plant (12.1)
3.15.5 Troubleshooting Daemon Start-up
Troubleshooting Daemon start-up information is given in the following sections.
3.15.5.1 Incorrect computer name
If the daemon doesn't start do the following:-
Stop the Global Daemon at the HUB.
Run Start.bat from a command prompt or put pause and the end of the bat file to check the error. It will may
be the hostname - the case must be the same as is entered in Computer Name. To check this open Control
Panel>Network.
Correct the hostname at the HUB. This will write to the traglb file. Copy this over to the satellite.
Re-start Global Daemon at the HUB
Re-start the Global Daemon at the Satellite
3.15.5.2 No UUID set
This can happen if a project is made global without Global being installed on the machine.
The UUId can be set at the Hub as follows:
In Admin at the Hub, navigate to /*GL
Enter Q NEWUID on the Command line.
Which will return a string similar to Newuid 5fc2846a-ce43-4ccf-b0ff-e605ad52abf5
Use the value to set the ADUUID by entering Aduuid ‘5fc2846a-ce43-4ccf-b0ff-e605ad52abf5’ on the
Command line.
This will write to the traglb file. Copy this over to the satellite.
www.aveva.com
29
AVEVA Plant (12.1)
3.15.6 Troubleshooting Daemon Stopping
If the daemon does not stop there might be a problem with the IT Configuration. Information on IT
configuration for Global is given on the AVEVA web site.
Alternatively theTrainer can provide a modification to the Registry using the file RPC.reg from the Global
Training directory, typically C:\AVEVA\Plant\Training12.1\Training\Global
3.16 Satellite Initialisation and Set-up
Make sure all project directories and foreign projects have been successfully copied to the satellite location
and the environment variables have been successfully created via the evars.bat file.
Start the Global Daemon at the HUB using start.bat
Start the Global Daemon at the Satellite using start.bat
Exit Admin at the HUB if not already done so
Enter Admin at the SATELLITE.
 The password at the Satellite will now be reset to the default XXXXXX.
3.17 Check Global Communications
At the Satellite in Admin select Query > Global Status > Communications from the main menu to display
the Test Project Communications form.
Select both locations in turn and click the Apply button.
A SUCCESS entry in the Ping Results pane indicates that the

ping was successful and the Global daemon at the location can
contact the Global Daemon at the location selected in the form.
Dismiss the form
www.aveva.com
30
AVEVA Plant (12.1)
3.19 Initialising the Satellite Location
Select Project > Initialise Location from the main menu or enter intilaise in the Command Window.
Exit from Admin and re-enter using the previous details.
 The Hub Administrator must exit from ADMIN and re-enter before the initialisation can be completed as
initialising a Location is an operation that requires the Global daemon to write to the Global Database.
Failure to do this will result in a misleading error message if Utilities>Transactions… is checked.
When the Satellite is initialised:
 The Satellite Administrator can start to create Users and MDBs in the usual way.
 The Hub Administrator can now make databases Primary at the Satellite.
 An Administrator, either at the Hub or at the Satellite, needs to set up Update Events, which control
when the daemons look for databases that need updating.
3.20 The Transaction Database
From the main menu, select Utilities>Transactions to display the Command Transactions form.
The Command Transactions scrollable list displays the Issue Date, Status and other information about
each Command issued. This combination of details for a command is known as a command transaction.
As a command progresses, the information displayed in the Command Transactions list is updated. If
desired, details of all the transaction messages for a specific command may be viewed by selecting the
command in the Command Transactions list, clicking the right mouse button and selecting Transaction
Messages to display the Transaction Messages form. This form shows all the transaction messages for
the command, from when the command was issued until it was completed:
The progress of the command can be checked using the right mouse button www.aveva.com
31
AVEVA Plant (12.1)
From the right click menu select Update:
When the command is finished the status will change to Complete and successful command will have the
Passed flag set to 1. If the INITILISATION command failed the Passed flag will beset to 0.
3.20.1 Transaction Messages
From the right click menu select Transaction Messages to display the Transaction Messages form.
As can be seen from the Transaction Messages, Global Commands may consist of more than one AVEVA
Plant Command.
If the Satellite Location fails to initialise it is possibly because an Administrator or User has crashed out at
the Hub.
Make sure that no one is in at the hub and possibly remove any rogue process and expunge all users at the
Hub.
The Message screen can be filtered using the radio buttons Messages, Successes, Failures and
Operations.
www.aveva.com
32
AVEVA Plant (12.1)
3.22 Transaction Timings
The transaction timings can be adjusted to optimise performance. This is the time between each AVEVA
Plant Command before the command times out or is retried.
Select Settings>Transaction Timings… to display the Transaction Command Timings form:
The default time settings are: Command Loop (All

Locations) time of 1 second Interval (Stalled Time)
30 seconds
These are the recommended Global settings and

would not normally be changed. Re-start the
daemons to activate any new timing.
 Note databases are updated using Update

events as described later.
3.23 Creating an Update Event
Update events are used to synchronise AVEVA Plant Databases and are two-way. Update event can be
created at the Hub or the Satellite and are normally created at the owning location so in our case at the
HUB.
In a working situation for a Hub that is the parent of e.g. 2 child satellites and no extract databases split
across locations a typical update event would be to update every hour Monday to Friday. This would allow
Saturday and Sunday to be used for typical maintenance of the project such as merging databasess and
reconfiguring. If extract databases are being used across locations this update shoule be increased to every
15 minutes.
For the purposes of the training, an Update Event every 2 minutes will be created to avoid waiting while
testing.
Enter AVEVA Plant at the HUB and select Update Events from the Admin elements form and click the
Create button to display the Create Update Event form:
Enter and select the following data:
Name CAM-OXF
Description Cambridge – Oxford
Select <LOC> OXFORD
www.aveva.com
33
AVEVA Plant (12.1)
Select the Frequency options list:
Select the Minutes options list:
Select the Frequency every 2 Minutes
Click the OK button and then the Apply button and Dismiss the
forms in turn.
A a batch file may be entered in the Transfer Script box so that

any other types of transfer can be done. This may be nothing to
do with AVEVA for example, it could be a timesheet or a plot.
 The Daemon must be stopped and restarted at the Hub for

these settings to take effect.
3.24 Creating Transfer Scripts
At the HUB create two batch files, one named C:\aveva\before.bat and one named C:\aveva\after.bat
Create two datafiles on the C: drive, one named C:\aveva\before.dat and one named C:\aveva\after.dat
The before.bat file should have a command similar to the following:
COPY /Y C:\aveva\before.dat \\ukmanl1724\c$
And the after.bat file should have a command similar to the following:
COPY /Y C:\aveva\after.dat \\ukmanl1724\c$
Test the batch file prior to including it in the Update Event. www.aveva.com
34
AVEVA Plant (12.1)
Save the Update event and stop and start the Admin Daemons
3.25 Daemon Automatic Updates
Checks pending file every 2.5 minutes.
Reads or re-reads System databases every 15 minutes.
Stopping and restarting the daemon forces the System databases to be read.
Hub daemon checks license file every 2.5 minutes.
3.26 Transfer of Other Data
Files such as Isodraft files, external plot files and Design manager files are not propagated automatically by
the global daemon. However, there is a mechanism in the daemon to allow such files to be transferred to
and from neighbouring locations. The daemon uses environment variables to define import and export
directories for other data files. At a location, there is a single directory to receive data imported from other
locations; and a set of export directories, one per neighbouring location, from which data can be exported to
those locations.
The import directory at a location is defined by an variable %IMPORT%. The export directory for
neighbouring location OXF is defined by variable %EXP_OXF%, etc. If these variables are defined at each
location, then the daemon will automatically transfer files in these directories from one Satellite to another
during scheduled updates (or when the UPDATE ALL command is used). Files can only be transferred
between neighbouring locations, and this method cannot be used to send files to/from off-line locations.
For example, myfile has been produced at Satellite OXF and is needed at a neighbouring location. The user
at OXF must ensure that myfile has been placed in directory %EXP_BBB%. During the next scheduled
update with BBB, this file will be sent to BBB, and received in directory %IMPORT% at location BBB. A
user at BBB can then use myfile. If myfile is to be sent on to other locations, it will need to be copied into
the export directories at BBB for those locations.
3.27 Update Order
The order that databases are updated is important. By default the databases are updated in random order.
To change the order to the recommendations set by AVEVA, i.e DICT, PROP, CATA, DESI, PADD select
Data>Database Allocation>Update Order… and click the Automatic Re-order button and then the Apply
button.
3.28 Update and Timing Considerations
Remember that automatic updates can take up to 15 minutes to take effect. This is because the daemon
checks the pending file every 2.5 minutes. This happens seven times before the system databases and the
update information is re-read. Thus, there is the possibility of a maximum delay of 15 minutes before
updates are started.
Generally, if data is required at locations quickly, frequent updates are required; also less data goes over the
'line', spreading it evenly through the day. However, a low speed connection between locations could
saturate the line causing problems if it is not a dedicated Global line. Less frequent updates mean that more
data will need to be transferred at one go. These types of updates are typically carried out during non-
working hours when the network traffic is reduced.
www.aveva.com
35
AVEVA Plant (12.1)
3.29 Pending File
The pending file is created in the project directory at the hub if the global daemon connection fails during
update. Check the status of the comms connection by using Query>Global Status>Communications. Do
this for HUB and Satellite.
If a pending file is created, it should disappear a few minutes after the daemon is running again. i.e. when
the connection is resumed. If there is a problem with the update this could result in the following situation. A
database may become Secondary at the HUB and Secondary at the satellite.
This can recovered this by selecting Data > Recove r> Primary Location from the main menu.
This is known as recovering a transient database. If there are none to recover an error is displayed
explaining this.
www.aveva.com
36
AVEVA Plant (12.1)
Exercise 1 - Making a Project Global

Using the above example make the Training Project (TRA) Global, Create a Satellite and a pair of Global
Daemons.
Check the access to both the Hub and the Satellite and that there is communication between the two.
Create an Update Event ready for Design Testing. Check that the transfer batch files can be executed.
www.aveva.com
37
AVEVA Plant (12.1)
www.aveva.com
38
CHAPTER 4
4 Satellite Project Structure

There are three ways or a combination of all three ways that the Satellite can be updated to include all the
Users, MDBs, etc., that are required.
1. Create the Users, MDBs, etc. manually

2. Copy the users, MDBs, etc. from the Hub by administering the Satellite from the Hub. (Remote
Administration.)
3. Create a Replicate Macro.
4.1 Creating Satellite Users and MDBs Manually
This method is not fully covered in this Training Guide. There is a limited set of items that can be created at
the Satellite as described above.
Enter AVEVA Plant Admin at the Satellite, confirm that admin items can be created by creating a user
called A.PIPE and an MDB called TESTMDB.
Also confirm also that Teams cannot be created.
Exit ADMIN at the Satellite.

www.aveva.com
39
AVEVA Plant (12.1)
4.2 Remote Administration
In this section the Satellite will be administered from the Hub and some Users and MDBs will be copied to
the Satellite.
Administration can be moved between locations as required so it is not necessary to have an AVEVA Plant
Administrator at a Remote Location.
Enter AVEVA Plant Admin at the HUB.
Select Locations from the Admin elements form.
Modify the OXFORD Location
Change the Admin Location from Local to CAMBRIDGE
Remember the progress can be checked using Utilities > Transactions.
Valid items can now be manually created at the OXFORD Location or citems copied from the CAMBRIDGE
Location to the OXFORD Location.
Once the Transaction has completed perform a “Getwork” as the Global Daemon is another user.
4.2.1 Manual Remote Access to a Satellite
Select the Location to be modified from the Admin main menu.
All the Admin windows will change to reflect the Satellite selected.
Similar to before, create a new user called A.STEEL and an MDB /STEELWORK
www.aveva.com
40
AVEVA Plant (12.1)
The information will be transferred to the Satellite by the update event following a Savework, this could take
some time. An update can be forced at any time using Unscheduled Database Update, described later.
Select Admin > Savework from the main menu.
4.2.2 Copying Admin Element to a Satellite Location
Admin elements, e.g. Users, MDBs, etc., can be copied from, for example, the Hub to a Satellite.
 Note in order to copy items from the Hub, the user must have administration of the Satellite.
In AVEVA Plant at the Hub select Local Administration. A User and an MDB will be copied from the
Cambridge Hub to the Oxford Satellite.
On the Admin elements form select Users
Select the user A.PIPER
Click the Copy element to Location button to display

the Copy to locations form.
Select the OXF - OXFORD Satellite
 The Password must be set
Enter A in the New Password textbox.
Enter A in the Confirm New Password textbox
Click the Copy button.
The information will be transferred to the Satellite by the update event following a Savework, this could take
www.aveva.com
some time. An update can be forced at any time using Unscheduled Database Update, described later.
41
AVEVA Plant (12.1)
Select Admin > Savework from the main menu.
Repeat the process for the MDB A-PIPING
4.3 Replicating the Project Structure
A common requirement is to replicate the project structure for Users and MDBs from the Hub to the Satellite.
All databases must be allocated at the Satellite before running the created macro.
Select Project>Replicate>Satellite Structure… from the Admin main menu at the HUB.
Save the file to a suitable directory
The User Passwords will not be included; the macro can be updated to include a suitable password.
For example:
ONERROR CONTINUE
Cname user SYSTEM SYSTEM
Create user 'A.SUPPORTMAN'/A General Description 'A SUPPORTMAN'
Create user 'A.STEELMAN'/A General Description 'A STEELMAN'
Create user 'A.ROOMMAN'/A General Description 'A ROOMMAN'
Create user 'A.PIPER'/A General Description 'A PIPER'
Create user 'A.HVACMAN'/A General Description 'A HVACMAN'
Create user 'A.ELECMAN'/A General Description 'A ELECMAN'
Create user 'A.EQUIPMAN'/A General Description 'A EQUIPMAN'
Create user 'A.CIVILMAN'/A General Description 'A CIVILMAN'
Create user 'A.CABLEMAN'/A General Description 'A CABLEMAN'
Exercise 2 – Creating Satellite Admin Elements
Using the above example create some users and MDBs at the OXF satellite using both remote
administration and by copying admin elements to a location.
www.aveva.com
42
CHAPTER 5
5 Unscheduled Database Updates

Databases will only be updated at the time interval specified by the Update Event. The system Administrator
can force database updates as required. This can be done to a specific database or to the system database.
5.1 Unscheduled Database Updates - System Databases
At the Hub make sure that the administered location is LOCAL.
Select Data > Update … from the main menu to display the Unscheduled Database Update form.
Select the Location OXF
Select All Databases from the Update options list.
Select System Databases from the Type options list.
Click the Apply button.
5.2 Unscheduled Database Updates - User Databases
Updating a User databse is similar to updating the System Databases described above. An individual
database or all User databases may be updated.
Selected User Databases All User Databases www.aveva.com

43
AVEVA Plant (12.1)
 Remember progress of these updates can be seen using the Transaction Form.
Exercise 3 – Unscheduled Updates
For the purposes of the training Update Events are every 2 minutes so all updates will go through very
quickly.
Run an unscheduled Update Event on the System Databases.
www.aveva.com
44
CHAPTER 6
6 Transaction Database Administration
The Transaction database stores global commands that have been issued. This database can soon become
quite large so it is necessary to merge it. Merging/purging a transaction database reduces and optimises the
size of the database by deleting old command data and removing "dead" space from it.
The transactions database can be merged or purged automatically, and the frequency and scope of the
operation may be set.
6.1 Automatic Purging the Transaction Database
Select Settings>Transaction dB Merge/Purge from the main ADMIN menu to display the Transaction dB
Merge/Purge form.
 See the Global User Guide for more details.
 If the transaction database becomes corrupt the transaction database file can be deleted after the
daemon has been stopped. The transaction database will be re-created when the daemon is re-started.
This can also be used instead of merging the database but all previous commands will be lost.
6.2 Manual Purging the Transaction Database
Select Utilities > Transactions to display the Command Transactions - Change form and select the
Purge/Merge transactions DB tab.
The Purge options list enables ALL, SUCCESS or FAILED transactions to be purged. The Older than
textbox enables transactions older than a specified number of days.
The Purge transaction DB and the Merge Transaction DB buttons will purge or merge the Transaction
database. www.aveva.com
45
AVEVA Plant (12.1)
For example:
Use the stop.bat file created earlier stop the HUB daemon.
On the Purge/Merge transactions DB tab click the Purge Transaction

DB button.
A confirmation message is displayed.
Click the Yes button.
6.3 Transaction Database Administration Summary
There are several ways to merge the transaction database:-
1. Set up a scheduled transaction merge using a Scheduled transaction Merge - users must be out of
ADMIN when it runs!
2. Stop the daemon and run MERGE CHANGES TRANSACTION/ABC. This can be used in conjunction
with Utilities > Transaction > Merge/Purge transactions DB tab
3. Keep the daemon running and issue REMOTE ABC MERGE CHANGES TRANSACTION/ABC, and
leave Admin.
The key is that there should only be ONE user accessing the Transaction database at the time it is merged –
so Admin users must have left for (1) and (3) above and the daemon must be stopped for (2).
MERGE does nothing unless the Transaction database is also purged. This is controlled either through the
Utilities > Transaction > Merge/Purge facility, or use Settings > Transaction db Merge/Purge and
selecting commands to be purged on the Scheduled Merge/Purge
If the administrator is trying to use the Utilities > Transaction > Purge/Merge transaction DB then the
daemon MUST be stopped
If the Administrator is trying to use Scheduled Merge/Purge (set up through Settings > Transaction db
Merge/Purge) or an ad-hoc REMOTE MERGE, then they should leave Admin but keep the daemon
running.
Exercise 4 – Transaction Database Administration
Automatically Purge the Transaction Database every 3 days.
If the Transaction Database is purged as described above, none of the records will be deleted as none were
created more then 30 days ago.
Start the Hub Daemon using the start.bat file.
www.aveva.com
46
CHAPTER 7
7 Databases in a Global Project
7.1 Database Allocation
All the databases that exist at the hub are copied to the Transfer directory, ready for taking to the new
Location, if the option was chosen when the Location was created.
If the option was note chosen, then all the DATABASEs that are required at the satellite need to be
allocated to it. Similarly, if a new database is created it may need to be allocated to a Satellite.
When the OXFORD Satellite was created the option was selected and all the database were allocated to it.
For the purposes of the training guide a new database is created

at the CAMBRIDGE Hub and allocated to the OXFORD satellite.
In this example a new master multi-write database named

PIPING/DESIGN is created at the Cambridge hub.
 Remember databases can only be created at the Hub.
Creating a database in this way does not allocate it to any

satellites.
www.aveva.com
47
AVEVA Plant (12.1)
Select Data > Database Allocation>By Database… from the main menu to display the Database
Allocation (By Database) form:
As shown on the Database allocation form database

PIPING/DESIGN is only allocated to the Cambridge
HUB.
The database can be allocated to the Oxford Satellite

using the arrows
Databases are allocated or de-allocate to suit. A + indicates Primary location and - indicates Secondary.
It is advisable to use macro input for long lists of databases allocations, for example:
ALLOCATE <db name> PRIMARY at /Satellite

ALLOCATE <db name> at /Satellite
etc.
This will most likely be the case when the Global project is initially created. It is advisable in a macro, to
leave a short pause between each allocation, because the daemon requires exclusive write access to the
global database while allocating. This will avoid the subsequent allocate commands being put into the
pending file. May take about 2 mins per database.
Allocate the new database PIPING/DESIGN to the Oxford Satellite and add it to the MDB A-PIPING at both
the Cambridge Hub and the Oxford Satellite
www.aveva.com
48
AVEVA Plant (12.1)
7.3 Changing the Primary Location
Make sure that there are no designers in the Project
Select Databases & Extracts from the Admin elements form options list. Select database
PIPING/DESIGN-AREA01-A and click the Modify button to display the Modify Database form:
In order to demonstrate extract databases later in the training, it

is necessary to have the database PIPING/DESIGN-AREA01-A
with its Access Mode set to Multiwrite.
Click the gadget at the right of the Primary Loc. text box to
display the Primary Location form:
This form lists all the initialised Locations defined in the Project.
Select the new Primary Location OXFORD from the Project

Locations list.
Click the OK button on the Primary Location form and then the
Apply button on the Modify Database form.
 This operation will update the Global Database without waiting for the next Update event, but it still may
not take place immediately.
To check the status of the command from the main ADMIN menu bar, Select Utilities>Transactions to
display the Command Transactions form.
If the selected database does not become Primary at the Satellite (indicated by a + on the Admin elements
form). The probable cause for this is that the database still has writers. This message will be output in the
window running the Global Daemon. E.g. 14:50 27/03/02 CHANGE_PRIMARY command - DB still has
writers
 The probable cause for this is that when Admin was entered, an MDB was set on the AVEVA Plant
Login form and the database that the Primary location is modifying is part of that MDB.
It is very important to remove the MDB when entering Admin when modifying the Primary Location.
www.aveva.com
49
AVEVA Plant (12.1)
Exercise 5 – Global Databases
As described above, create a new database PIPING/DESIGN, allocate it to the Oxford satellite and make
database PIPING/DESIGN-AREA01-A Primary at the Oxford satellite.
Check that database PIPING/DESIGN-AREA01-A is Primary at Oxford and that PIPING/DESIGN is

Primary at Cambridge by checking the + or – flag on the Database & Extracts form.
Confirm that both databases are in the A-PIPING MDB at both locations.
www.aveva.com
50
CHAPTER 8
8 Testing AVEVA Plant Global Access in Design
8.1 Creating a Zone at the Cambridge Hub
Access AVEVA Plant Design at the HUB with the User A.PIPER, Password A and the MDB /A-PIPING.
Navigate to the Site PIPING/DESIGN and create a new Zone named PIPING-ZONE with the Purpose set to
PIPE
Confirm that the SITE-PIPING-AREA01 site cannot be deleted as it is not Primary at the Hub Location
Select Design > Savework from the main menu.
8.2 Checking Satellite Propagation
Wait for 2 minutes for the update event to take place
Access AVEVA Plant Design at the Oxford Satellite; using the System user, Password XXXXXX and MDB
/A-PIPING.
Confirm that the new Zone has been created.
If the changes do not appear, then the daemon communication update has been beaten. Wait until the next
update before performing a GETWORK.
www.aveva.com
51
AVEVA Plant (12.1)
8.3 Database Status
Entering STATUS on the Command Line to verify if the database is Secondary at the location. Even if the
user is a member the Team of that database, they will still not have access to write to the database.
Status at the Cambridge Hub Status at the Oxford Satellite
Exercise 6 – Testing Global in Design
Using the above examples create some items in AVEVA Plant Design and check that they are propagated to
the other location.
www.aveva.com
52
CHAPTER 9
9 Global Daemon Service
The normal way of running the Global daemon is as a service. The files required are in the PDMSEXE
folder.
There are two services provided, one for a single project and one for multiple projects.
 To run the daemon as a service, the project directory and the daemon files must be on a local drive,
since the service cannot map network drives.
The installation of the service must also be carried out locally.
9.1 Single Project Service
A service batch file named singleds.bat is required. Typical contents of this file are: -
rem Must set a username

call set USERNAME=globaldaemon
set PDMSEXE=C:\AVEVA\Plant\Manage\GlobalServer12.1.1
set PDMSWK=C:\TEMP\PDMSWK
call "C:\Globalproject\Training\evarsTraining.bat"
rem set LM_LICENSE_FILE=744@<SERVERNAME>
call start %PDMSEXE%\admind %1 TRA service
To install a single project service for project TRA, in a MS-DOS window navigate to the Global Executable
directory typically:
cd C:\AVEVA\Plant\Manage\GlobalServer12.1.SP4
and enter:
DemonServiceSingle /install /project TRA /location C:\Globalproject\singleds.bat
Select Start > Control Panel> Administrative Tools >Services and find AVEVA Global Single Project.
www.aveva.com
53
AVEVA Plant (12.1)
Select Properties… and then select Automatic so the daemon will

start when re-booting the machine.
Click the Start button.
9.1.1 Desktop Interaction
Select the Logon tab.
Check the Allow Service to Interact with Desktop checkbox. This

means that a window will be opened for each daemon:
This may be useful when setting up a project or tracking any

communication problems.
If for any reason the service will not start, it is possible to run the service from a MS-DOS window using the
syntax:
demonServiceSingle /debug
This will assist in identifying the cause of the problem , for example, the Project directory has not been set-
up.
www.aveva.com
54
AVEVA Plant (12.1)
9.3 Multiple ProjectPservice
A service batch file named multis.bat is required. Typical contents of this file are: -
rem echo off

rem Must set a username
call set USERNAME=globaldaemon
set LM_LICENSE_FILE=744@<SERVERNAME>
set PDMSEXE=<Location of PDMS folder>
(e.g. set PDMSEXE=C:\AVEVA\Plant\Manage\GlobalServer12.1.x)
set PDMSWK= <Location of pdmswk folder (e.g. C:\AVEVA\Plant\Data12.1.x\pdmswk >
call C:\Globalproject\evarsTraining.bat
call C:\Globalproject\evarsMaster.bat
rem Start daemons in new windows, specifying window Title

start "Project TRA - PDMS Global Daemon" %PDMSEXE%\admind %1 tra service
start "Project mas - PDMS Global Daemon" %PDMSEXE%\admind %1 mas service
To install a multi project service for projects, in a MS-DOS window navigate to the PDMS12.1.SP4 directory
and enter:
DemonServiceMulti /install /location C:\Globalproject\multids.bat
The line to start the admind must be exactly the same as is shown above. Failure to do this will create a
situation where the daemon cannot be stopped using the service, only by re-boot. This can result in the
license not being released after re-boot. To release the license use the syntax:
Lmremove GLOBAL SYSTEM alt23 at23
Open Control Panel > Administrative Tools >Services and find AVEVA Global Multi Project. Select
Startup… and select Automatic so the daemon will start when re-booting the machine.
If for any reason the service will not start, it is possible to run the service from a MS-DOS shell using the
syntax:
DemonServiceMulti /debug
This will assist in identifying the cause of the problem (for example, Project directory not set up)
 If the installation is unsuccessful, remove the service and install it again:

If multiple projects are being used, the Global daemons for all the projects will be started. Individual
deamons cannot be stopped and started: if one daemon needs to be stopped but others do not, stop
the service, edit the file to remove the daemon to be stopped, and then start the service again. If
Startup on the Services form is pressed, another form is displayed that allows the start-up the service
automatically when the computer is re-booted.
www.aveva.com
55
AVEVA Plant (12.1)
9.4 Removing the Daemon Service
The Daemon service can be removed from the computer using the following syntax in an MS-DOS window,
as appropriate:
cd C:\AVEVA\Plant\Manage\GlobalServer12.1.SP4
Demonservicesingle /remove or Demonservicemulti /remove
Exercise 7 – Global Daemon Service
Create a new batch file for a single daemon service and install the service. Remember that the line that
starts the daemon must be in the same format as is shown in the examples and not the same as in the
manual start batch file.
Start the daemon as a service at both hub and satellite and check global communications at both locations
to ensure the daemons have started successfully.
www.aveva.com
56
CHAPTER 10
10 Extract Databases
All global extracts are given an identifying number when they are created. Before creating extracts, the
extract numbering system should be thought through, see example below.
Databases can be given numbers in the range 1 to 255,000, and for each of these, working extracts
numbered in the range 1-8191 can be allocated.
Numbers in the range 250,001 to 255,000 are reserved for AVEVA use, as are numbers in the range
7,001 to 8000, from previous releases, e.g. catalogues supplied by AVEVA has the PDMS DB Number in
the 7000 range.
However, a working extract can only be seen at its location (not globally), so to avoid database working
extract number clashes a working extract number range needs to be set for each location.
For each database master:
Range Type Number Range

Global, Normal Extracts (seen wherever allocated) 1 - 3000
Working Extracts - Location HUB 3001-3101
Working Extracts - Location TWO 3102-3202
(allowing this location 100 working extracts
of the Master database)
Working Extracts - Location THREE 3203-3303
The Working Extract Number Range settings allow the extract number ranges to be specified in
accordance with an agreed numbering system.
10.1 Standard Extracts
Extracts can be created at any Location: The owning database, master or extract, must be allocated to the
Location first. Like other databases in a global project, extracts have a Primary Location, and this need not
be the same as the Primary Location of the parent database. By default, the Primary location of the new
extract will be the current Location.
For standard extracts, the extract must be ceated at the hub and then allocated to the satellite, so it will
always exist at the hub. Working extracts can be created locally at the satellite. These exist at one location
only and hence cannot be allocated to the hub.
10.2 Working Extracts
Working extracts can only be created at the location where the parent extract is Primary. Working extracts
do not need to be added to Mds. When an MDB that includes databases that have working extracts is
selected, data will actually be written to the working extract.
 Note: Extracts that have a different location than the parent location will place a heavier demand on the
global daemon when doing such operations as claiming, flushing, etc. For this reason extracts that
have a different parent location should only be used where necessary.
www.aveva.com
57
AVEVA Plant (12.1)
10.3 Creating an Extract Database
This section describes how an extract database, that is Primary at another Location to where the Master
database is Primary, can be created and how Designers are able to write to the extract at a remote location.
Master Database PIPING/DESIGN-AREA01-A is currently Primary at the Oxford Satellite, an extract of this
database is created and made Primary at the Cambridge Hub.
The existing PIPING/DESIGN-AREA01-A is then removed from the A-PIPING MDB and replaced with the
New Extract PIPING/DESIGN-AREA01-A-EX
Designers will then be able to write to the extract database at the Cambridge Hub.
Select Databases & Extracts from the Admin

element option list.
Click the Create button to display the Database &

Extracts form.
Select the An Extract of a DB radio button
Click the OK button to display the Create Extract

form.
Select PIPING/DESIGN-AREA01-A in the Select Database for

Extract list.
Select PIPING in the Owning Team list.
Enter DESIGN-AREA01-A-EX in the Name checkbox.
Enter Extract of AREA01 Piping Database in the Description

textbox.
Select CAMBRIDGE from the Primary Location options list.
www.aveva.com
58
AVEVA Plant (12.1)
Select MDBs from the Admin elements options list.
Select MDB A-PIPING from the list and click the Modify
button to display the Modify Multiple Database form.
The Current Database list shows that the database

PIPING/DESIGN-AREA01-A has been replaced by the
extract database PIPING/DESIGN-AREA01-A-EX
The X adjacent to the name indicates that it is an

extract database.
Click the Apply button.
As the creation of the Extract database is carried out by another user, i.e. the Global Daemon, a GETWORK
will need to be performed.
www.aveva.com
59
AVEVA Plant (12.1)
Exercise 8 – Creating Extract databases in a Global Project
Create an Extract database called PIPING/DESIGN-AREA01-A-EX based on PIPING/DESIGN-AREA01-A

as described above, Primary at the Cambridge Hub.
Remember to Savework and Getwork.
www.aveva.com
60
CHAPTER 11
11 Working with Extract Databases in a Global Project
In this chapter several pipes from one location will be extracted to another location ready for modification at
that location. The Pipes can then be modified individually ready for passing back to the master database
collectively.
11.1 Extracting Design Items in a Global Project
Enter the AVEVA Plant Design module as User A.PIPER, Password A and the MDB A-PIPING.
 Remember the A-PIPING MDB now has an extract of the master database PIPING/DESIGN-AREA01-
A which is Primary at the OXF Satellite.
Select the Zone ZONE-PIPING-AREA01 from the Site SITE-

PIPING-AREA01.
Select Design > Extract Control …. from the main menu to

display the Extract Data Control form.
Select ZONE ZONE-PIPING-AREA01 from the Elements list.
Select the Element Hierarchy radio button in the Scope frame of

the Extract DB Operations area of the form.
Click the Extract button.
A message is displayed.
Click the OK button on the message form.
Click the Status button to display the Command Transactions

form.
www.aveva.com
61
AVEVA Plant (12.1)
Use the right click menu

Update function to refresh
the list.
Wait for the Transaction to complete before continuing.
Select Extract Claimlists to display the Extract Claim List form.
This form shows the items claimed to the Extract Database.
Navigating in the Extract Data Control form will refresh the

Elements List.
Note that prefixes are displayed in Elements list.
Click the Prefix Info button to display the Prefix Information form.
All the pipes in the zone ZONE-PIPING-AREA01 have been extracted to the local location
Extract Claims are not the same as User Claims; the above items have just been claimed to the database
and there are no user claims as can see by clicking the User Claimlists button.
 Extract Claims are persistent, i.e. they are not lost when the AVEVA Plant session is ended.
www.aveva.com
62
AVEVA Plant (12.1)
11.3 User Claims
Select Utilities > Claimlists from the main menu to display

the Multiwrite Claim Lists form.
As described above, no User Claims have been made.
Navigate to a Pipe /100-B-1 in Design Explorer
Select Claim > CE from the Multiwrite Claim Lists form

menu to claim the pipe branches.
 This is a User Claim and will be lost when the Designer

leaves AVEVA Plant.
11.4 Flushing or Issuing Items in a Global Project
Flushing makes the information available in the owning database but the elements are still claimed to the
extract. Issue makes the elements available and releases thecClaim. When working in a global project it is
normal practice to issue, where possible, batches of items. In this example all the pipes in the PIPE Zone
are issued.
Select Design > Extract Control… from the main menu to display
the Extract Data Control form.
Navigate to the zone Zone-PIPING-AREA01 in Elements list.
Click the Issue button.
All the extract claims will be released and the Extract Data Control
form updated.
www.aveva.com
63
AVEVA Plant (12.1)
11.5 Updating the Extract Database
When working with extract databases it is always necessary to update the extract to reflect any changes
performed by other designers.
Failure to do this will mean that the user is working on an outdated copy of the data. This is the extract
equivalent of Getwork.
Select Design > Extract Control… from the main menu to display
the Extract Data Control form.
Click the Get All Changes button.
Exercise 9 - Working with Extract Databases in a Global Project
Using the above example Extract, Claim and Issue a zone containing some pipes.
www.aveva.com
64
CHAPTER 12
12 Data Access Control in a Global Project
Data Access Control (DAC) is described in the AVEVA Plant Admin User Guide. There are a few points to
note when using DAC in a Global project.
ROLE elements can only be created at the Hub of a Global project:
DAC elements such as Scopes, Access Control Rights, etc. are created locally. They are not propagated
from the Hub.
The Hub Administrator is responsible for switching DAC on and off for the whole project. Ensure there are
no General users in the project at any location before DAC is switched on.
www.aveva.com
65
AVEVA Plant (12.1)
www.aveva.com
66
CHAPTER 13
13 Managing Databases in a Global Project
13.1 The Global System Database
The Global database contains information that is common to all Locations running a Global project. The
Global database is readable at all locations but it can only be written to at the Hub. Changes to the Global
database are propagated to all the other Locations. This means that the Global database is the same at
every Location, except during the short time changes are being propagated.
13.2 The Local System Database
Each local System Database contains project information that is specific to the Location. The local
Administrator can write to the local System database. A local System database is similar to the System
database in a non-global Project. The main difference is that some of the standard Admin elements will be
redundant. Session information is stored separately in the COMMs database; and the MISC database stores
inter-db macros and messages.
The Comms and Misc databases are local to each Location. The communications world element in the
COMMs database contains the project lock and isolation flags. The project lock may be set or cleared using
LOCK and UNLOCK; and the Isolation flag may be set true or false using ISOLATION syntax. Both lock
and isolation may be set or queried remotely by the Hub or an administering location.
13.3 Database Management
It is important for a System Administrator to consider merging (compressing) databases. Each organisation
will have different working practices but may wish to consider merging databases on a daily basis. Each time
a user does a SAVEWORK, a new database session is created, so for any working day there may be
hundreds of sessions added to a multiwrite database.
These can be merged into one session for each day. This would keep the number of sessions per year to a
manageable 300-400 sessions. Older sessions could be further compressed to weekly or even monthly
increments, whereas newer data compression could be delayed by a day or merged into hourly increments,
prior to the daily merge, to allowing more accurate backtracking if necessary.
The above information is given as a guideline for consideration but each organisation needs to decide on
their own course of action.
13.3.1 Database Stamps
Database sessions included within a Stamp are considered permanent and are not removed when a
MERGE CHANGES command is given.
13.4 Merging Changes in a Global Project
Databases can only be merged at their Primary locations. It is important to note that when a project
database is merged, the database sessions will be lost. Thus the ability for Global to send only session
changes is lost too.
It is therefore recommended that a Remote Merge operation is carried out on the project database, as this
also synchronises and merges the database at all Secondary locations automatically (unless the database is
non-propagating). This prevents propagation of the entire database on the next update.
Although it is named Remote Merge it can be applied from the Hub on Primary databases in the Hub.
www.aveva.com
Typically for a database named, say, PIPING/DESIGN that is Primary at the hub the syntax would be:
67
AVEVA Plant (12.1)
REMOTE HUB MERGE CHANGES PIPING/DESIGN
For a database that is Primary at a Satellite named OXF the syntax would be:
REMOTE OXF MERGE CHANGES PIPING/DESIGN-AREA01-A
Merging of dtabases should be done when there is no update

event taking place. This should be taken into consideration when
setting up the Update event. One method would be for no updates
to take place on Saturday and to allow merging to be done.
Schedule Updates can also be suspended on the Modify Update

Event form by checking the Suppress Scheduled Updates
checkbox.
13.4.1 Remote Change Management
Selecting Remote> Global Change Management> Global Merge Changes from the main menu displays
the Remote Merge Changes form.
www.aveva.com
68
AVEVA Plant (12.1)
13.5 Backtrack Changes in a Global Project
Remote Backtrack Changes works in a similar way to revert by creating a new session based on a previous
session.
13.6 Database De-allocation
If a database is no longer needed at a Satellite, it can be de-allocated. The de-allocation process requires
the database to be Secondary at that location and no users to be accessing an MDB containing that
database. De-allocating a database from a location which is the parent of the Primary location cannot be
achieved. A database must be allocated to all locations between the Hub and its Primary location.
To de-allocate a database use the following syntax on the Command Line at the HUB:
DEALLOCATE <DB/NAME> AT <LOC>
Where <DB/NAME> is the database name and <LOC> is the Satellite name.
13.7 Backing Up and Restoring Global Projects
Backing up projects is good practice in any environment and all files at all locations should be backed up
regularly.
If a Global project needs to be restored, extra attention must be given to any restoring process that is carried
out.
Project databases mabe be able to be restored using the Recover option. This may minimise work loss.
Backups for a location should only be used for that location, if possible. In some cases the only option may
be to use backups from other locations. If so, be aware of the implications it could have on the amount of
work lost.
The transaction databases may need to be re-created at locations using the RENEW command. For
information about this command and others, refer to the AVEVA Plant Design Global Command Reference
Manual.
 If the transaction database file has been deleted, it will be re-created automatically when the daemon is
started.
Remember the global database at the Hub is the master global database. This should be backed up before
any major Global administration work is carried out. www.aveva.com
69
AVEVA Plant (12.1)
13.8 Using Global to Distribute Catalogue Data
Global can be used to distribute the catalogue databases around the world so that projects can include them
as foreign databases. It should also been noted that a project cannot include a database from a Global
project unless the project itself is Global, i.e. the MAKE GLOBAL command has been executed on the
project.
Therefore, in order to have a set-up where there are several projects all using a Global distributed project,
they themselves must be Global, in the MAKE GLOBAL sense: They do not have to be distributed
themselves. Single location Global projects do not require a Global licence.
Single location Global projects may be created and made global at their resident location. The catalogue
data can then be included in the usual way.
If there are many multiple-location projects that share this project, then it will be necessary, because of the
HUB licence, to create and make each project global at the HUB and then copy them to their eventual
resident locations. The catalogue data can then be included in the usual way.
Exercise 10 - Remote Merge
Use Remote Merge to merge the changes on database PIPING/DESIGN-AREA01-A. Remember to pause
the Update Event.
www.aveva.com
70
CHAPTER 14
14 Transaction Failures
Reasons for failures of commands can be found in the Transactions Messages window. Messages such as:
shows failure due to the satellite being unavailable. This may be due to the communications link being down.
14.1 Remote Merge
Remote Merge can be lost due to the above failure and also if the error messages 'Prevented reverse
update' or 'Prevented reverse copying' are displayed in the Transaction Message window.
If the message 'Prevented reverse update' appears in the Transaction Message window, this means that the
session data or the header page at the Secondary location is greater than at the Primary location.
The usual cause of 'Prevented Reverse update' is that in a three location network, for example), Satellite A
has updated with Satellite C without going through the Hub (Location B). Checking the session number at
each location should give information as to the difference in session numbers.
If the message 'Prevented reverse copying' appears in the Transaction Message window, this means that
the NACCNT (Non-additive Changes Count) of the session at the Secondary location is greater than at the
Primary location. There are a number of causes of 'prevented reverse copying':
 Satellite A has updated directly with satellite C without going through the Hub
 Updates have been running during a REMOTE MERGE command
 The database at the Primary location has been deleted without the files for all Secondary location
databases having been deleted
It may be necessary to recover the database at the Secondary location to solve the problem.
www.aveva.com
71
AVEVA Plant (12.1)
14.2 Allocation
For a database to be allocated it must copy all allocated databases to the location, before the allocate
command can be processed. Messages such as:
show that all databases have been copied, but it failed to commit the changed allocation. This may occur
because the link between the Hub and the Satellite has failed/timed out.
Messages such as:
show that the location may be claimed by another user, e.g. the administrator of the satellite. In all cases of
a failed allocation, Global will leave the databases as they were before they failed, so the command will
need to be re-issued.
14.3 De-allocation
For de-allocation, Global will delete the de-allocated databases on the Satellite before updating the site.
However, like allocation, users should not access an MDB containing the database being de-allocated.
These messages show that an MDB, containing the databases, has been accessed and so the databases
could not be de-allocated. Once again PDMS Global will leave the databases as they were before they
failed, so the command will need to be re-issued.
14.4 Claim
Remote Extract Claims need to be claimed up the hierarchy to the Hub; so claims can be completed by
satellites but can fail at the Hub as it may be claimed by another user.
One reason may be that if the scheduled update has not run recently. A claim may fail due to the satellite
having dated information, which has since been modified. So another user, on a different satellite, may have
www.aveva.com
72
AVEVA Plant (12.1)
claimed the database in-between the last scheduled update and the next. Thus, it will not have been
acknowledged on the Satellite until the next Scheduled Update.
In cases such as this, an ‘EXTRACT REFRESH DB/NAME’ is necessary.
In certain cases it may not be possible to claim certain elements as they may already be claimed by other
users.
In cases such as these, the transaction will have to wait until the claim is released.
14.5 Changing Primary Location
The Primary location cannot be changed until all users at that old Primary location exit the AVEVA Plant
session or change to an MDB that does not include the database. If there is a failure during a Change
Primary command, a recovery operation normally restores the database to its original location. As shown
below.
Otherwise, select Data > Recove r> Database > Primary Location from the Admin main menu to display
the Recover Primary Location form.
14.6 Creating a Child Satellite of a Parent Satellite
When setting up a child Satellite of a parent Satellite, the parent of the child Satellite must be set to the
parent Satellite on the Create Location form and the environment variablesmofified to suit.
For example, if a new satellite (LON) was being created as a child satellite of OXF, the parent would be
OXFORD and the batch files would need to contain the syntax
set TRA_LON=\\<SERVERNAME>\Globalproject
at both the Hub and the Satellite OXF.
14.7 Correcting Reverse Propagation Errors
This section simulates a Reverse Propagation Error and rectifies it.
Create a new database, copy it when empty, add some data and then after it has been propagated by the
Global Daemon, replace the updated file with an older version.
 Remember: the Global Daemons check database sessions.
www.aveva.com
73
AVEVA Plant (12.1)
Enter AVEVA Plant Admin at the Cambridge Hub.
Create a new database selecting and entering the following

data where appropriate:
Team: PIPING
Name: NORTH_AREA
DB Element Name: PIPING/NORTH_AREA
Type: Design
Primary Loc.: OXFORD.
 Remember to wait for the transaction to finish.
Administer the OXFORD Satellite
Make DB PIPING/NORTH_AREA part of MDB A-

PIPING at position 1
www.aveva.com
74
AVEVA Plant (12.1)
The Admin Elements form can be changed to

display the name of the file that was created.
Select Settings > Display Mode > Setup Admin

Element form from the main menu to display Level
of Detail on th Admin Elements form form.
Check the Filename checkbox and then click the

Apply button followed by the Dismiss button.
In this example the database file created is

tra0070_0001
At the OXFORD Satellite make a copy of this file using windows COPY tra0070_0001 tra0070_0001.old
The file will typically be in the directory C:\Globalproject\Training\tra000
Enter AVEVA Plant Design at the OXFORD Satellite
Navigate to Site /PIPING/NORTH_AREA in Design Explorer.
Create three Zones under the site, saving work after the creation of each Zone.
After an update event has completed, see the Command Transactions Window, exit AVEVA Plant and
stop both daemons using the stop.bat file.
Swap the new file with the old file in the tra000 folder and restart the Global daemons.
An error message should appear in Command Transactions Window when the update event occurs and
one in the Daemon console window. This is because the session number at the Secondary location (HUB) is
greater than that of the Primary location (OXF).
www.aveva.com
75
AVEVA Plant (12.1)
This can be rectified by simply swapping the files back, however in cases that a backup file cannot be found,
it can be manually copied from the Hub to the Satellite.
This is typical of what would happen if an older version of the database was recovered from back up, the
latest version or as least the same version should be copied to all locations.
Exercise 11 - Correcting Reverse Propagation Errors
Using the above example create and correct the Reverse Propagation Errors.
www.aveva.com
76

TM-1400 AVEVA Plant (12.1) Administering Global Projects Rev 2.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TM-1400 AVEVA Plant (12.1) Administering Global Projects Rev 2.0

Uploaded by

Copyright:

Available Formats

AVEVA Plant

Visit our website at http://www.aveva.com

Unauthorised or unlicensed use of the software is strictly prohibited.

4.2.2 Copying Admin Element to a Satellite Location ....................................................................... 41

 Configure a Project for Global

1.4 Course Structure

1.5 Using this guide

Information the user has to key-in will be in bold red text.

1.1 Setting up the Training Course

Use the Project Creation Wizard to create a new Training Project

Click the Browse button to display the

Navigate to the C: Drive

Click the Make New Folder button.

Name the New Folder Globalproject

Click the OK button on the Browse For Folder

Enter the following data into the relevant

Click the Create button.

The Project Creation Wizard create the

Click the Dismiss button on the Project

MDB: <leave blank>

Click the Login button.

Select the Training Setup Tab.

Enter 1 in the Number of Designers textbox.

Click the Create Project button.

The progress ar is display and textual feedback is

Click the Close button on the Training Admin form.

The Training project is now ready for the training course.

2 Concepts and Terminology

2.1 Overview of AVEVA Plant Global

Communications between Locations are handled by the Global Daemon.

The pending file may be read in the project directory:

2.4 Global Daemon

2.5 Database Allocation

 All databases are must exist at the Hub.

 Extract databases must have their parent database allocated.

2.6 Primary and Secondary Databases

2.7 Database Propagation

2.8 Hub Administration

 Create Master Database

 Create other Locations

2.9 Local (Location) Administration

 Create Users and MDBs

2.10 Non-propagating Files

The following files are not propagated by the Global Daemon

 External Plot files

3 Setting Up a Global Project

In this chapter the following tasks will be completed:

 Install Global if not already installed.

 Lock Project and Make Global.

 Generate the Locations and allocate the DBs.

 Start the Daemon and Initialise HUB

 Copy the Project in the Transfer Directories to the Locations

 Set-up User-Defined Automatic Updates

3.1 Installation and Set-up

3.2 System Ping

ping sat_pc_1 (if sat_pc_1 is the machine name for satellite).

Do the same from satellite to HUB.

ping hub_pc (if hub_pc_1 is the machine name for satellite).

3.3 Project Data

3.3.1 Project Variables

3.4 Creating a Transfer Folder

Create a transfer folder named oxf in C:\Globalproject\Training.

In the oxf folder create a sub-folder named Training

Set an environment variable pointing to this directory of the form:-