Advanced Admin Pdms

Advanced ADMIN
Version 11.4
Advanced ADMIN
Administration
Course Workbook
PLEASE NOTE:
AVEVA has a policy of continuing product development: therefore, the information
contained in this document may be subject to change without notice.
AVEVA MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS
DOCUMENT, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
While every effort has been made to verify the accuracy of this document, AVEVA
shall not be liable for errors contained herein or direct, indirect, special, incidental or
consequential damages in connection with the furnishing, performance or use of this
material.
This manual provides documentation relating to products which you may not have
access to or which may not be licensed to you. For further information on which
Products are licensed to you please refer to your licence conditions.
Copyright 2017 AVEVA Limited
All rights reserved. No part of this document may be reproduced, stored in a retrieval
system or transmitted, in any form or by any means, electronic, mechanical,
photocopying, recording or otherwise, without prior written permission of AVEVA.
The software programs described in this document are confidential information and
proprietary products of AVEVA Ltd or its licensors.
Visit our website at http://www.aveva.com
AVEVA Ltd, High Cross, Madingley Road, Cambridge CB3 0HB, UK

Introduction
Contents
Advanced ADMIN
Administration
Session 1: Introduction To The Course
Session 2: Database Extracts
Session 3: Data Access Control
Session 4: Review and Feedback

Introduction 1-2 Advanced ADMIN Training Manual
Introduction
Session 1
Introduction

Introduction
Introducing the course
Content
A one-day course on use of Advanced ADMIN
Concepts and Terminology
Database Extracts
Data Access Control
Assumptions
Level of knowledge of Administration
Level of knowledge of PDMS
ADVADM5
This course is designed and run by AVEVA Ltd. to familiarise users with Extracts and
Data Access Control techniques for Vantage PDMS.
It assumes that participants are fully conversant with the PDMS ADMIN module and
have themselves, administered a PDMS project.
At the end of this session you will be able to:

Provide sufficient information and practice to enable a VANTAGE PDMS Administrator to
design an ADMIN set-up using Database Extracts and Data Access Control (DAC).
And understand:
Concepts and Terminology
Database Extracts
Data Access Control

Introduction
Course delivery
Training material Practical exercises
Workbook
ADVADM6
The course will consist of lecture material together with practical exercises for each
session. There will be a large worked exercise on day two.
The supporting workbook provides a backup to the lecture and exercises during the
course and a valuable reference guide after the course.
At the end of the workbook you will find references to further reading and information
sources.

Introduction

Database Extracts
Session 2
Database Extracts
Extended Multiwrite Facilities
Review of Simple Multiwrite Databases

Allows more than one user to write to a given
database.
Elements in a Multiwrite database must be claimed
before modification is possible. No other user can
claim an element that has already been claimed.
Claim mode can be explicit or implicit.
Elements are unclaimed by a module change or
EXIT.
Only primary elements can be claimed.
ADVADM10
Database Extracts 2-1 Advanced ADMIN Training Manual

Database Extracts
Extracts
An Extract db provides a means of working on

data in a Master db without the data in the Master
db being updated until the user chooses.
A user claims elements to work on in the Extract.
A SAVEWORK saves work back to the Extract,
not to the Master db. Claims made in this way are
persistent.
Master DB
Extract A Extract B
SAVEWORK
ADVADM11
When you do a SAVEWORK, the changed data will be saved back to the Extract.
The unchanged data will still be read via pointers back to the Master db.
When required, changes made to the Extract are written back to the Master db.
The Extract itself can be updated to reflect changes made to the Master.

Database Extracts
Extract dbs - Features
When an Extract is created it is essentially an

empty db, with pointers back to the data in the
Master db.
Extracts can only be created from Multiwrite dbs
and are themselves Multiwrite.
You can create Extract dbs from any db that can
be Multiwrite, i.e. DESI, PADD, CATA and ISOD.
You can create many Extracts from one Master
db, and also create Extracts of Extracts, thus
creating an Extract Family (10 levels maximum).
You cannot create Extracts from foreign dbs.
You cannot create Extracts from copy dbs. ADVADM12
Claim mode must be set when a Multiwrite db is created.

Explicit claim - you must claim any element you wish to change before the
modification starts.
Explicit claim mode is recommended when extracts are distributed. This avoids
delays when claiming across a location.
Implicit claim - an element will be claimed automatically when it is modified.
Disadvantage of implicit claim mode is that you could spend some time defining a
change, then not be able to apply the changes if the element had already been
claimed by someone else.
Elements can be unclaimed at any time, providing they have not been modified since
the last SAVEWORK.

Database Extracts
1 Extracts
An extract is created from an existing Database. When an Extract is created, it

will be empty, with pointers back to the owning or master database. Extracts
can only be created from Multiwrite databases, and all extracts are themselves
Multiwrite. You can create Extract DBs from any type of database that can be
multiwrite, that is DESI, PADD, CATA and ISOD.
You cannot create extracts from foreign DBs.
You cannot create extracts from copy DBs.
An extract can be worked on by one User at the same time as another user is
working on the master or another extract. When a user works on the extract,
elements are claimed to the extract in a similar way to simple multiwrite
databases, so no other User can work on them. When an extract User does a
SAVEWORK, the changed data will be saved to the Extract. The unchanged data
will still be read via pointers back to the master DB. When appropriate, the
changes made to the extract are written back to the master. Also, the extract
can be updated when required with changes made to the master.
1.1 Extract Families

A Master DB may have up to 8000 extract DBs. You can create an extract from
another extract, forming a hierarchy of extracts. All the extracts derived from the
same master are describes as an Extract Family.
The original database is known as the Master database. The Master database
is the owner or parent of the first level of extracts. If a more complex hierarchy
of extracts is created, the lower level extracts will have parent extracts which
are not the master.
The extracts immediately below an extract are known as extract members.

Database Extracts
The following diagram illustrates an example of an extract family hierarchy:
PIPES
PIPES_X PIPES_X2
PIPES_X10 PIPES_X11 PIPES_X12
In this example:
PIPES istheMaster
andtheparentofPIPES_X1
PIPES_X1 isachildofPIPES
andtheparentofPIPES_X10
PIPES_X10 isachildofPIPES_X1
The members of PIPES are PIPES_X1 and PIPES-X2.
Write access to extracts is controlled in the same way as any other database:
The user must be a member of the Team owning the Extract. Extracts in the same family can
be owned by the same team or by different teams.
The user must select an MDB containing the extract.
Data Access Control can be applied.
Note: At this release, you can only create an extract at the bottom of an
extract tree: you cannot insert a new extract between existing
generations, or create a new master for the extract family.

Database Extracts
1.1.1 Querying Extract Families
You can query the following attributes to get information about the structure of
an extract family
DB attributes
EXTNO Extract Number

EXTOWN Extract Owner
EXTMAS Extract Master
EXTALS Extract Ancestors
EXTCLS Extract Children
EXTDES Extract Descendants
EXTFAM Extract Family
ISEXOP Owner Primary Here
ISEXMP Master Primary Here
ISEXAP Ancestry Primary Here
LVAR Variant
LCTROL Controlled
1.2 Creating Master and Extract Databases
1.2.1 Creating Master Databases
All master databases (that is, normal multiwrite databases which are going to
have extracts created from them) must be created at the Hub (when GLOBAL
is used. They can be created before giving the make global command).
You should specify the database numbers and matching database file numbers
for each database. For example:
cr db pipe/pipe-a desi acc multiwrite claim explicit db no n fino n
1.2.2 Creating Extracts (including Global working practice)
Extracts can be created at any Location: the parent 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.

Database Extracts
If you are at the Hub and creating an extract for a satellite, use the AT option in the CREATE
command, The extract will be created with its primary location at the Satellite specified.
If you are at an administering location, you must also use the AT option if you want to
specify that the extract will be created at the administered location, otherwise the extract will
be created at the administered location (that is, the true current location, queried using
Q CURLOC). The parent extract must be allocated to the current location.
When you are creating an Extract at a satellite, make sure you give the CREATE EXTRACT
command only once and check that the command has completed before issuing a second
CREATE EXTRACT command.
The CREATE EXTRACT command will be executed by the Daemon (which will
imply a delay in executing the command) if any of the following is true:
If the current location is a satellite

If the parent extract is primary at another location
If the new child extract is specified to be primary at another location (AT loc option).
Note that the ALLOCATE Command allows child extracts to be allocated to a

satellite without their parent being allocated, but you will not be able to open the
extract until all its ancestors have been allocated to the location.
1.2.3 Creating 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 MDBs. When you select an MDB
that includes databases for which you have working extracts, you will actually
write your data to the working extract.
When you issue data from a working extract, it will be issued to the database
from which the working extract has been created.

Database Extracts
In order to issue data from an extract which has working extracts to an extract
further up the extract tree, there must be a user who does not have a working
extract: see the following diagram.
Extract 1
USERA and
USERB will issue
to Extract 2.
You must have
Extract 2 another user with
no working extract
to issue from
Extract 2 to
Extract 1.
Working Working
Extract of 2 Extract of 2
for USERA for USERB

Database Extracts
Extract dbs - Benefits
They allow persistent claims - changed

elements are not unclaimed when the user
changes module or exits from PDMS.
The master DB is written to less, therefore
less session data is recorded, and change
management is better controlled.
Users may have working extracts for
their private use (Working Extracts).
Design variants can be tried and
maintained (Variant Extracts).
ADVADM13
Extracts can be used to control approving and issuing of work. For example,
changes can be issued when given criteria are met. Other users can then read the
approved data rather than the working data.
Variant extracts are extracts that allow work on elements without having to claim
items.

Database Extracts
Extract Families
An Extract can be created from another Extract.

Two or more Extracts derived from the same
master db form an Extract Family.
In the hierarchy below, PIPES is the Master DB,
PIPES_X1 is owned by PIPES and is a member of
PIPES, PIPES_X10 is owned by PIPES_X1.
PIPES Master db
PIPES_X1 PIPES_X2 First-level Extracts
PIPES_X10 PIPES_X11 PIPES_X12 Second-level Extracts
ADVADM14
Extract families enable several users work to be combined into another higher-level
extract, which can then be approved before it is used to update the master.
Write access to the Extracts is controlled in the first place by the user selecting the
MDB containing the Extract.
Extracts in the same family can be owned by the same team or by different teams.
Data Access Control can be applied.
Every Extract db will have the same db number as the Master db.
Every Extract in an Extract family will have a unique Extract Number.
Q EXTOWN gives the owner of an Extract; Q EXTNO gives the Extract Number.

Database Extracts
Multiple Databases vs. Extracts

Use Extracts for:
Controlling data workflow within a discipline.
Controlling cross discipline modifications (e.g. penetrations,
supports)
Persistent claims.
Integrated working environment with other offices (Global+)
Use Separate Databases for:
Enabling cross discipline review / approval of data
Catalogue, Library and Template data
Splitting data into smaller units to avoid mass data processing
through large collections, clashing and spatial map updates.
Controlling the visibility of data in working areas.
Controlling the distribution of sub-contractors data.
Separating common data for export across projects
Reducing the consequences of possible data corruption
ADVADM15

Database Extracts
2 Setting up an Extract Hierarchy

Before you start creating extracts and working extracts, you should have a clear plan
of how they will be used. You should maintain diagrams of the basic master / extract /
working extract database organisation. These help when devising flush and release
procedures, and defining MDBs.
PIPE/PIPE File number 200

Db number 200
First level extract
PIPE/REVIEW File numbers will be 200_xxxx,

where xxxx is the extract number
Second level extract
PIPE/CURRENT File numbers will be 200_xxxx,

Working extract Working extract Working extract

for UserA for UserB for UserC
Working extracts are identified as

PIPE/CURRENT_EXxxxx
Note: Thedatabasesshownareallpartofthesameextractfamily,and

Database Extracts
sotheywillallhavethesamedatabasenumber,forexample200.
Operations on Extracts - 1
EXTRACT CLAIM
The transfer of write access of a given
primary element to an Extract.
A claim can be to a first-level Extract from
a Master db, or to a low-level Extract from a
higher-level Extract.
/PIPE1
PIPES
PIPES_X1 PIPES_X2
/BRAN1-1
ADVADM16

Database Extracts
REFRESH
Updates an Extract with changes made in the owning db. A
REFRESH can be to a first-level Extract from a Master db, or
to a low-level Extract from a higher-level Extract (one level at
a time).
changes
PIPES
changes
PIPES_X1 PIPES_X2
ADVADM17
The user of an extract gives the REFRESH command and updates the changes from
the higher-level db. The user of another extract will not see the changes unless they
also do a REFRESH.
Command syntax for REFRESH:
EXTRACT REFRESH DB DB/NAME
EXTRACT REFRESH CE
EXTRACT REFRESH CE HIERARCHY
EXTRACT REFRESH gid
EXTRACT REFRESH gid HIERARCHY

Database Extracts
FLUSH
Local changes are copied to the owning db, but the elements
are not released. Users who have access to the owning db
can now see the changes, but they can not make changes of
their own to the elements.
changes
PIPES
PIPES_X1 PIPES_X2
changes
ADVADM18
Command syntax for FLUSH:

EXTRACT FLUSH DB DB/NAME
EXTRACT FLUSH CE
EXTRACT FLUSH CE HIERARCHY
EXTRACT FLUSH gid
EXTRACT FLUSH gid HIERARCHY

Database Extracts
RELEASE
Use after local changes have been FLUSHed to the owning
db; Users who have write access to the owning db can now
make changes of their own to the elements.
changes
PIPES
PIPES_X1 PIPES_X2
changes
ADVADM19
RELEASE can only be used if you have not made any changes, or if all the changes
that have been done have been FLUSHed.
Command syntax for RELEASE:

EXTRACT RELEASE DB DB/NAME
EXTRACT RELEASE CE
EXTRACT RELEASE CE HIERARCHY
EXTRACT RELEASE gid
EXTRACT RELEASE gid HIERARCHY

Database Extracts
ISSUE
The same as FLUSH followed by RELEASE. Local
changes are copied to the owning db, and the changed
elements are released. Users who have write access to
the owning db can now make changes to the elements.
DROP
Local changes will be abandoned. There will be no
change to the owning db, and it will return to its state
before the changes were made (even if the user has
done a SAVEWORK). The elements which were being
worked on will NOT be released.
ADVADM20
Command syntax for ISSUE:

EXTRACT ISSUE DB DB/NAME
EXTRACT ISSUE CE
EXTRACT ISSUE CE HIERARCHY
EXTRACT ISSUE gid
EXTRACT ISSUE gid HIERARCHY
Command syntax for DROP:

EXTRACT DROP DB DB/NAME
EXTRACT DROP CE
EXTRACT DROP CE HIERARCHY
EXTRACT DROP gid
EXTRACT DROP gid HIERARCHY

Database Extracts
3 Using Extracts in DESIGN

A useful querying command when you are using extracts in DESIGN is:
Q DBNAME
This command will return the name of the database which you are actually writing to.
3.1 User Claims

Normal multiwrite databases require the user to claim an element before changing it.
This is known as a user claim. Depending on how the database is set up when it is
created, user claims can be implicit or explicit, and in either case, when a new element
is created, it will be claimed to the user who created it.
Note: Inaglobalproject,werecommendthatmultiwritedatabases
shouldbecreatedwithEXPLICITclaimmode.
User claims can be explicitly released (unclaimed) by the user during a PDMS
session, and elements are always unclaimed when the user changes modules or
leaves PDMS.
The commands for user claims are:
CLAIM . . .
UNCLAIM . . .
3.2 Extract Claims

When you are using extracts, another type of claim, known as an extract claim, is
made as well as user claims.
If an element is claimed to an extract, only users with write access to the extract will
be able to make a user claim and start work on the element.
Once a user has made a user claim, no other users will be able to work on the
elements claimed, as in a normal multiwrite database.
If a user unclaims an element, it will remain claimed to the extract until the extract
claim is released.

Database Extracts
3.3 Command Syntax

The command syntax for handling extract claims in DESIGN is as follows:
>- EXTRACT -+- CLAIM ---.

| |
|- FLUSH ---|
| |
|- RELEASE -|
| |
|- ISSUE ---| .-----<---.
| | / |
|- DROP ----+-*- element -+- HIERARCHY -.
| | | |
| | `-------------|
| | |
`- REFRESH -+--- DB dbname -------------+--->
CLAIM Claimstheelementorthewholedatabasetotheextract.
FLUSH Writesthechangesbacktotheowingextract.TheExtract
claimismaintained.
ISSUE Writesthechangesbacktotheowingextract,and
releasestheextractclaim.
RELEASE Releasestheextractclaim:thiscommandcanonlybe
usedtoreleasechangesthathavealreadybeenflushed.
REFRESH Refreshestheextractwithchangesthathavebeenmade
totheowingextract.
DROP Dropschangesthathavenotbeenflushedorissued.The
userclaimmusthavebeenunclaimedbeforethis
commandcanbegiven.
The HIERARCHY keyword must be the last on the command line. It will attempt to claim
to the extract all members of the elements listed in the command which are not already
claimed to the extract.
The elements required can be specified by selection criteria, using a PML expression.
For example:
EXTRACT CLAIM ALL PIPE WHERE (:OWNER EQ USERA) HIERARCHY

Database Extracts
3.4 Relationship between Extract and User Claims

If the databases are set up with implicit claim, when the user modifies the element,
the element will be claimed both to the extract and then to the user. If the element is
already claimed to the extract, then the claim will only be made to the user.
If the databases are set up with explicit claim, then the user will need to use the
CLAIM command before modifying the element.
3.4.1 How to Find Out What You Can Claim
Before you start work on an extract, you should do a GETWORK and an EXTRACT
REFRESH, which will ensure that you have an up-to-date view of the database.
This section explains what different users will see as a result of Q CLAIMLIST
commands.
For this example, take the case of a database PIPE/PIPE, accessed by USERA, with
two extracts. Users USERX1 and USERX2 are working on the extracts.
DB PIPE/PIPE
USERA
DB PIPE/PIPE-X2
DB PIPE/PIPEX1
USERX2
USERX1
USERA creates a Pipe and flushes the database back to the owning database,
PIPE/PIPE. The results of various Q CLAIMLIST commands by the three Users, together
with the extract control commands which they have to give to make the new data
available, are shown in the following diagram.

Database Extracts
USERA:
EXTRACT REFRESH DB PIPE/PIPE
Q CLAIMLIST:
none
Q CLAIMLIST OTHER:
/PIPE-100 Extract PIPE/PIPE_EX7001
Q CLAIMLIST EXTRACT:
/PIPE-100
USERX1 creates PIPE-100 USERX2:

EXTRACT FLUSH DB PIPE/PIPE EXTRACT REFRESH DB PIPE/PIPE
Q CLAIMLIST: Q CLAIMLIST:
none none
Q CLAIMLIST OTHER: Q CLAIMLIST OTHER:
none /PIPE-100 Extract PIPE/PIPE_EX7001
Q CLAIMLIST EXTRACT: Q CLAIMLIST EXTRACT:
/PIPE-100 none
Note that USERX2 must

use
Q CLAIMLIST OTHER
(not Q CLAIMLIST
EXTRACT) to see the claim
Note:
Q CLAIMLIST EXTRACT
tellsyouwhatyoucanflush
Q CLAIMLIST OTHERS
tellsyouwhatyoucan'tclaim

Database Extracts
You can query the extract claimlist for a named database. The database can be the
current on or its owner:
Q CLAIMLIST EXTRACT DB dbname
When you create an element, PDMS only sees it as a user claim, not an extract claim,
until the element is flushed. It will then be reported as an extract claim (as well as a
user claim, if it has not been unclaimed).
Note that a change in the claim status of an existing element will be shown by the
appropriate Q CLAIMLIST command as soon as appropriate updates take place, but a
user will have to GETWORK as usual to see the changes to the Design model data.
We recommend that:
Databases which are going to own extracts should be created with explicit claim mode.
Before you make a user or extract claim, you should do an EXTRACT REFRESH and GETWORK.
If you need to claim many elements to an extract, it improves performance if the elements
are claimed in a single command, for example, by using a collection:
EXTRACT CLAIM ALL FROM !COLL
Global Only
The admin daemon will only be involved in the claiming process if the user is claiming
an element from a secondary database / extract to their current primary extract. In this
instance, the user will be warned that the element is now being claimed by the admin
daemon. The user will know when the claim is completed, by using GETWORK and
checking the claim list.
3.5 Flushing Changes

When an extract user makes changes and saves them, they are stored in the extract.
These changes can be made available to users in other extracts using the EXTRACT
FLUSH command.
The FLUSH command operates on a single element or a database or a collection of
elements. The changes to these elements will be made available in the owning extract.

Database Extracts
If changes need to be made available in the master database, it will be necessary to

flush the changes up through each level of extracts. Users accessing extracts in other
branches of the extract tree will need to use EXTRACT REFRESH to see the changes.
The following diagram illustrates the sequence of commands that need to be given so
that a user working on extract B2 will be able to see the changes made by a user
working on extract A2.
MASTE
R
2
FLUSH
A1 3 B1
REFRESH 4
1
REFRESH
FLUSH
A2 B2
Global Only
The admin daemon will only be involved in the flush process if the user is flushing
changes to a secondary database / extract from their current primary extract.
3.6 Releasing Claims

Elements that have been claimed to an extract will remain claimed to that extract until
they are released. Any changes must have been flushed to the owning extract before
the extract claim is released.
The EXTRACT RELEASE command operates on a single element or a database or a
collection of elements. The elements claimed will be released from (that is, no longer
claimed in) the current extract, at which point they will be claimed by the owning
extract.
If elements need to be made available in the master database, it will be necessary to
release the elements up through each level of extracts.

Database Extracts
Global Only
The admin daemon will only be involved in the release process if the user is releasing
elements to a secondary database / extract from their current primary extract.
When you are flushing / releasing data from a satellite to another location, you should
check that the flush has been successful before releasing the changes.
3.7 Issuing Changes

The ISSUE command is simply a combination of FLUSH and RELEASE.
3.8 Dropping Changes

You can drop changes that have not been flushed. The EXTRACT DROP command will
operate on a single element or a database or a collection of elements.
You cannot drop an element if it owns other significant elements. You have to list all the
elements in the same EXTRACT DROP command, or drop the lower-level elements first.
You must UNCLAIM any user claim on an element before you can drop it.
The DROP command should be used with care. Once the changes have been dropped they
can only be retrieved using session data or from backup.
3.9 Refreshing an Extract

If changes have been made to the data in an extract, the changes will not be visible in
lower extracts unless these extracts are refreshed. The refresh command operates on
a database, and it refreshes the database to look at the latest state of the owning
extract.
If the changes are in the master and need to be made available in an extract several
levels down, each extract will need to be refreshed in turn, starting with the extract
directly beneath the master database and continuing down to the lower extracts.

Database Extracts
Note the difference between REFRESH and GETWORK:

GETWORK will get changes made to databases in the current MDB.
REFRESH will get changes made to the owning extracts of extracts in the MDB.
Global Only
The refresh command will only refresh from databases local to the satellite. Therefore,
if a secondary database has not yet been automatically updated with changes made to
the database at the primary location, then these changes will not yet be visible at the
local satellite. Extracts below the database will only see the latest version of the
secondary database when they are refreshed. To see the changes made to the
primary database, you must wait for the next scheduled automatic update before
refreshing.
3.10 Partial Operations

When named elements are specified in an ISSUE, DROP or FLUSH command, it is
know as a partial issue, drop or flush. There are some restrictions on what you
can do, as follows:
Where a non primary element has changed owner, then the old primary owner and the new
primary owner must both be issued back at the same time. Otherwise there is potential for
inconsistencies to occur.
If an element has been unnamed, and the name reused, then both elements must be
flushed back together.
If an element and its owner have been created then :
If the element is included in a partial flush, then its owner must also be
included.
If the owner is include in a partial drop, then the element itself must be
included.
If an element and its owner have been deleted then :
If the element is included in a partial drop, then its owner must also be
included..
If the owner is included in a partial flush, then the element itself must be
included.
The HIERARCHY option will scan elements in both the extract and owned
extract. Thus deleted/moved elements will be included as part of the
issue/drop/flush.
You can use selection criteria to specify partial issues and flushes.

Database Extracts
Types of Extract - Standard Extracts
Similar to normal databases, i.e. can be

owned by any team, given any name, added
to MDBs in the usual way.
Claiming can be implicit or explicit - if an
element is being worked on by any user in
the Extract Family, no other user can work
on it.
Changes flushed back to owning database -
claimed elements can then be released, or
kept claimed out for further modification.
ADVADM21

Database Extracts
Types of Extract - Working Extracts
Working Extracts
are one per user Extracts
only require the use of a single MDB
DROP operations only remove one users changes
MDB /A Approval Extract
MDB /B Review Extract
USERA USERB USERC Working Extracts
ADVADM22
Note that the Working Extracts themselves are not members of an MDB; the owning
Extract db is the member of the MDB.
Use: Allows an Extract to be controlled such that users are restricted to their own
work area and are not allowed to issue other users work.

Database Extracts
Types of Extract - Variant Extracts
Any element can be modified, i.e. elements

are NOT claimed.
Different users can modify the same element
in different (variant) Extracts.
If two users modify the same attribute, the
changes may conflict. Therefore, control of
this situation may be required, using ACRs.
The user who has issuing rights must
resolve any conflicts before issuing
changes back to the Master db.
ADVADM23

Database Extracts
4 Extract Sessions
When an extract is created, it is created at a particular session number in the parent
extract. This is called the linked session. As the owner extract is modified, and new
sessions added, the linked session on the child extract will not change until a refresh
or flush is made.
Note that ISSUE and DROP cause an automatic refresh.
Extract Linked session in Comment

session owner
no.
1 10 Extract created
2 10 Modification made on extract
3 10 Modification made on extract
4 15 Refreshed from owner.
5 15 Further modification.
6 18 Issued
7 18 Further modification
8 18 Further modification
9 25 Issued
While a user is making changes only to the extract, the linked session number in the
owner stays the same. On refreshing, the local extract is linked to the most recent
version of the parent extract.
The new session number linked to in the owner depends on the number of flushes
done by other users. In the example the linked session number goes from 10 to 15,
indicating that five flushes have been made by other users in the meantime (assuming
that not work is being done directly on the owner).

Database Extracts
4.1 Merging Changes

When a MERGE CHANGES command is given on a DB with extracts, all the lower
extracts have to be changed to take account of this. Thus doing a MERGE CHANGE on a
DB with extracts should not be undertaken lightly.
The following restrictions apply:
Any sessions linked to owned extracts must be preserved.
There may be no users on any lower extracts.
We recommend that you should MERGE CHANGES at the lowest level of extracts first,
and then work up the tree.
In a Global project, MERGE CHANGES can only be carried out at the location at which
the database and all its descendant extracts are primary.
Note: BACKTRACKisnotallowedforextractdatabases.
4.2 Varient Extracts

Varients are a special type of extracts, with less rigourous control of claiming elements
and writing data back to the owning extract. They are designed to allow users to try out
different designs, which then may or may not be written back to the master.
Varients are different from normal extracts (including Working extracts) in the following
ways:
Any element can be modified without being claimed, and so different users can modify the
same element in different varients.
When data is written back to the owning database, it will overwrite any conflicting data in the
owner.
A varient can have normal extracts created from it. Note that in this case, the varient
forms a new root for claiming elements: claims in extracts below the varient will not be
visible from other parts of the extract family, and claims in other parts of the family will
not be visible in extracts owned by the varient.

Database Extracts
Creating an Extract -1
On the Admin Elements form select Databases &

Extracts from the Elements list, select a Multiwrite db
from the list, then click Create:
Gives the
Databases & Extracts
form
Select An Extract of a DB,

then click OK to give . . .
ADVADM24
Examples of Syntax for Extracts, Variants and Working Extracts:
cr db teama/dbA DESI access MULTIWRITE CLAIM EXPLICIT dbno 1 fino 1 desc 'Master Data'
cr ext teamb/dbB FROM teama/dbA CLAIM EXPLICIT extno 1001 desc 'Data For Approval'
cr ext teamc/dbC FROM teama/dbA CLAIM EXPLICIT extno 1002 desc 'Site Change Approval'
cr var teamc/dbD FROM teama/dbA CLAIM EXPLICIT extno 1003 desc 'Cross Discip Approval'
cr ext teamd/dbE FROM teamb/dbB CLAIM EXPLICIT extno 1004 desc 'Fab Update Area'
cr ext teamd/dbF FROM teamb/dbC CLAIM EXPLICIT extno 1005 REFB 10 desc 'Constr Update Area'
cr ext teamd/dbG FROM teamb/dbC CLAIM EXPLICIT extno 1006 REFB 10 desc 'Work Area'

Database Extracts
Creating an Extract -2
The Create Extract form
Select the database

for the Extract
and the owning Team

Enter a Name and a
Description for the Extract,
then Apply the form.
ADVADM25
Variant Extracts are created by checking the Variant box.

Database Extracts
Creating a Working Extract
On the Admin Elements form select Working Extracts

from the Elements list, then click Create:
Gives . . . .
ADVADM26

Database Extracts
The Create Working Extracts form
Select the db from which

to create the Working
Extract
Select the User for the

Working Extract
Enter a Description for

the Working Extract,
then Apply the form
ADVADM27

Database Extracts
Exercise 1 - Simple Extract Tree
In ADMIN, create the structure shown below:
TeamMaster
MDBMASTER
DB UserMaster
TeamA Extract Extract TeamB

MDBA MDBB
UserA
UserB
ADVADM28

Database Extracts
Exercise 1 - Simple Extract Tree
Having created the teams, databases, users

and MDBs, add the databases to the relevant
MDBs and any other catalogue databases you
require. Use MDB /TRAINA as a template.
Now go into PDMS into DESIGN as USERA
and as USERB and test the set-up, using
claim, refresh, issue etc.
Create some PDMS elements as USERA and
issue the elements. Then go in as USERB and
refresh the database to see the changes.
ADVADM29

Session 3
Data Access Control (DAC)
Data Access Control (DAC) 3-1 Advanced ADMIN Training Manual

Improved Data Access Control (DAC)
Users are members of Teams. Only Team

members have Write access to dbs owned by
the Team.
Access Control Rights (ACRs) allow the
Administrator to:
Restrict Users access to named elements or given element
types, or particular volumes of the model.
Restrict the type of operation a User can carry out on elements.
Restrict which attributes a User can set or change.
DAC can be applied to Update or Multiwrite
(controlled or uncontrolled) databases.
ADVADM30
Default PDMS data access control will apply to the Project unless the Data Access
Control option in ADMIN is switched on.
To switch DAC on:
Project > Data Access Control
Once DAC is switched on, General Users will not have write access to any
elements unless ACRs have been set up to give them access rights. Free Users
always have full access to all elements.

ACRs, Roles and Scopes
Each User can be given one or more ACRs.

Each ACR consists of:
A Role, which defines what operations the User
can carry out on which elements.
A Scope, which defines the part of the Design to
which the Role applies.
Roles and Scopes are referenced by ACRs
and must therefore be created before the
ACR has its RoleRef and ScopeRef set.
Roles are likely to be used on all Projects,
but Scopes are Project-Specific.
ADVADM31
Example Roles - Create, Modify and Delete all types of Piping elements.
Example Scopes - a particular Site in DESIGN or Registry in DRAFT, or a specified
volume within the model.

Permissible Operations (Perops)
A Role is a set of Permissible Operations

(Perops), which define the operations that can
be performed on a given element type.
ADVADM32

Summary of ADMIN hierarchy used
in Data Access Control
User
User
ACR1
ACR1 ACR2
ACR2
Scope
Scope Role
Role
Perop1
Perop1 Perop2
Perop2
ADVADM33

Enabling DAC
From the Project pull-down, select:
Data Access Control . . .
to give . . .
ADVADM34
To switch ACRs on in a Project:

Navigate to /*RO
Set attribute LACR to TRUE

Creating Roles and Scopes
Remember that ACRs are defined in terms of

Roles and Scopes, so these must be created
first.
On the Admin Elements form:
Select Roles
Gives the
Create Role
form
Then click Create

ADVADM35
Give the Role a Name and a Description. Description is optional, but is

recommended; when you later create ACRs, the ACR Description is built from the
Descriptions of the Role and the Scope.
Logical naming conventions help when generating an ACR system.
Example syntax:
NEW ROLE /name
DESC text_string
NEW PEROP /name
OPCREATE GRANT
OPMODIFY GRANT
OPDELETE GRANT
OPISSUE GRANT
OPDROP GRANT
ECLASS SITE
ACLASS PURP NAM FUNC VESL
COND (purp of site eq ADM)

Creating Roles
Remember that Roles are defined in terms of
Permissible Operations (Perops), so these must be
created first.
On the Create Role form:
Enter Name
Gives the
Create Permissible
Operation form
Click Apply, then Create
ADVADM36
When you click Apply, the form changes to a Modify Role form and the Role is
added to the relevant list in the Admin Elements form. The Create button now
becomes active.

Creating Permissible Operations
(Perops).
Name the Perop Specify the element types to

which the Perop is to apply
Specify qualifying conditions
and corresponding message
Specify all operations allowed
Specify the attributes of the

element to which the Perop
is to apply
ADVADM37
You can add Element types to the list by pressing All or by typing them one at a
time into the text box. You can remove an element type by selecting it in the list and
pressing Remove. In the event of contradictory list members, the list member which
is highest in the list will always win. A negative condition will always win,
irrespective of its position in the list.
The Attributes list lets you to specify that the operation is allowed (+) or disallowed
(-) only for specified attributes of the selected element. You can add attributes to the
list by pressing All or by typing attribute names one at a time into the text box.
You can further restrict accessible elements by giving a Qualifying Condition, using
a PML expression. For example:
ALL PIPES WITH ATTRIB ABORE LT 150
If you specify a qualifying condition, you can also set a Message to be output if the
user is refused access to the element because the condition is not met.
The Operations options specify the operations allowed on the elements. Claim and
Issue are only used in Multiwrite Databases.

Note: All required operations must be set explicitly. For example, if you select
Create, you must also select Modify and Delete, if that is what you want. A Perop
with all options set to Ignore has no effect.
Creating Scopes
On the Admin Elements form . . .

Select Scopes
from the
Elements list Give the Scope a Name
Gives the and a Description
Create Scope form
Define the Scope
Then click
Create . . .
ADVADM38
The Description is optional, but it is recommended: when you create ACRs, the
Description is built automatically from the Descriptions of the Role and the Scope.
The Scope Selection is a PML expression.
Note that, unlike Roles, Scopes are project-specific, and they are defined in terms of
specific parts of the project data. For example, you can specify a Scope as being a
given Site (in DESIGN) or Drawing (in DRAFT).

Creating ACRs and ACR Groups
Now that Scopes, Roles and Perops have

been created, ACRs can be defined.
On the Admin Elements form, select
ACRs & ACR Groups from the Elements
list, then click Create.
Gives the ACRs and ACR Groups form
Select whether you wish to create one

ACR or an ACR Group, then click OK
ADVADM39
Setting Access Control Rights gives the Create ACR form.

Setting A group of ACRs gives the Create ACR Group form.

Creating an ACR
(Scopes, Roles and Perops have already been

created - see exercises in training manual.)
Give the ACR a Name
Select the Role and the Scope
Apply the form
Note selected Role and Scope

names have been set here
ADVADM40
Description is generated automatically from the Descriptions of the Role and the
Scope, and you cannot change it.
The syntax is:
NEW ACR /name
DESC text_string
ROLEREF /text_stringROLE
SCOPEREF /text_stringSCOPE

Creating an ACR Group
(A group of ACRs has been selected from the

ACRs and ACR Groups form.)
Give the ACR Group a Name
and a Description
Select the ACRs that

you want to be in
the ACR Group
Move the selected

ACRs to the Group
Apply the form

ADVADM41
You can now assign an ACR Group to a User.

Applying ACRs
A User can have several ACRs.

Select Users on the Admin Elements form and
select the User you wish to assign ACRs to.
Modify the User to give . . .
ADVADM42
The syntax is:

/USER
ACRLI /ACR1 /ACR2
where /USER is the user to which the ACRs are to be assigned
and ACRLI (ACR List) specifies all ACRs for that user.

Assigning ACRs to a User
The Modify User form
Select the ACRs (or

the ACR Group) that
you want to assign
to the User
Assign the selected

ACRs (or ACR
Group) to the User
ADVADM43
When you are planning how to set up ACRs for your Users, the main thing to
remember is that once DAC is switched on, no General Users have write access to
anything unless they are given an ACR that allows it.
The order of ACRs is important. Once PDMS has found an ACR which excludes a
User from carrying out a task, it will look no further in the list. For example, if a User
has an ACR which only allows Modification of Pipes within a given Zone, but not
Creation, and that ACR is first in the list, the User will not be able to Create Pipes in
that Zone even if an ACR later in the list allows it.
A User can be assigned one (or more) ACR Groups, or several ACRs. ACR Groups
simply provide a shortcut.

5 Data Access Control
5.1 Introduction
The basic method of controlling users access to data in PDMS is by means of the
Teams-owning-databases mechanism only members of the Team owing the
database have write-access to it. This is always the case, but you can additionally use
Access Control Rights (ACRs) to provide a much more sophisticated level of Data
Access Control (DAC). ACRs allow you to:
Restrict Users access to named elements or given element types, or particular volumes of
the model.
Restrict the type of operation (for example, Create, Modify or Delete) a User can carry out on
elements.
Restrict which attributes a User can set or change.
Note: DAC will only take effect if it is switched on for the project. Once
DAC is switched on, no General Users will be able to write to any
database unless they have ACRs permitting them to do so.
5.2 ACRs, Roles and Scopes

Each User can be given one or more Access Control Rights (ACRs). Each ACR
consists of two parts:
A Role, which defines what operations a User can carry out on which elements. For
example, create, modify and delete all types of Piping elements.
A Scope, which defines the part of the design to which the Role applies, for example, a
particular Site (in DESIGN) or Registry (in DRAFT), or a specified volume within the model.
Roles and Scopes must be created before you can create ACRs. They are both
defined within a project, but Roles are likely to be Company-wide and used for all
projects, and so they are defined in very general terms: Scopes are project-specific.
5.2.1 Permissible Operations (Perops)
A Role is a set of Permissible Operations (Perops for short) which define the
operations that can be performed on a given element type.

The hierarchy of ADMIN elements used in DAC is shown below:
User
ACR1 ACR2
Scope Role
Perop1 Perop2
5.3 Creating Roles and Perops

To create a Role in a project, use the Admin Elements form to display navigate to the
Role World /*RO (in the system database) and give the command:
new role /rolename

You can then set the Description attribute of the ROLE.
Then create the Perops which are owned by the ROLE:
new perop /name

Now set the attributes of the Perop:
Operator Attributes
The Operator attribute are attributes which define the operations that the Role will
allow. There are six attributes, each of which can be set to GRANT, DENY or IGNORE.
OpCreate If Create is set to Grant, the Perop will

allow users to create the elements
specified in the Perop's Eclass attribute,
and set their attributes specified in the
Perop's Aclass attribute .
OpModify If Modify is set to Grant, the Perop will
allow users to modify the attributes
(specified in the Perop's Aclasss
attribute) of the elements (specified in
the Perop's Eclass attribute).
OpDelete If Delete is set to Grant, the Perop will
allow users to delete the elements
specified in the Perop's Eclass attribute.
OpClaim If Claim is set to Grant, the Perop will
allow users to make a user claim or an
extract claim.
OpIssue If Issue is set to Grant, the Perop will
allow users to issue changes from
extract databases.
OpDrop If Drop is set to Grant, the perop will
allow users to drop changed from the
extract database.
Note: Alltheoperationsyourequiremustbespecifiedexplicitly.For
example,ifyouselectCreate,youmustalsoselectModifyand
Delete,ifthatiswhatyouwant.

The Element Class (Eclass) attribute of the Perop specifies all the element types on
which the user can perform the operations specified.
Note: Allelementsmustbespecifiedindividually:thepermissiondoes
notcascadetothemembersoftheelementsspecified.Hence,if
youwantthePeroptogivepermissionsapplyingtoBranch
members,youwillneedtospecifyeachPipingcomponent(ELBO,
FLAN,GASKetc.)individually.
You can use the NOT keyword to stop users changing a small number of elements: for
example, setting the Eclass to
NOT SITE ZONE
means that users will be able to change all elements except SITEs and ZONEs.
Aclass
The Attribute Class (attribute Class) of the Perop can be set to ALL, or a list of the
Attributes which the Perop allows to be set or changed. You can use the NOT keyword
to stop users changing a small number of attributes: for example, setting the Aclass to
NOT ABORE HBORE TBORE
means that users will be able to change all the attributes of the elements given in
Eclass except ABORE, HBORE and TBORE.
Note that you can also use User-defined attributes (UDAs) in this setting.
Condition
The Condition is a PML expression which further restricts the elements to which the
operations can be applied. For example:
ABORE OF BRANCH LT 150MM
Acrmessage
If you specify a Condition, you can set a message which will be output when the User
is refused access to the element because the condition is not met. For example:
You can only create branches with bore less than 150MM

5.4 Creating Scopes

Note that, unlike Roles, Scopes are project-specific, and they are defined in terms of
specific parts of the project data. For example, you can specify a Scope as being a
given Site (in DESIGN) or Drawing (in DRAFT).
To create a Scope, navigate to the Scope World /*SC (in the System database) and
give the command:
new scope /scopename

The most important attribute of the Scope is SCOSEL, which actually defines what the
Scope is. It is set to a PML expression. For example:
ALL ZONE WITH FUNC EQ PIPE
You can also set the Description attribute of the Scope.
5.5 Creating ACRs

To create an ACR, navigate to the ACR World /*ACR (in the System database) and
give the command:
new acr /acrname

The most important attributes of ACRs are
The ROLEREF, which must be set to the name of a Role, for example:
roleref /roleA
The SCOPEREF, which must be set to the name of a Scope, for example:
scoperef /pipezones
You can also set the Description attribute of the ACR.
ACRs can be collected into ACR Groups, which can then be assigned to Users. ACR
Groups can only contain ACRs, not other ACR Groups.
5.6 Assigning ACRs to Users

The next step is to assign ACRs to Users, by setting the ACRLI (ACR List) attribute of
each user to contain all the ACRs needed by that user. For example:
acrli /acr1 /acr2 /acrgrp1 . . .
5.7 How ACRs are Applied

A User can have several ACRs. For example, someone might be able to create, modify
and delete all types of Pipework in one area, but only be able to modify certain
attributes of Steelwork.
When you are planning how to set up ACRs for your Users, the main thing to
remember is that once DAC is switched on, no General Users have write access to
anything unless they are given an ACR that allows it.

When a User attempts to carry out a task, the list of the User's ACRs will be checked
until an ACR that allows the task is found. For example, consider a User trying to
create a Pipe with a bore of 15. There may be one ACR which allows creation of Pipes
with bore less than 100, and a second ACR which allows creation of Pipes with bore
less than 200: the operation will be allowed
Negative ACRs (that is, ACRs which use negative Perops) are processed differently.
Once PDMS has found a negative ACR which excludes a user from carrying out a
task, it will look no further in the list. This means that for efficient performance,
negative ACRs should be placed at the top of the User's ACR list.

5.8 Using UDAs in DAC

You can set the Aclass (Attribute Class) to restrict access to elements with particular
attributes, which can include UDAs.
If you want to use UDAs, you must:
Modify the ADMIN Module definition to give access to DICT databases using the EDIT
MODULE command in ADMIN as follows:
EDIT MOD ADMIN MODE DICT READ
Set up an MDB containing the DICT database in which the UDAs are stored, and make sure
you select it as you enter ADMIN. Users will also need to have read access to the DICT
database via their MDBs.
The following simple scenario illustrates how you could use UDAs in Data Access
Control combined with extracts, to control work flow.
The Designer Role would give access to all Piping elements except those with the
UDA :ISSUED set to TRUE.
Designer creates data in

working extract and issues
Working extract to PIPE/CURRENT
for USERA
ISSUE
Data is checked by user

CHECKER who does not
PIPE/CURRENT have a working extract of
User CHECKER PIPE/CURRENT
If OK, :CHECKED set to
TRUE and elements issued to
ISSUE
PIPE/CHECKED
Now Designers cannot modify
checked data.
PIPE/CHECKED

Exercise 2 - Data Access Control
Create a DAC set that only allows a piping

engineer create and modify pipes.
Make sure you set the ACR up so that the
user cannot create anything other than pipes
and below.
Assign this new ACR to USERA, created in
Exercise 1.
Go into PDMS and test the users access to
DESIGN.
ADVADM44

Summary
Extracts
Existing Multiwrite facilities
Extracts and there benefits
Extract operations in Design
Working and Variant Extracts
Data Access Control
Scopes and Roles
Access Control Rights
ADVADM45

Exercise 3 - Working Extracts
In ADMIN, create the structure shown below:
TeamMaster
DB
MDBMASTER
UserMaster
TeamA TeamB
Extract Extract
MDBA UserA UserB MDBB
AA AB BA BB
ADVADM46


Having created the teams, databases, users
and MDBs, add the databases to the relevant
MDBs and any other catalogue databases you
require. Use MDB /TRAINA as a template.
If you enter PDMS as a working extract user
(AA) then when you set the MDB /MDBA, the
working extract will automatically be swapped
into the MDB for that user.
Try working in DESIGN as a working extract
user and issue the work. Enter PDMS as
USERA and issue the work to the Master db.
ADVADM47

Check the Master DB has the data you
expected.
Experiment with the set-up and familiarise
yourself with each db and its role in the
structure.
ADVADM48

E x e r c is e 4 - D a ta A p p r o v a l
U s in g A C R S a n d th e s tr u c tu r e c r e a te d in
E x e r c is e 3 , d e fin e a n a p p r o v a l m e c h a n is m t h a t
w ill o n ly a llo w th e f o llo w in g :
U ser E le m e n t s A ttrib u te s C o n d it io n O p e r a t io n s
AA P ip e a n d B r a n A ll F u n c o f P ip e e q P r e lim in a r y C la im , M o d if y
AA B e lo w P ip e A ll F u n c o f P ip e e q P r e lim in a r y C r e a t e , M o d if y , D e le te
AA P ip e F u n c o f P ip e e q D e s ig n e d Is s u e
USERA P ip e F u n c o f P ip e e q A p p r o v e d Is s u e
USERA P ip e A ll C re a te
USERA P ip e Func F u n c o f P ip e e q D e s ig n e d M o d if y
ADVADM 49

Exercise 4 - Data Approval
Go into PDMS as USERA and create some
pipes and set the function to Preliminary
Now go in as the piping user AA and create
the piping components and test your ACRs.
Change the function to Designed and issue
the completed pipe.
Finally go into PDMS as USERA and change
function of a pipe that is Designed to
Approved and issue.
ADVADM50

Exercise 5 - Project Structure

Consider your companys requirements for
access control and approval mechanisms and
the way in which they divide the data into
databases.
Design an extract structure for the a typical
project procedure within your company using
the new ADMIN facilities available.
Draw your structure out before creating it
within PDMS ADMIN.
ADVADM51

Review and Feedback
Session 4
Review and Feedback
Reference and Further Reading

Summary
Discussion
Feedback from Training Course Delegates
Review and Feedback 4-1 Advanced ADMIN Training Manual

Review and Feedback
Reference and Further Reading
Other Sources of Information*
The PDMS ADMIN Command Reference Manual. See

C:\CADCENTRE\pdms11.3\manuals\pdms1131\man17\doc1.pdf
The PDMS ADMIN User Guide. See

C:\CADCENTRE\pdms11.3\manuals\pdms1131\man18\doc1.pdf
The Online Help
*In a standard installation of PDMS 11.3
Also available
Using PDMS Global Management.
PDMS Global User Guide.
PDMS ADMIN Command Reference Guide.

Review and Feedback
Summary
Database Extracts
Database Extract Families
Data Access Control
Roles, Scopes and Perops

Review and Feedback
Discussion
Clarification and comments arising from these

sections
Discussion on the complete course

Advanced Admin Pdms

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Advanced Admin Pdms

Încărcat de

Drepturi de autor:

Formate disponibile

Advanced ADMIN

Copyright 2017 AVEVA Limited

AVEVA Ltd, High Cross, Madingley Road, Cambridge CB3 0HB, UK

Session 1: Introduction To The Course

Session 2: Database Extracts

Session 3: Data Access Control

Session 4: Review and Feedback

Introduction 1-1 Advanced ADMIN Training Manual

Introducing the course

At the end of this session you will be able to:

Introduction 1-2 Advanced ADMIN Training Manual

Training material Practical exercises

Introduction 1-3 Advanced ADMIN Training Manual

Introduction 1-4 Advanced ADMIN Training Manual

Extended Multiwrite Facilities

Review of Simple Multiwrite Databases

Database Extracts 2-1 Advanced ADMIN Training Manual

An Extract db provides a means of working on

Database Extracts 2-2 Advanced ADMIN Training Manual

Extract dbs - Features

When an Extract is created it is essentially an

Claim mode must be set when a Multiwrite db is created.

Database Extracts 2-3 Advanced ADMIN Training Manual

An extract is created from an existing Database. When an Extract is created, it

1.1 Extract Families

Database Extracts 2-4 Advanced ADMIN Training Manual

The following diagram illustrates an example of an extract family hierarchy:

PIPES_X10 PIPES_X11 PIPES_X12

Database Extracts 2-5 Advanced ADMIN Training Manual

1.1.1 Querying Extract Families

EXTNO Extract Number

1.2 Creating Master and Extract Databases

1.2.1 Creating Master Databases

1.2.2 Creating Extracts (including Global working practice)

Database Extracts 2-6 Advanced ADMIN Training Manual

If the current location is a satellite

Note that the ALLOCATE Command allows child extracts to be allocated to a

1.2.3 Creating Working Extracts

Database Extracts 2-7 Advanced ADMIN Training Manual

Database Extracts 2-8 Advanced ADMIN Training Manual

Extract dbs - Benefits

They allow persistent claims - changed

Database Extracts 2-9 Advanced ADMIN Training Manual

An Extract can be created from another Extract.

PIPES_X1 PIPES_X2 First-level Extracts

PIPES_X10 PIPES_X11 PIPES_X12 Second-level Extracts

Database Extracts 2-10 Advanced ADMIN Training Manual

Multiple Databases vs. Extracts

Database Extracts 2-11 Advanced ADMIN Training Manual

2 Setting up an Extract Hierarchy

PIPE/PIPE File number 200

First level extract

PIPE/REVIEW File numbers will be 200_xxxx,

Second level extract

PIPE/CURRENT File numbers will be 200_xxxx,

Working extract Working extract Working extract

Working extracts are identified as

Database Extracts 2-12 Advanced ADMIN Training Manual

PIPES_X10 PIPES_X11 PIPES_X12

Database Extracts 2-13 Advanced ADMIN Training Manual

PIPES_X10 PIPES_X11 PIPES_X12

Database Extracts 2-14 Advanced ADMIN Training Manual

PIPES_X10 PIPES_X11 PIPES_X12

Command syntax for FLUSH: