11.5 M26 Advanced Administration

Version 11.
Module 26
Advanced Administration
Training Manual
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 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.
Copyright 2004 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

Contents
Session 1 ..................................................................... 1-1

Extract Databases ....................................................................................... 1-1
Objectives .................................................................................................. 1-1
Must Know Points ...................................................................................... 1-1
Review of Simple Multiwrite Databases ..................................................... 1-2
Claim mode................................................................................................ 1-2
Extracts ...................................................................................................... 1-3
Extract DBs Features .............................................................................. 1-4
Types of Extract Databases ....................................................................... 1-5
Standard Extracts............................................................................. 1-5
Working Extracts .............................................................................. 1-5
Variant Extracts................................................................................ 1-6
Write access to Extracts Databases........................................................... 1-7
Extract Families.......................................................................................... 1-8
Querying Extract Families .......................................................................... 1-9
Multiple Databases vs. Extracts ............................................................... 1-10
Operations on Extracts in Design............................................................. 1-11
Extract Claim.................................................................................. 1-12
Get All Changes ............................................................................. 1-13
Flush .............................................................................................. 1-14
Issue .............................................................................................. 1-15
Drop ............................................................................................... 1-15
Creating Standard Extract Databases...................................................... 1-15
Testing Standard Extract Databases in Design........................................ 1-21
Creating Working Extracts ....................................................................... 1-25
Testing Working Extracts in Design ......................................................... 1-26
Variant extracts ........................................................................................ 1-26
Session 2 ..................................................................... 2-1

Data Access Control (DAC) ......................................................................... 2-1
Objectives .................................................................................................. 2-1
Must Know Points ...................................................................................... 2-1
Improved Data Access Control (DAC)........................................................ 2-2
Access Control Rights (ACRs), Roles and Scopes .................................... 2-3
Permissible Operations (Perops) ............................................................... 2-3
Enabling DAC ............................................................................................ 2-4
Creating a Scope ....................................................................................... 2-5
Creating a Roles ........................................................................................ 2-6
Role for ALL Access......................................................................... 2-6
Module 26 Advanced Administration Issue 04/12/03 Contents-i

Contents
Role for Piping Designer Access ......................................................2-7

Role for Equipment Designer............................................................2-9
Role for Pipe Support Designer ........................................................2-9
Access Control Rights (ACR) .....................................................................2-9
Create an ACR for ALL .....................................................................2-9
Create ACR for Equipment and Piping ...........................................2-10
Setting User Access .................................................................................2-11
Testing PDMS Access Control..................................................................2-12
Querying DAC in Design...........................................................................2-14
Using Negative DAC.................................................................................2-15
Setting DAC for use with MDS..................................................................2-16
Contents-ii Error! No text of specified style in document. Training Manual

Session 1
Extract Databases
Extract databases provide a method of controlling the issue of PDMS information to

other Designers within a PDMS project. An example of this is passing information to
a check or approved database.
Database Reports, Isometrics, Drawing etc can be generated from databases that
have a known state for example drawings for checking will only be produced from
the check database.
Objectives
At the end of this module, you will able to:
Explain the basic concepts of Extract Databases
Create Standard and Working Extract Databases
Be able to Create, and Issue PDMS elements
Must Know Points
The following points need to be understood by the trainees:

How to create Extract Databases
Know the difference between Standard, Working and Variant Extract Databases
Know how to control the issue of PDMS databases elements
Module 26 Advanced Administration Issue 04/12/03 1-1

Extract Databases
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.
Claim mode
Claim mode is set when a Multiwrite db is created but can be changed as required.
Explicit claim - you must claim any element you wish to change before the
modification starts.
Implicit claim - an element will be claimed automatically when it is modified.
Elements can be unclaimed at any time, providing they have not been modified since
the last SAVEWORK.
1-2 Module 26 Advanced Administration Issue 04/12/03

Extract Databases
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.
The unchanged data will still be read via pointers back to the Master db.
Claims made in this way are persistent.
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.
Extract A and Extract B are extract from the same master database.

Extract Databases
Extract DBs - Features
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.
You can create Extract dbs from any db that can be Multiwrite, i.e. DESI, PADD,
CATA and ISOD.
Extracts can only be created from Multiwrite dbs and are themselves Multiwrite.
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.
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.

Extract Databases
Types of Extract Databases
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.
Working Extracts
are one per user Extracts
only require the use of a single MDB
DROP operations only remove one users changes

Extract Databases
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.

Extract Databases
Write access to Extracts Databases

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.

Extract Databases
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.
The following diagram illustrates an example of an extract family hierarchy:
PIPES Master
PIPES_X1 PIPES_X2 First-level
PIPES_X10 PIPES_X11 PIPES_X12 Second-level
In this example: -
PIPES is the Master
and the parent of PIPES_X1
PIPES_X1 is a child of PIPES
and the parent of PIPES_X10
PIPES_X10 is a child of PIPES_X1
The members of PIPES are PIPES_X1 and PIPES-X2.

Extract Databases
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

Extract Databases
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 2)
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

Extract Databases
Operations on Extracts in Design
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
PIPES_X10 PIPES_X11 PIPES_X12
If your extract database has been set-up in implicit claim mode then all you need to
do is modify the item and it will be claimed automatically.
Items can be claimed using Utilities > Claim Lists

Extract Databases
Get All Changes
Updates an Extract with changes made in the owning db. Get all changes 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). This is similar to doing a Getwork on a normal
database.
change
PIPES
change
PIPES_X1 PIPES_X2
PIPES_X10 PIPES_X11 PIPES_X12
Design > Extract Control
Get All Changes
NOTE the C in the Elements window showing that the Item is Claimed.

Extract Databases
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.
change
PIPES
PIPES_X1 PIPES_X2
change
PIPES X PIPES_X11 PIPES_X12
Flush
After a Flush the Item is still claimed. This is an example of a persistent claim.

Extract Databases
Issue
Local changes are copied to the owning db, and the elements are released. Users
who have access to the owning db can now see the changes and can make changes
of their own to the elements.
change
PIPES
PIPES_X1 PIPES_X2
change
PIPES X PIPES_X11 PIPES_X12
Issue
Following an Issue the Item will NOT be claimed.

Extract Databases
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.
Creating Standard Extract Databases

The following section has been written as a worked example of creating extract
databases. This manual assumes that you are familiar with Basic Administration.
Create 3 new Teams MASTERA, EXTEAMB and EXTEAMC.

Extract Databases
Create 3 new Users APPRUSER/A, EXUSERB/B and EXUSERC/C and make them
members of the corresponding teams.
Create a new Master DB MASTERA/DESI and set access to Multiwrite.
This first database is the master databases so make sure you tick the Master DB
button

Extract Databases
Standard Extracts
We are now going to create 2 extracts of the DB and place them in separate teams
i.e EXTEAMB/DESI_X1 and EXTEAMC/DESI_X2.In admin on the main admin
element form select Databases and Extracts.
This time select An Extract of a DB

Extract Databases
Currently on this project there is only one multi-write database, the one we have just
created. Create the database EXTEAMB/DESI_X1 based on MASTERA/DESI and
repeat the operation to create EXTEAMC/DESI_X2.

Extract Databases
You will notice that because extract databases are Multi-write they themselves are in
the top box Databases for Extract , extracts can be made from extracts.
Extract databases are indicated in Admin with an X

Extract Databases
Create 3 MDBs, MASA, EXTB and EXTC i.e. one for each DB. Copy the mdb
/SAMPLE and put the dbs in the corresponding mdbs. at the top.
Make sure in each case that the first database is the correct one for that MDB in the
above example it is MASTERA/DESI.

Extract Databases
Testing Standard Extract Databases in Design
Enter PDMS as APPRUSER (master db) in mdb /MASA. Make the main display
window small in height and put it at the top of the screen.
Enter PDMS as EXUSERB (extract db) in mdb /EXTB. Make the main display
window small in height and put it at the bottom of the screen.

Extract Databases
In APPRUSER (top of screen) create a SITE and name it /APPROVED then create a
Zone and some pieces of Equipment. Savework.
In EXUSERB (bottom of screen).
Select Design>Extract Control and press the 'Get All Changes' button
The form will refresh and the equipment is shown after you click in the elements part
of the form.

Extract Databases
We will now create equipment in EXUSERB (bottom of screen).
Navigate to the equipment zone you have just created and Create Equipment /EQ-3
To show the items that are claimed by the Extract, on the members form select
Control>Show Extract Claim and a * appears at the side of the claimed element.
In EXUSERB (bottom of screen). Savework
In APPRUSER (top of screen). Getwork. You will notice that the new equipment
/EQ-3 did NOT appear, this is because the equipment has not been Flushed or
Issued to the master.

Extract Databases
In EXUSERB (bottom of screen). Display Design > Extract Control.. Form
You will notice that /EQ-3 has C and M against it indicating that it has been
Claimed and also Modified whilst the owning zone just has an M indicating that it
has been Modified.
In EXUSERB press the 'Flush' button
In APPRUSER Getwork should display the new equipment created by EXUSERB.
When you do a Flush items are available in the owning database but remain
Claimed. At this point the Extract Control Form will just be showing a C against /EQ-
3
I you try for example to change the name of /EQ-3 in the Master database as
APPRUSER you will get a message similar to this: -

Extract Databases
In order for another designer to modify the equipment /EQ-3 you will need to issue
the equipment. This will release the claim.
At this point you may wish to try some of your own example of creating, deleting and
renaming items in both of these databases.
Creating Working Extracts
Working extracts are allocated to users, we are going to create working extracts for 3
users USERA,B and C to database MASTERA/DESI.
In Admin Select Working Extracts from the Admin Elements form and Create
Working Extracts
Select database MASTERA/DESI. And select USERA, USERB and USERC in the
User List. This will create 3 new db's again all with the same db number but 3 new
db file numbers.

Extract Databases
You do not need to create a new mdb for Working Extracts. You can enter PDMS in
the same mdb for all 3 users as access is controlled by the username. Obviously, the
3 users must be added to the team MASTERA.
Testing Working Extracts in Design
Enter PDMS as USERA in mdb /MASA and
Enter PDMS as USERB in mdb /MASA
Create some equipment as USERB and Savework.
Use the Extract Control Form to Flush or Issue the database changes back to the
Master database.
Variant extracts
Both standard and working extracts can be variant extracts. Variants are a special
type of extracts in which elements are not claimed from the owner. They are
designed to allow users to try out different designs, which then may or may not be
written back to the master.
When variants are used, all changes are merged together on issue. Changes are
handled at attribute level, so that different users can change different attributes on
the same element and then merge there changes.
No locking is applied to a variant extract, and any locks applied to other extracts are
ignored. This allows many users to modify the same element in a given session, but
has the disadvantage that any conflicts will not be found until the changes are
issued. If two users modify the same attribute, the last change to be merged takes
precedence.
PDMS will ensure that all merges comply with the basic database rules, that is, the
data will comply with all DICE checking requirement, but it cannot check that the
data makes sense in PDMS design terms.
It is recommended; therefore, that data consistency and clash checks are carried out
on the resulting merged data.

Session 2
Data Access Control (DAC)
Being a member of the team that owns the database controls write access in PDMS.
With the advent of multi-write databases designers may have been given to much
write access. By using DAC the PDMS administrator can restrict the access to
PDMS types, names or particular areas of the PDMS design.
Objectives
At the end of this module, you will able to:

Understand how DAC can help with the control of PDMS data
Be able to create simple DAC.
Be able to use DAC in Design to control the update of data.
Must Know Points
The following points need to be understood by the trainees.

The importance DAC in controlling the update of PDMS data.
How to switch DAC On or Off.
How to create Roles, Scopes and ACR and test these within the PDMS project.

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:
o Restrict Users access to named elements or given element types, or

particular volumes of the model.
o Restrict the type of operation a User can carry out on elements.
o Restrict which attributes a User can set or change.
DAC can be applied to Update or Multiwrite (controlled or uncontrolled)

databases.
Normal PDMS data access control will apply to the Project unless the Data
Access Control option in ADMIN is switched on.
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.

Data Consistency Checker
Access Control Rights (ACRs), Roles and Scopes
Each User can be given one or more ACRs.
Each ACR consists of: -
A Role, which defines what operations the designer can carry out on which
elements. Example Roles - Create, Modify and Delete all types of PDMS elements.
A Scope, which defines the part of the Design to which the Role applies. Example
Scopes - a particular Site in DESIGN or Registry in DRAFT, or a specified volume
within the model.
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.
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.

Enabling DAC
In Admin Select Project > Data Access Control
Select YES
Remember General Users do NOT have any access to PDMS elements until and
ACR is created for them.

Creating a Scope
Scopes define the area of the plant where the PDMS Designer can work. We will
create a scope that covers any area in the PDMS Model.
Select Scopes from the Admin Elements form and press Create.
Enter ALLSCOPE for name and ALL for Scope Selection.
You could be more selective here by entering the name of a SITE or a ZONE etc.
Apply and Dismiss the form.
Note:- The syntax for scopes is pml style syntax typically for a site named
/SITE-AREA100 the Scope Selection syntax would be:
ALL WITH NAME OF SITE EQ /SITE-AREA100

Creating a Roles
Role for ALL Access
Select Roles from the Admin Elements form and press Create.
Enter ALL-DESIGNER for name and Apply.
Press the now activated Create button.
Enter ALLELE for name of the

Permissible Operation
(Perop). Enter ALL in the Add Type or

press the All button.
For Operations change all the option

gadgets to be Allow i.e. Modify Allow,
Create Allow, Delete Allow, Claim Allow
etc.
Apply and Dismiss the Create Role form

Role for Piping Designer Access
We are going to create a role of piping designer that can create pipes and pipe
branches providing that the pipe has not been issued. The Pipe Designer can also
connect and orientate nozzles.
Select Roles from the Admin Elements form and press Create.
Enter PIPE-DESIGNER for name and Apply.
Press the now activated Create button.
Enter PIPE-DESIGNER-PIPE for name

of the Permissible Operation (Perop).
Enter PIPE in the Add Type text gadget

and return. This is known as a PEROP.
A Qualifying Condition is set to -
Purpose of Zone eq 'PIPE' and Function

neq ISSUED.
For Operations set all the option

gadgets to be Allow.
Attributes - ALL

Create another PEROP to allow the Pipe Designer the ability to connect to nozzles.
Select Create
Enter PIPE-DESIGNER-NOZZ for

name.
Enter NOZZ in Add Type.
For Operations set the option gadgets to

be Create Disallow, Delete Disallow,
Modify, Claim, Issue and Drop Allow.
Allow modification to ORI CREF and

POS only.
Create another PEROP for Branches.
Enter PIPE-DESIGNER-BRAN for

name of the Permissible Operation
(Perop).
Enter BRAN in the Add Type text gadget

and return and tick the hierarchy box.
For Operations set all the option

gadgets to be Allow.
For Qualifying Condition enter
Function of Pipe neq ISSUED.
If a pipe has this attribute set you cannot

modify it.

Role for Equipment Designer
Now create role for the Equipment Designer, allow the equipment designer to create
the equipment hierarchy but only where the purpose of the zone is EQUIP.
Role for Pipe Support Designer
Discuss with your trainer what access a pipe support designer might require if they
were going to use MDS or a similar pipe support system that may need access to
Pipes, and steelwork. Think about the PDMS items they might need to create or
modify.
Access Control Rights (ACR)

ACRs are used to link Roles and Scopes, remember a role is what you can do and a
scope is where you can do it.
We are going to create ACRs for All Items (or Supervisor), for Pipes and Equipment
Designers.
Create an ACR for ALL
Select ACRs & ACR Groups on the Admin Elements form and press Create.
Leave the toggle gadget set to Access Control Rights and press OK.

Enter ALL-DESIGN for name. Select ALL-DESIGNER for Roles and ALLSCOPE for
Scopes. Apply the form.
Create ACR for Equipment and Piping
Repeat the process and create an ACR for ALL-EQUIPMENT, ALL-PIPES.

Setting User Access

Remember once DAC has been set on then the default access to PDMS is no
access, and ACR must be set for each user.
USERA will be the Supervisor and will have all access.
USERB will be a piping designer and will be given Pipe Designer Access and
USERC will be the equipment designer.
Select Users on the Admin Elements form Select USERA and press Modify.
The bottom part of the form

shows the ACRs
The left pane shows all the

ACRs available on the
project whilst the right hand
pane shows the user ACRs.
For USERA select ALL-

DESIGN in the project pane
and move it to the Users
ACRs
Apply and Dismiss the

form.
Repeat the process for USERB and USERC selecting the correct ACR in each case.

Testing PDMS Access Control
To recap: -
USERA can create anything anywhere
USERB can only create pipes in a zone with a purp of PIPE where the pipe
has not been issued.
USERC can only create equipment in a zone where the purp is EQUI.
Things you might wish to test: -

USERA test that you can create SITE, ZONES etc.
USERB test you can create Pipes, Branches and components.

test you can only create pipes in a zone with the purp set to
PIPE.
Change the Function of the pipe to ISSUED
A good way to test this is to user the Modify > Attributes form at pipe level: -
You will notice a DAC column showing (+)

if the attribute can be updated and (-) if
the attribute cannot be updated.
Select Function and set it to Issued.
Select the OK button.

Select the Apply button you will get the following dialogue box: -
Select YES You will now not be able to modify the pipe or is Hierarchy.
You should also notice that all the attributes on the attributes form is set to (-)
indicating that they can not be updated.
USERC Test that you can only create Equipment in a zone where the
purp is EQUI

Querying DAC in Design
You can query your access in design using Query > Project > User Rights .

Using Negative DAC

Up to now we have only created positive DAC, for example the designer could create
a pipe or a structure etc.
We will now consider negative DAC where the designer is first given all access and
then access is taken away.
The advantage of doing DAC this way is that you can get PDMS to give out more
meaningful massages, the disadvantage is that there will be more PEROPs for each
Designer.
Earlier in the training we created a Role ALL-DESIGNER we will modify this role to
stop the designer creating equipment.
In Admin modify the Role ALL-DESIGNER and create a new Perop.
Name /NOT-EQUIPMENT
Set the element to EQUIP Hierarchy
Message to You can not Create

Equipment
Operations are all set to Disallow.
Apply and Dismiss
Enter PDMS at USERA and check that you can create all items except Equipment
and below.

Setting DAC for use with MDS
Earlier in the course you will have discussed with your trainer the access that you
might need if you were a pipe support designer.
The following DAC could be used with the AVEVA Multi Discipline Support system
(MDS).
The support designer would need access to branch members to create ATTAs, swap
elbows, tees etc. He would also need to create branches for Trunnions, SNODS and
joints on steel and create structures but only if the purp of the zone is SUPP.
To help with in this area a variable !!MDSACCESS is set to TRUE if MDS is

running.
The following is a list of the required PEROPs for MDS: -
Access to
Condition
Element
BRAN HEIR VTEXT !!MDSACCESS EQ 'TRUE'
REST HEIR VTEXT !!MDSACCESS EQ 'TRUE'
SNOD HEIR ATTRIB PURP OF ZONE EQ 'STL' AND VTEXT !!MDSACCESS EQ 'TRUE'
STRU HEIR ATTRIB PURP OF ZONE EQ 'SUPP'

11.5 M26 Advanced Administration

Î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

11.5 M26 Advanced Administration

Încărcat de

Drepturi de autor:

Formate disponibile

Version 11.

Copyright 2004 AVEVA Limited

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

Session 1 ..................................................................... 1-1

Session 2 ..................................................................... 2-1

Module 26 Advanced Administration Issue 04/12/03 Contents-i

Role for Piping Designer Access ......................................................2-7

Contents-ii Error! No text of specified style in document. Training Manual

Extract databases provide a method of controlling the issue of PDMS information to

Must Know Points

The following points need to be understood by the trainees:

Module 26 Advanced Administration Issue 04/12/03 1-1

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.

Claim mode can be explicit or implicit.

Elements are unclaimed by a module change or EXIT.

Only primary elements can be claimed.

Implicit claim - an element will be claimed automatically when it is modified.

1-2 Module 26 Advanced Administration Issue 04/12/03

An Extract db provides a means of working on data in a Master db without the

A user claims elements to work on in the Extract. A SAVEWORK saves work

Claims made in this way are persistent.

Module 26 Advanced Administration Issue 04/14/03 1-3

Extract DBs - Features

An extract is created from an existing Database.

You cannot create Extracts from foreign dbs.

You cannot create Extracts from copy dbs.

1-4 Module 26 Advanced Administration Issue 04/12/03

Types of Extract Databases

Claiming can be implicit or explicit - if an element is being worked on by any user in

are one per user Extracts

only require the use of a single MDB

DROP operations only remove one users changes

Module 26 Advanced Administration Issue 04/14/03 1-5

Any element can be modified, i.e. elements are NOT claimed.

1-6 Module 26 Advanced Administration Issue 04/12/03

Write access to Extracts Databases

The user must be a member of the Team owning the Extract.

The user must select an MDB containing the extract.

Data Access Control can be applied.

Module 26 Advanced Administration Issue 04/14/03 1-7

The extracts immediately below an extract are known as extract members.

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

PIPES_X1 PIPES_X2 First-level

PIPES_X10 PIPES_X11 PIPES_X12 Second-level

PIPES is the Master

and the parent of PIPES_X1

PIPES_X1 is a child of PIPES

and the parent of PIPES_X10

PIPES_X10 is a child of PIPES_X1

The members of PIPES are PIPES_X1 and PIPES-X2.

1-8 Module 26 Advanced Administration Issue 04/12/03

Querying Extract Families

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