Database Management

Reference Manual
AVEVA Solutions Limited

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.

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.
Database Management Reference Manual

Revision Sheet

Date Version Comments / Remarks

September 2011 12.1.1 Add section on Define Dynamic Groups.

Model Changes and Revert Element added.

January 2012 Copyright added to all pages.
January 2012 12.1.2 Added new section in Sequence Number Generator: 18.5 Use
of Name Sequences in Marine applications.
January 2012 12.1.2 Added new chapter Copying Data between Projects.
October 12.1.SP3 New section in 2 Database Navigation and Query Syntax; 2.9
Use the BACKREf attribute.
October 12.1.SP3 New Chapter; 21 Cleanup and the CLEANUp Command
Database Management Reference Manual
 Database Management Reference Manual

Database Management Reference Manual

Contents Page

Reference Manual
Introduction to Database Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Project Organisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:1
Teams and MDBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:2
Splitting Data Across Multiple DBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:3
Database Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:3
Reference Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:3
Name .............................................................. 1:4
Current Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:4
Change Element Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:4
Primary Database Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:4
Hierarchical Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:4
User Defined Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:5
Element Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:5
Where the Primary Hierarchy is Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:6
Secondary Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:6
Database Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:7
User Defined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:7
Pseudo Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:7
Global Namespace for Attribute and Element Type Names. . . . . . . . . . . . . . . . . . . . . . . . . 1:8
Attributes of Physical Quantities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:8
Database Expressions and Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:8
Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:8

© Copyright 1974 to current year. i 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:9
Dumping out the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:9
Data Listings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:9
Reconfigurer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:9
Database Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:10
Data Access Control (DACs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:10
Errors Applicable to all Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:11
Integrity of Modifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:11
Element Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:12
Element Deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:12
Element Copy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:12
Element Move . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:12
Attribute Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:12
Effect of Modifications on Dynamic Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:14
Database Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:14
Savework/Getwork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:14
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:14
Session History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:15
Create a Stamp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:16
Set a Comparison Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:16
Merge Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:16
Multiwrite Working . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:17
Multiwrite Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:17
Claim Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:17
Release Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:18
Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:18
Potential Conflicts at SAVEWORK/GETWORK in a Multiwrite Environment . . . . . . . . . . . 1:18
Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:18
Create Extracts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:19
Restrictions on Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:19
Extract Sessions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:19
MERGE CHANGES on Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:20
Extract Claims/Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:20
Extract Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:21
User Claims/Releases on an Extract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:21
Variants ............................................................. 1:22
Extract Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:22
Merge Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:22
Dealing with Deleted Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:24

© Copyright 1974 to current year. ii 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

Flushing Connected Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:24

Errors for Extract Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:24
Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:25
Global Working. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:25
Global Propagation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:25
Extract Claim/Release with Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:25
Flush with Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:26
Merge Changes for Global Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:27
Undo Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:27
Undo/Redo within a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:27
Backtrack/Rewind. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:27

Database Navigation and Query Syntax . . . . . . . . . . . . . . . . . . . . . . 2:1

Current Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
Current Position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
PML DBRef Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
PML !!CE Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:1
Specify the Standard Name. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:2
Specify the Constructed Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:2
Specify the World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:2
Specify the Refno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:2
Use the BACKREf attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:2
Specify a Relative Position in the Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:3
Climb Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:3
Move within the Current Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:3
Move to Next Lower Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:5
Syntax Ambiguity Between Moving Across and Down . . . . . . . . . . . . . . . . . . . 2:7
Climb up by Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:7
Use the ‘OF’ Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:7
Other Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:8
Use the GOTO Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:8
Return to the Previous Current Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:8
ID Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:8
Special Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:9
UDETs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:9
Trace Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:9

© Copyright 1974 to current year. iii 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

Pseudo Attributes Relating to Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2:10

Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Attribute Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:1
Real Attributes of Physical Quantities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:2
Values of Physical Quantities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:4
Standard Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:5
SI Unit Prefixes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:8
Compound Units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:9
Units of Absolute and Gauge (gage) Pressures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:10
Query Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:11
Query the List of Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:11
Standard Attribute Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:11
Query Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:12
dot Notation in PML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:13
Qualifier ............................................................. 3:13
Relative Positions, Directions, Orientations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:14
Summary of Related Pseudo Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:14
Set Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:15
Standard Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:15
Set a UDA Back to a Default . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:17
Set an Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:17
Single Value of an Array. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:17
Special Syntax for Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:17
Special Syntax for LOCK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:18
Related Pseudo Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:19
PML Attribute Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:19
Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:19
Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:19
PML ElementType Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:20
Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:20
Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:20
Related Pseudo Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3:21

Database Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1

Modify the Content of a DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1
Create a New Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:1
Delete an Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:3
Reorganise the DB Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:4

© Copyright 1974 to current year. iv 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

Copy Attributes from One Element to Another . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4:6

Save Work and Get Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1

Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1
Session Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5:1

Multiwrite Databases Claims and Extracts . . . . . . . . . . . . . . . . . . . . 6:1

User Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:1
Notes on Standard Multiwrite DBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2
Extract Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:2
How to Find Out What You Can Claim. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:5
Related Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6:7

Undo and Redo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1

How Undo Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7:1

Groups and Secondary Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . 8:1

Define Group Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:6
Delete Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:7
Copy a Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:7
Define Dynamic Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8:7

Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:1
Format of Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:1
Operator Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:2
Nesting Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:2
Logical Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:2
Logical Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:3
Logical Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:6
Logical Array Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:12
Numeric (Real) Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:12
Numeric (Real) Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:13
ADD and SUBTRACT (+ and -) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:13
MULTIPLY and DIVIDE (* and /) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:14
Numeric (Real) Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:15
Real Arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:24
Units and Physical Quantity Attributes in Expressions . . . . . . . . . . . . . . . . . . 9:25
Using IDs in Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:26

© Copyright 1974 to current year. v 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

Positions, Directions and Orientations in Expressions . . . . . . . . . . . . . . . . . . 9:26

Use Positions in Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:26
WRT ............................................................. 9:27
FROM ............................................................. 9:28
Compare Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:29
POLAR ............................................................. 9:30
Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:31
Orientations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:32
Text Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:33
Text Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:33
Text Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:34
Late Evaluation of Variables in Expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . 9:45
Attributes in Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:45
Query Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:45
Precision of Comparisons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:46
Undefined Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:46
Unset Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:46

Rules to Define Attribute Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 10:1

Set Attribute Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:1
Verify Attribute Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:2
Execute Attribute Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:2
Delete Attribute Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:3
Rules for Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10:3

Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11:1
Comparisons Across Sessions and Stamps . . . . . . . . . . . . . . . . . 12:1
Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:1
Query the Last Modification to an Element or Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:1
Query the Session History for an Element or Attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:2
Query Details of a Specific Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:2
Query Session Number for a Given Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:2
Comparison Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:3
Set the Comparison Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:3
Query the Comparison Date. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:4
MODIFIED Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:4
CREATED Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:6

© Copyright 1974 to current year. vi 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

DELETED Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:6

GEOM, CATTEXT, and CATMOD Special Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:6
Query Any Attribute at the Comparison Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:7
Compare Database Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:8
Compare Database States at Different Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:8
Model Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:9
Revert Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12:13

Output Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:1

General Features of Output Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:2
Principles and Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:2
OUTPUT Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:3
Some Examples of Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:7
Full Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:7
Comment Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:8
Tabulate Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:9
Index Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:10
Brief Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:11
NOUDA Option. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:12
OLDFORMAT Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:12
ONLY Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:13
PASS Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:15
Option Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:17
Locate and Replace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:17
Create Datal Interactively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13:19

Project Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14:1

MDB Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14:1
Check the Current User Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14:2
Check the Current System Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14:2
List Project Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14:3
Query MDB Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14:4
Query Individual Database Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14:5

Link Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:1
Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:2
Link World (LINKWL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:2

© Copyright 1974 to current year. vii 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

Link Folder (LNFOLD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:2

Link Descriptor (LNDESC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:2
Link Class (LNCLAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:3
Command Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:4
Configuring Links Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:4
Link a Document to a Database Element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:4
Unlinking a Document from a Database Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:5
Classify a Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:6
Unclassify a Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:6
Related Pseudo Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:6
Links Addin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15:7

Inter-DB Connection Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16:1

Automatically Prompt the Save Dialogue . . . . . . . . . . . . . . . . . . . . 17:1
Sequence Number Generator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18:1
Create a Name Sequence Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18:1
Enable Usage of Name Sequences from PML . . . . . . . . . . . . . . . . . . . . . . . . . . 18:1
NameSeq Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18:1
Typical Usage of Name Sequences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18:2
Use of Name Sequences in Marine applications. . . . . . . . . . . . . . . . . . . . . . . . 18:2
Name Sequences in Global Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18:3

Distributed Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:1

Terminology and Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:2
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:3
Create Distributed Attribute Group, the UDET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:3
Create the Attributes, as UDAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:3
Create Distributed Attributes Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:3
Default Home Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:5
Create the XPIWLD Home Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:7
Distributed Attributes, Configuration and Usage Details. . . . . . . . . . . . . . . . . 19:7
Distributed Attributes and Default Home Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:7
DSX Hierarchy, Top Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:7
Distributed Attributes Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:8
Default Home Selector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:9
New Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:10

© Copyright 1974 to current year. viii 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

New and Updated Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:11

DATT DELete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:11
Q ATT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:11
Distributed Attributes and Attribute Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 19:11
PML2 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:12
Pseudo Attributes Associated with Distributed Attributes . . . . . . . . . . . . . . 19:12
DLIST - Eligible Distributed Attributes Members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:12
XRLSTT - List Distributed Attributes Member Types Associated. . . . . . . . . . . . . . . . . . . 19:13
XRLIST - List Distributed Attributes Member Associated. . . . . . . . . . . . . . . . . . . . . . . . . 19:13
XRQCNT - Count of Distributed Attributes Member Associated . . . . . . . . . . . . . . . . . . . 19:13
XRQELE - Return a Single Distributed Attribute Member . . . . . . . . . . . . . . . . . . . . . . . . 19:13
ATTDST - List of Attributes to Show . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:14
DFHOME - The Evaluated Default Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:14
Datal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:14
Element Selection, Claim, Flush . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:15
Status Control Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19:15

Copying Data between Projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . 20:1

Design Reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20:1
Copy Assistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20:1
Export ............................................................. 20:2
Import ............................................................. 20:3
Include Associated Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20:3
Restoring Database References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20:5
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20:5
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20:5
Restoring Selected Hull Design Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20:5
Replicate Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20:6

Cleanup and the CLEANUp Command . . . . . . . . . . . . . . . . . . . . . . 21:1

Cleanup and the CLEANUp command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21:1

© Copyright 1974 to current year. ix 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

© Copyright 1974 to current year. x 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

1 Introduction to Database Concepts

This reference manual describes in detail the structure and methods of the internal
databases used within Marine. It is written for System Administrators who may be involved
in maintaining projects, and the databases from which they are created.

1.1 Project

1.1.1 Project Organisation

In order to create data, a user must first create a Project.
A Project consists of:
• One each of System, Comms, and Misc DBs
• Multiple Design, Catalogue, Drawing, and Dictionary DBs
• Various picture files
A project starts with just the System, Comms and Misc DBs.
The user will then have to create other DBs for users to work on. The various visible DB
types are:

System Contains details on DBs, MDBs, teams etc in the project

Dictionary Contains UDA and UDET definitions

Property Contains units for different properties

Catalogue Contains catalogue and specification information

DESIGN Contains Marine design information

Outfitting Draft Contains drawing information

SPOOLER Contains spool information

Materials Contains hull material information

Diagrams Contains Schematic information

Transaction Used by Global to record transactions

SCHEMATIC Contains PI&D (Schematic) information

MANU Contains detailed manufacturing data

NSEQ Stores name sequences

© Copyright 1974 to current year. 1:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

Typically there will be many DBs of each type within a project.

An example of a simple project is as follows:

DBs may be included from other projects.

Each DB has a unique DB number. User DBs have numbers in the range 1-7000. The range
7000-8000 is reserved for AVEVA supplied databases. The range 8000-8192 is reserved for
system databases.
The DB number is assigned to the DB on creation. The user may specify the DB number. If
not specified by the user then the next available DB number is used.
There may never be two DBs with the same DB number in a single project. Thus to include
a DB from another project, that DB number must be unused in the target project.

1.1.2 Teams and MDBs

For ease of working DBs are grouped into Teams and MDBs (Multiple Databases). A DB
belongs to one team, but may be in many MDBs. Users specify the MDB to work on when
entering Outfitting.
Details of DBs, teams, and MDBs are stored in the system database.
An example is shown below.

It can be seen that DB /A is only in MDB /X, whereas DB /B is in both MDB /X and /Y.

© Copyright 1974 to current year. 1:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

Team access controls fundamental write access. Members of Team1 will always have write
access to DBs /A and /B, and read access to the remainder. For members of Team2 it will be
the opposite way around.
If a DB is included from another project then it is always read only regardless of team
membership.
These concepts are discussed in detail in the Administrator User Guide.

1.1.3 Splitting Data Across Multiple DBs

Theoretically there need only be one DB of each DB type. The main reasons for there being
more are:
• DBs are used as a fundamental means of access control. DBs are allocated to Teams,
and only team members can modify a DB.
• Whilst the multiwrite facilities allow many writers per DB, it eases contention if the
writers are not all accessing the same DB.
• The easiest way to run a Global project is to have different DBs writable at different
locations.
• The granularity of propagation and distribution in Global is per DB
• It allows different permutations of MDBs.
• It allows specific DBs to be hidden from sub contractors
• Inclusion in other projects is done on a DB basis.

1.2 Database Elements

All data in a Dabacon database is stored in elements. Every element has a type, e.g. BOX.
The type of element determines the attributes available on the element.
Each DB type allows a different set of element types.
Database attributes are described in Database Attributes
The elements are organised in a primary hierarchy. This is described in Database hierarchy.

1.2.1 Reference Number

Every element has a reference number, which is assigned when the element is created, and
is unique to that element within the project. The reference number comprises two 32 bit
integers. This is displayed in the form:
=1234/6789
The first integer is composed from the database number and a bucket number. The bucket
number allows for multiple users to access a database simultaneously without the risk of
generating the same reference number; bucket numbers are allocated to users on a
temporary bases starting at 1. In single write databases, the bucket number is always 1.
The second integer is a sequence number, starting at 0, and incrementing each time an
element is created within that database and bucket.
The algorithm for allocating a reference number is:
1st part - DB number plus (bucket number * 8192)
2nd part - Increment starting from 0.

© Copyright 1974 to current year. 1:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

Thus, for example, for DB 1, the first element created will have a reference number of
=8193/0 (this will be the world element since this is always created first).
The reference number is never changed once an element has been created.

1.2.2 Name
In Outfitting any element may be given a name. The name always starts with a '/'. At the
user level, it is this name that is typically used to identify an element. Names may of course
be changed, thus there is no guarantee that the element named '/FRED' today is the same
as the element named '/FRED' yesterday.
An element need not have a name. For these elements Outfitting creates a constructed
name, consisting of the relative position in the hierarchy up to the first named element.
e.g. BOX 2 OF SUBEQUIPMENT 1 OF /VESS1
Whilst the constructed name can be used to identify elements, its use is even more volatile
than named elements, since the order of an element in a member's list may change.
The user can duplicate the name of an element in a Design (DESI), Production (MANU),
Schematic (SCHE) or Engineering (ENGI) databases in the current MDB. For example an
element can be named `/FRED´ in the DESI database and a different element can be
named ´/FRED´ in the MANU database.

1.2.3 Current Element

At the user level there is a concept of current element.
Most Outfitting commands act on the current element. This is often referred to as the CE.
There is an extensive set of commands to navigate around the database changing the CE.

1.2.4 Change Element Types

For most elements, the element type may never be changed after creation. For example,
once created, an element of type SITE will always be of type SITE until deleted.
There are a few exceptions to this rule where it makes sense. For example, BENDs may be
changed to ELBOs and vice versa.

1.3 Primary Database Hierarchy

1.3.1 Hierarchical Data Model

Each database consists of a hierarchy of elements. The allowed hierarchy is defined in a
Database Schema. The database schema is the 'meta data', i.e. it is data about data.
Database Schemas cannot be modified by users. The Database Schema for each database
type is listed in the data model reference manual. An example of part of the Database
Schema for DESIGN databases is shown below:

© Copyright 1974 to current year. 1:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

This schema shows which elements are allowed where. For example, a WORLD may own a
SITE, or GROUPWORLD, whereas a SITE may own a ZONE, BOUNDARY, DRAWING or
GROUND model.
The same element type may occur in more than one place in the schema. In the above
example it can be seen that a BOUNDARY element may occur below a SITE or a ZONE.
All database schemas have a WORLD element at the root.

1.3.2 User Defined Hierarchies

The database schemas in Outfitting are fixed by AVEVA.
Users may, however, customise the allowed hierarchy using UDETS. (User Defined
Element Types).
A UDET must be based on an existing system type. For example, a user may define a
UDET :PUMP which is based on an EQUIPMENT. By default, a UDET will have the same
allowed members and allowed owners as a base type. This can be customised to be a
subset of that allowed on the base type, e.g. you might decide that SUBE are not allowed
under a :PUMP even though they are allowed under an EQUI.
UDETs based on zones may own other UDETs based on zones. This allows very flexible
data models to be built.

1.3.3 Element Instances

A new database starts with a single world element with name '/*'. Users will then create
instances of other element types. For example, a system user might create an initial
hierarchy of sites and zones in a DESIGN DB, leaving it to other users to create the actual
Ship items.
An element instance will always be created within the primary hierarchy. For example, a
new ZONE element must be created under an existing SITE. It cannot be created as a
'freestanding' element outside the existing hierarchy.

© Copyright 1974 to current year. 1:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

The actual element hierarchy can be viewed with the Outfitting explorer.
All element instances within an MDB are accessible at all times.

1.3.4 Where the Primary Hierarchy is Used

The primary hierarchy is used as follows:
• It is used to create the 'constructed' name for unnamed elements.
• When an element is deleted, all descendants in the primary hierarchy are deleted.
• The COPY command will copy an element and all its primary descendants.
• Claiming elements relies on the primary hierarchy.
• Collections work on the primary hierarchy.
• Most commands assume that the action is to be performed on the given element and
its descendants in its primary hierarchy, e.g. adding a ZONE to a 3D view will add
everything below that ZONE.
• In the DESIGN DB, world positions and orientations are concatenated according to the
primary hierarchy.

1.4 Secondary Hierarchies

An element can only exist once in the primary data hierarchy. Secondary hierarchies, such
as GPSETs, allow elements to appear more than once in the overall hierarchy. For example
a PIPE will appear below a ZONE in the primary hierarchy. The same PIPE may also be
added to a GPSET element. This is useful for collecting elements according to different
criteria.
The diagram below shows a typical multi hierarchy where the secondary links are dotted.

Most commands will work on secondary hierarchies. For example, if /GPSET1 is added to a
3D view then this is equivalent to adding both /VESS1 and /PUMP2 to the 3D view.
However, there are exceptions to this. In particular deleting a GROUP will not delete the
GROUP members; thus deleting /GPSET1 will not delete /VESS1 and /PUMP2.
Unlike the Primary hierarchy, secondary hierarchies may span different DBs.

© Copyright 1974 to current year. 1:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

1.5 Database Attributes

Every element may have a number of attributes. All elements have the following attributes:

NAME the element's name

TYPE the element's type
LOCK if set, then the element may not be modified
OWNER the element's owner
MEMBERS the current members of the element

The remaining attributes vary depending on the element type. The Database Schema
defines which attributes are available on an element type. The allowed attributes for an
element type may be ascertained using PML objects and other command queries.
Attributes may be one of the following types:
Integer Ref
Integer Array Ref Array
Real Position
Real Array Direction
Bool (or Logical) Orientation
Bool (or Logical) Array Attribute
String (or Text) ElementType (or Noun)
Datetime

A 'Ref' type is a pointer to another element. For example, on a BRANCH element the CREF
attribute points to the connected NOZZLE. The use of Ref attributes enables Outfitting to
model networks and other cross relationships.
The attribute type dictates how the attribute can be set with PML or specific syntax.

1.5.1 User Defined Attributes

Users can extend the allowed attributes for any element type, including a UDET, by defining
UDAs (user defined attributes). For example, a user could define a UDA called :SUPPLIER
of type string on all piping components. The newly defined UDA will then exist on all
applicable elements, existing and new. If the definition of a UDA is changed then this will
also apply to all existing instances.
Having defined a UDA, it is accessed in the same way as any other attribute.

1.5.2 Pseudo Attributes

In addition to the attributes stored on the database, there are a large number of pseudo
attributes. The value of pseudo attributes is calculated at the time of making the query.
For example, the CUTLENGTH attribute on SCTN elements is a pseudo attribute calculated
at the point of doing the query.
There is a lot of functionality presented via pseudo attributes. Currently there are over 1200
pseudo attributes.

© Copyright 1974 to current year. 1:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

Since the value of a pseudo attribute is calculated from other attributes, it is not generally
possible to set their value directly.

1.5.3 Global Namespace for Attribute and Element Type Names

Attributes and element types have a global name space. This means that an attribute such
as XLEN will have an identical meaning wherever it exists.
Similarly if an element type is valid in more than one database type, the definition of the
element type will be identical in each.

1.5.4 Attributes of Physical Quantities

Some real attributes are simply numbers, counts, quantities etc. Others represent real
physical quantities such as distances, areas, densities, angles etc. The type of physical
quantity is called its physical dimension, often shortened in unambiguous contexts to its
dimension. Real attributes (stored, derived, user defined etc.) can all be assigned a physical
dimension and this determines the type of data stored in these attributes wherever and
whenever they occur in the database. The most common dimensions of attributes are of
length (internally set to either DIST or BORE). There are many others supported including
density, mass, pressure, temperature, area, volume and angle.
The dimension of an attribute is held in the database in its (ambiguously named) UNIT field.
It may be queried directly using the VAR ATTDEF attributeName UNIT syntax, and the
!attribute.units() PML ATTRIBUTE object method, refer to PML ElementType Class.

1.6 Database Expressions and Rules

1.6.1 Expressions
Database expressions can be of the following types:
• algebraic
• boolean (or logical)
• text
• Element ID
• position
• direction
• orientation
The contents of an expression may contain the standard operator and mathematical
functions along with the names of attributes and element identification.
Examples of expressions are:
Real Expression: (XLEN * YLEN * ZLEN * 2)
This expression simply multiplies the three attributes XLEN, YLEN, ZLEN together and then
multiplies by two.
The attributes refer to the current element. If attributes of other elements are required then
the OF syntax is used.
Boolean expression: (PURP EQ 'HS' AND AREA OF OWNER EQ 1)

© Copyright 1974 to current year. 1:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

The 'OF' keyword ensures that the AREA attribute is obtained from the owner of the current
element rather than the current element itself.
The main uses of expressions are:
• Catalogue parameterisation
• Template parameterisation
• Rules
• Drafting line styles
• User level collections and report
Database expressions are very similar to PML expressions. The major difference is that
database expressions may not contain other PML variables or functions. E.g. (XLEN *
!MYVAR) is not a valid database expression.

1.6.2 Rules
An attribute may be defined as a rule. For example, the attribute XLEN may be defined as a
rule by the expression (YLEN * 2).
The OF syntax is often used in Rule expressions to refer to other elements, e.g. (YLEN OF /
FRED * 2)
The result of the rule is stored against the attribute as for other attributes.
There are commands to recalculate the rule.
Rules may be either static or dynamic. If static, then the rule result will only be recalculated
on demand. If dynamic, then the result will be recalculated every time an attribute within the
expression changes, e.g. for the above rule, if YLEN is modified, then XLEN will be
recalculated automatically. The dynamic linkage of rules may be across elements and
across DBs.

1.7 Dumping out the Database

1.7.1 Data Listings

Data listings (DATALs) capture the state of the database in the form of Outfitting commands.
All element data including all attributes, UDAs and rules will be captured. They are similar in
concept to XML output. These files can then be read back in via the command line.
Data listings are used as follows:
• Long term archiving
• Copying parts of a DB between projects
• For general information.

1.7.2 Reconfigurer
Reconfigurer is similar to Datal in that it dumps out the state of the data.
The data can be dumped to either binary or text file. Using binary files is quickest.
Reconfigurer is faster than Datal and is recommended if whole DBs or world level elements
are to be transferred. Datal or the copy facilities is recommended if lower level elements are
to be transferred.

© Copyright 1974 to current year. 1:9 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

1.8 Database Modifications

The fundamental modifications allowed are:
Element creation
Element deletion
Element copy
Element move
Attribute modification

1.9 Data Access Control (DACs)

Data Access Control (DAC) is the mechanism that protects information handled by the
system from accidental or unauthorised manipulation.
For a more detailed description of the basic functionality and administration of DAC refer to
the Administrator User Guide.
The basic access control available is known as 'Team Owning Databases'. It implements
access control on database level by simply giving the members of the team owning the
database full access and others read-only to data held in particular databases.
A more sophisticated access control is implemented in the form of Access Control Rights
(ACRs). ACR allows the administrator of the system to apply a more fine grained access
control over the model. The following figure illustrates the DAC database hierarchy.

An ACR is defined through two entities:

• A ROLE, which is a collection of rules called Permissible Operations (PEROPs).
• A SCOPE, which defines to what part of the model the ROLE applies. The SCOPE may
be an expression, e.g. all ZONE WHERE (FUNC eq 'TEAMA')
A PEROP defines the access rights given for a number of pre-defined operations for one or
more elements.
One or more ACRs may be assigned to a user granting and denying access to the model.
For a user to gain update access to a particular element two rules apply:
• At least one PEROP in a ROLE assigned to a USER must grant the update operation.

© Copyright 1974 to current year. 1:10 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

• No one PEROP must explicitly deny the operation.

Management tools are available for DAC through the ADMIN module. Control of DAC is also
available through PML.
A PEROP consists of three parts:
• The Element it applies to
• The operations which can be performed on those elements
• Optionally the Attributes that may be modified.
The PEROP may further restrict the elements it applies to by a qualifying condition. The
qualifying conditions is an Outfitting statement that should evaluate to true to qualify the
PEROP.
The following operations are available through PEROPs
Create
Modify
Delete
Claim
Issue
Drop
Output
Export
Copy
Each of these operations may be set to

Allow The operation is permitted

Disallow The operation is not permitted

Ignore The PEROP does not define whether this operation is permitted or not

Optionally the PEROP may further restrict which attributes it allows modification to by
specifying a list of attributes that it either includes or excludes from allowing modification to.
The PEROP also holds the message that the system will issue if the PEROP denies
attempted operation.

1.9.1 Errors Applicable to all Modifications

The following checks are applied to all modifications:
• Check access control
• Check that the DB is open in write
• Check that the element's LOCK flag is false
• If a multiwrite DB then do a claim check, and claim if needed
The claiming process is described in Claiming Elements

1.9.2 Integrity of Modifications

The engineering integrity is always maintained for any database modification.
The integrity checks are applied below the database interface. Thus modifying the database
is always safe whether done via PML commands or C#.

© Copyright 1974 to current year. 1:11 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

The checks are applied to individual attributes and element types. For example the OBST
attribute can only ever be set to 0,1 or 2. Outfitting will always check that this is the case
prior to allowing the modification.

1.9.3 Element Creation

Elements may be created. They are always created one at a time, and may only be created
at a legitimate point in the primary hierarchy.
On creation, a unique reference number will be assigned. The method by which the default
reference number is generated is described in User Defined Hierarchies.
It is possible to create an element with a specified reference number, provided it is unused
and valid for the DB. This functionality is provided for certain specialised situations (such as
recreating an exact copy of a DB, so that all references to elements from other DBs remain
valid), and is not recommended for general use.
The attributes will be set to their default values. In some cases the default attribute values
are cascaded down from the owning element.

1.9.4 Element Deletion

Elements may be deleted. All elements below the deleted element in the primary hierarchy
will also be deleted.
Reference numbers of deleted elements are never reused.

1.9.5 Element Copy

Elements may be copied. There are options to copy a single element or an element and all
its descendants. Elements may be copied between DBs. Any cross references entirely
within the copied structure will be updated to point to the newly created elements.
Elements are always copied on top of an existing element of the same type.
There are various options on the copy command to allow:
• The copied elements to be renamed according to a given criteria
• Whether any attribute rules are to be rerun on the copied element. (Rules are
described in Reconfigurer)
Additional potential errors at create are:
• The element may not be copied to an element of a different type

1.9.6 Element Move

Elements may be moved to a different point in the DB or to a different DB.
The Element and all its descendants will be moved.
If the element is moved to a different DB, then its reference number is changed. All
reference attributes pointing to the moved structure will be updated.
Additional potential errors at move are:
• The element is not allowed in the members list of the new owner

1.9.7 Attribute Modification

The following checks are applied when modifying attributes:

© Copyright 1974 to current year. 1:12 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

1. the attribute value is the right type

2. the attribute is valid for the given element

Modify Related Attributes

Sometimes modifying one attribute will actually cause a number of attributes to change.
There are two main cases where this might happen:
1. There is a dynamic rule on another element dependent on this element (see section
Rules for description of rules)
2. There is built in code that keeps a number of attributes synchronised. This is used for
some Draft attributes and some cross references.

Change Cross Referenced Attributes

The integrity of cross referenced attributes is maintained when one end of the connection is
changed. Changing one end of a connection will also change the following:
1. If there is an existing connection, the corresponding attribute on the element at the
other end of the existing connection, is unset.
2. For the new element connected, if this is already connected, then this connection is
unset, which itself may change the element at the other end.
In essence, changing one value may result in four elements being updated.
For example, consider the following:

After setting the CREF on /N1 to /B1, the end result is:

© Copyright 1974 to current year. 1:13 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

1.9.8 Effect of Modifications on Dynamic Rules

A dynamic rule will automatically respond to changes which affect the attributes referred to
in the rule.
For example, we set a rule on YLEN of /MYBOX to be (YLEN OF /FRED * 2). Thus if YLEN
on /FRED changes then YLEN on /MYBOX will be updated automatically. However there
are reasons why the automatic propagation of dynamic rules may fail, as follows:
1. The elements are in different DBs and the DB containing /MYBOX is not in the MDB
2. The elements are in different DBs and the DB containing /MYBOX is read only
3. It is not possible to claim /MYBOX
4. /MYBOX is locked
5. There is a DAC preventing the change
Note also that only static rules are not automatically updated. For these reasons there are
commands to verify that rule results are up to date.

1.10 Database Sessions

1.10.1 Savework/Getwork
Data is only saved to the database on demand. Similarly a user will only see changes made
by others on demand. In order to make changes visible to other users two steps must occur:
1. The user making the changes must do a Savework
2. The reader must do a Getwork
For most applications, the savework/getwork actions are totally in the hands of the user.

1.10.2 Sessions
When a savework is made a new session will be created on the database. The changed
data will always be written to the end of the file. This represents the 'delta' from the previous
session. Details such as date, user, session description are stored as part of the session
data. There is always a pointer from the database header to the last session on the
database.

Internally there is a linked list between sessions. It is worth reiterating that once a session is
written, it will never be changed. Thus if a user is looking at session 19, then his view of the
data will never change in any way regardless of any sessions created by other users. If the

© Copyright 1974 to current year. 1:14 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

user does want to see the changes made by others then he must do a 'Getwork'. 'Getwork'
will always reposition the user to view the latest session. Thus in the above example if a
user originally looking at session 19 did a Getwork then he would now be looking at session
39.

1.10.3 Session History

The Database will preserve the full session history. Thus at any point it is possible to find out
what was changed when and by whom. The system can report on changes down to the
attribute level.
The list of facilities include:
• Comparing elements to an old session
• Dataling out changes since a given session
• Setting a comparison session
• Creating a stamp
• Various pseudo attributes

Comparing Elements to an Old Session

The DIFF command can be used to report on changes. For example, if the user were to
modify a couple of attributes on an equipment, and add a new primitive, then the DIFF
command could be used to report on the changes. The output from the command might be:
Local comparison for Database items:-
/VESS1
/VESS1 [=15752/201] has been modified
Member list has changed
List member /EXTRACYL created
Description has changed
Old value= my description
New value= my new description
Area has changed
Old value= 999
New value= 100
/EXTRACYL [=15752/1326] has been created
2 changed elements found
By default, the DIFF command will report the changes made by the user in the current
working session, that is to say, since the last savework. It is also possible to specify a given
session number, a date and time, or a stamp (see Create a Stamp) in order to see the
differences since then.

© Copyright 1974 to current year. 1:15 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

Dataling out Changes Since a Given Session

The OUTPUT command may be used to record changes since a given session. The Datal
file will then contain the commands that reproduce the updates made since the given
session. The file can then be read back in to reproduce the changes. This is convenient
where bits of data have been copied between projects, and the copied data needs to be
updated with changes made to the original.
Reverse changes can also be output. The Datal file will then contain the commands that
remove the updates made since the given session. This is a convenient way for restoring
part of a model back to how it was at an earlier point.

1.10.4 Create a Stamp

It is often convenient to mark a set of DBs at particular milestones in the project. The 'Stamp'
functionality allows this. It is then straight forward to find out what has changed since the
stamp, or to view the data as it was at that time.
Stamps can only be created within ADMIN.

1.10.5 Set a Comparison Date

Within Outfitting a comparison date can be set. A convenient way of doing this is to use a
stamp. However the comparison date may also be set to an explicit session on a particular
extract. If the comparison session is on a different extract then the extract must be an
ascendant of the current extract.
Any query may then be done at the old session using the 'OLD' keyword. e.g.
Q OLD XLEN
This would return the value of XLEN at the comparison session.

Pseudo Attributes for Comparisons

There are a number of pseudo attributes that can be used to do comparisons. These are
listed in the database reference manual.

1.10.6 Merge Changes

As a result of storing all changes, Outfitting databases will grow relatively quickly. The user
may compress a DB to reduce its size by merging multiple sessions together using the
MERGE CHANGES command in ADMIN. The user may compress all sessions, or a range
of sessions.
Any sessions used in stamps will always be preserved. Thus before compressing a DB the
user should create stamps to preserve any comparison points that might be needed.
Sessions 1,2 and the last session are also always preserved. Thus for the previous
example, if the user decides to do a MERGE CHANGES on a database having set a stamp
on session 10, the resultant DB will look like:

© Copyright 1974 to current year. 1:16 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

It can be seen that as well as sessions 10, sessions 1,2 and 39 are kept. The changes in
session 10 now hold the accumulated changes for sessions 3-10, and Session 39 actually
holds the accumulated changes for sessions 11 to 39.
The MERGE CHANGES command is discussed in the ADMIN manual.

1.11 Multiwrite Working

Dabacon DBs may be either 'UPDATE' or 'MULTIWRITE.
UPDATE DBs allow only one user to have write access at any given time, although multiple
users may still have simultaneous read access.
MULTIWRITE DBs allow multiple simultaneous users with write and read access.

1.11.1 Multiwrite Strategy

The Database employs two techniques to allow multiple writers.
A claiming mechanism - User must claim an element at the point of making a modification.
This will lock the element preventing other users making modifications.
A Last Back Wins strategy- For some changes a 'last back win' strategy is used rather than
claim locks. With this strategy two users may change the same element. Any changes are
merged back in. The merging is done at the attribute level. If two users change the same
attribute then the last save wins. Places where this strategy is used are:
• Some connection attributes. e.g changing a TREF attribute on a branch does not
require the BRANCH to be claimed.
• Member lists containing primary elements are always merged back. e.g. creating a
ZONE below a SITE doe NOT require the SITE to be claimed,
• Changes issued from variant extracts are always merged back in.
• Dynamic rule linkage
• Spatial map values

1.11.2 Claim Elements

The level of claiming is at the 'primary' element level. Examples of primary element types
are SITE, ZONE, EQUI, SUBE. Examples of non primary elements are primitives such as
BOX. When you need to modify a non primary element then the first primary element up the
hierarchy must be claimed out. E.g. to modify a BOX, then the owning EQUI or SUBE must
be claimed.
When working on multiwrite DBs, users may either explicitly claim elements to work on, or
let the system implicitly claim elements for them. The implicit claim will occur at the point of
making a modification.
There are a number of reasons why an element may not be claimed:

© Copyright 1974 to current year. 1:17 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

1. The element is claimed by another user

2. The element is claimed by an extract
3. The element has been changed since this user last did a GETWORK or SAVEWORK.
To remedy this, the user must do a GETWORK first.
If a list of elements is claimed, and some in the list fail, then the remaining elements will still
be claimed.

1.11.3 Release Elements

Having claimed an element, a user may release it, thus allowing others to change it.
An element may not be released if changes are outstanding. The user must do a
SAVEWORK first.
On leaving a module all elements will be released for that user.
If a list of elements is released, and some in the list fail, then the remaining elements will still
be released.

1.11.4 Performance Considerations

Every time a claim/release is made the underlying DB is accessed. To minimise such
access, as many elements as possible should be done in one go.

1.11.5 Potential Conflicts at SAVEWORK/GETWORK in a Multiwrite

Environment
There are a number of potential problems which are not discovered until SAVEWORK or
GETWORK.
1. Two users could simultaneously use the same name for an element. This may not be
discovered until the second user attempts to do a SAVEWORK or a GETWORK. In this
case the second user must rename the offending element before SAVEWORK or
GETWORK is allowed.
2. One user may insert a primary element in another element's list, say /PIPE1, whilst a
second user deletes /PIPE1. Again SAVEWORK or GETWORK will throw an error, and
the user will have to move or delete the offending branch in order for SAVEWORK or
GETWORK to take place.
3. The opposite of (ii) can also occur. i.e. you have deleted a primary element in which
another user has created an item. In this case the user must QUIT the changes.
If any error occurs at SAVEWORK or GETWORK then the entire operation is aborted.

1.12 Extracts
Extracts are an extension of the multiwrite facilities.
The extra functionality offered by extracts is:
• They allow long term claims, i.e. Elements are not released on module switch.
• The issuing of data is separated from SAVEWORK.
• A partial set of changes may be issued, rather than the whole lot.
• A partial set of changes may be dropped, hence losing the changes.
• Allows variants to be tried and maintained.

© Copyright 1974 to current year. 1:18 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

• Allows a 'last back wins' when issuing from variants

• Users may have their own private work space.
• Users can use extracts to implement an approval/work cycle, i.e. the issuing of data
from one extract to another could correspond to given criteria being met. Other users
could then read the approved data rather than the working data.

1.12.1 Create Extracts

Extracts are created from existing multiwrite DBs. The existing DB then becomes the Master
DB. Many extracts may be created off the same Master DBs. Extracts may also be created
from other extracts. The term extract family is used to refer to all extracts created directly or
indirectly off a Master DB. Example of an extract family:

In this extract family, three extracts were created below the Master DB. Two further extracts
were then created below Extract1.
There may be up to 8000 extracts in an extract family.
Extracts may be included in an MDB as for any other DB. Two extracts from the same
extract family cannot be included in the same MDB.

1.12.2 Restrictions on Extracts

It is not be possible to:
• COPY an extract
• INCLUDE an extract from a foreign project without its parent extract being included
first.
• EXCLUDE an extract/DB unless all child extracts have been excluded.

1.12.3 Extract Sessions

An extract will have its own set of sessions. This is illustrated below:

© Copyright 1974 to current year. 1:19 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

In this example the extract DB was created when the Master DB had 19 sessions. The
extract thus represents a branching of the model from session 19. Changes were then made
to the Master and to the Extract. The Extract has had nine more sessions created (sessions
2-10). The Master has had 20 more sessions added (sessions 20 - 39).
Changes made to an extract can be flushed back to the Master DB. Similarly the extract
may be refreshed with changes made to the Master.

1.12.4 MERGE CHANGES on Extracts

When a 'MERGE CHANGE' operation is performed 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 opposite is not needed, i.e. MERGE
CHANGES on a child does not require the parent extract to be merged.
The following restrictions apply to MERGE CHANGES:
1. Any sessions 'linked' to child extracts are preserved.
2. There may be no users on any lower extracts.
To minimise the sessions preserved in (1) it is suggested that a bottom up approach is
followed when doing 'MERGE CHANGES'.

1.12.5 Extract Claims/Releases

In order to modify an element in an extract, the element must be claimed to the extract. The
principals of extract claiming are exactly the same as standard claiming, i.e, the granularity
of extract claims is at the level of primary elements.
Extract claims will work up through the extract levels, extract claiming as necessary, i.e, the
user need not do a separate claim for each level of extract.
For example, consider a three level extract as follows:

© Copyright 1974 to current year. 1:20 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

If a user does an extract claim to the Working Extract the following logic will be used:

Is element claimed out to WORKING already?

-if YES

do nothing

-if NO

Is element claimed to APPROVED extract?

-if NO

Claim from ASBUILT to APPROVED

Then claim from APPROVED to WORKING

-if YES-

Claim from APPROVED to WORKING

The extract claim may fail for the same reasons that a user claim may fail, i.e.:
• Another user/extract has the item claimed
• The element is modified in a later version, hence a refresh is needed first.
Unlike user claims, extract claims stay with the extract across SAVEWORKs.
If a list of elements is extract claimed, and some in the list fail, then the remaining elements
will still be extract claimed.

1.12.6 Extract Release

Extract claims may be released in the same way as user claims.
An extract release will not be permitted if:
1. Updates are outstanding on that extract
2. The element is currently claimed out to a user or to a lower level extract
If a list of elements is extract released, and some in the list fail, then the remaining elements
will still be extract released.

1.12.7 User Claims/Releases on an Extract

An extract is itself a multiuser DB, thus more than one user may work on an extract.
Standard user claims and releases are thus also applicable to extracts

© Copyright 1974 to current year. 1:21 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

1.12.8 Variants
Variants are like standard extracts except that there is no extract claiming of elements
between the variant and its parent extract. Any elements may thus be modified. This has the
advantage that many users can potentially change the same element at the same time in a
different variant. The disadvantage is that conflicts are not discovered until the time of flush.
There are no restrictions on where variants are located in the extract tree, e.g. variants may
own other normal extracts or other variant extracts. If a variants owns standard extracts,
then the variant acts as a root for subsequent extract claims.

1.12.9 Extract Operations

The following operations are allowed:

Drop This is the process of losing modifications done locally on an extract

combined with the transfer of write extract back to the parent extract.

Partial Drop This is the process of losing modifications done locally on a subset of
elements, combined with the transfer of write extract back to the parent
extract.

Issue The local changes are copied to the parent extract, and the elements
are released.

Flush This term is used for issuing without doing a release.

Partial Issue The Issuing of a subset of the modifications made in the current extract
to the parent extract.

Refresh The mechanism by which an extract is updated with changes made in

the parent DB.

The refresh functionality is needed since users work on a constant view of the parent extract
DB. Thus they will not see other users' issues until they do a REFRESH. It is akin to the
GETWORK functionality in a single multiwrite DB.
All flushing, issuing, releasing and dropping operations work on one level of extract only. A
Refresh can be done all the way up the tree using just one command.
If an extract operation fails, then the entire operation is aborted.

1.12.10 Merge Algorithm

On issue or flush, changes made in an extract will be merged back to the parent extract.
The basic approach is that any changes made to the extract are applied to the parent
extract, as shown below:

© Copyright 1974 to current year. 1:22 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

The granularity of this merge is at the attribute level, i.e. two users can change different
attributes on the same element and merge their changes together. If they modify the same
attribute then a 'last back win' strategy is used.
Outfitting ensures that all merges are valid at the raw database level, i.e. the data will be
DICE (Database Integrity Checker) clean. However it is not possible to ensure that the data
is consistent in engineering terms. Thus it is highly recommended that when variant data is
flushed back, Datacon checks and Clasher checks are run on the resulting version.
The definition of the different sessions for issue and flush are:

Base Session Session on parent when Refresh was last done

From Session From session on child extract

To Session New session on parent

The definition of the different sessions for refresh are:

Base Session Session on parent when Refresh was last done

From Session From session on child extract

To Session New session on parent

The definition of the different sessions for drop are:

Base Session Session on parent when Refresh was last done

From Session From session on child extract

To Session New session on child

Note: The standard flush and issue commands also do a refresh. This ensures that there is
a suitable base session for the next extract operation.

The drop command compares the elements that are NOT to be dropped and applies the
changes to create a new session.
The same algorithm is used for SAVEWORK and GETWORK.
There are two exceptions to the merge criteria as follows:

© Copyright 1974 to current year. 1:23 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

1. Once an element is deleted, then it stays deleted regardless of any conflicts in merging.
For example, user 1 deletes /BOX, whereas user 2 changes an attribute of /BOX. If
user 1 issues his change before user 2, then user 2's change will have no affect.
2. If the element type is changed, then the merge is done at the element level rather than
the attribute level, i.e. all the current attribute values are taken regardless of whether
they have changed. Any attribute changes made by other users will thus be lost.

1.12.11 Dealing with Deleted Elements

There are three ways of denoting deleted items for a partial operation.
1. The reference number of the deleted item can be specified. The reference number can
be obtained by opening an MDB which includes the parent extract and navigating to
that element, and then querying ('QUERY REFNO')
2. If the 'HIERARCHY' keyword is used, then any deleted items within that hierarchy will
be included.
3. For primary elements, if the name of the deleted element has been reused, then
flushing the element with the new name will flush the deleted element. For example, if
the user deletes PIPE /PIPE1 and then recreates it, then flushing /PIPE1 will also flush
the deleted pipe.

1.12.12 Flushing Connected Items

For two way connections, it is often desirable to flush both ends of the connection in order to
preserve engineering consistency. There are addition options that allow the connected
items to be flushed.

1.12.13 Errors for Extract Operations

Potential problems at issue and refresh are the same as for SAVEWORK and GETWORK
on multiwrite DBs, i.e. there could be a name clash, or an owning element could be deleted.
Such problems will need to resolved in the extract prior to issuing being allowed.
If doing a partial issue or flush or if issuing from an extract, then extra checks are applied 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.
• 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:
1. if it is included in a partial flushback, then so must its owner.
2. if the owner is include in a partial drop, then so must the element itself
• if an element and its owner have been deleted then:
1. if it is included in a partial drop, then so must it's owner.
2. if the owner is included in a partial flush, then so must it.
Where an element has not been claimed, then Drop can still be used to lose the local
changes.

Note: When a partial issue or drop is made there is no guarantee that the data is
'Engineering correct'. Users are advised to run Clasher and/or Datacon on the
resultant version.

© Copyright 1974 to current year. 1:24 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

1.12.14 Performance Considerations

A new session is created for every flush operation. Thus it is much better to flush a large
number of elements in one go rather than flush them individually.

1.13 Global Working

Global allows DBs to be spread across different locations. Global propagates changes from
one location to another. The Global daemon does the propagation.
With global, there may be copies of a database or extract at multiple locations, but only one
copy may be writeable. A database is said to be primary at a given location if it is writeable
there, and secondary if it is not. A DB may be made primary at any location.
Different extracts from the same extract family may be primary at different locations. This
allows multiple different locations to modify the same DB.

1.13.1 Global Propagation

Changes made to a primary DB are propagated to the read only secondary DBs. The
propagation algorithm just sends the new sessions. For example:

If this case the propagation algorithm will send the sessions 20 to 39 to the secondary
location.

1.13.2 Extract Claim/Release with Global

If the two extracts are primary at the same location, then the extract claim/release
operations are the same as for non global projects. If the two extracts are primary at
different locations then the claim/release goes via the daemon. For example:

© Copyright 1974 to current year. 1:25 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

The extract claim operation is thus asynchronous. The user has to wait to discover if the
claim succeeded or not.

1.13.3 Flush with Global

If the two extracts are primary at the same location, then the flush operation is the same as
for non global projects. If the two extracts are primary at different locations then the steps
are as follows:

The steps are:

1. Propagate sessions on the child from location B to location A
2. Flush the Master at location A with changes
3. Propagate the new sessions on the Master at location A to location B (at next update)

© Copyright 1974 to current year. 1:26 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

Step 2 could fail for normal reasons, e.g. a name clash. If so the primary child extract needs
to be informed so that next time it uses the correct base session for comparison purposes.
At the command level this is the 'EXTRACT FLUSH RESET' command.

1.13.4 Merge Changes for Global Extracts

In the Global environment MERGE CHANGES will only be allowed where all lower extracts
are also primary on this location.

1.14 Undo Capabilities

1.14.1 Undo/Redo within a Session

The Outfitting database has a built in undo/redo capability. Applications may define a start/
end transaction and wind back to the start of that transaction.
Internally this is implemented using 'micro' sessions. Each micro session represents the
start of each transaction.
An undo can not be done across a SAVEWORK.

1.14.2 Backtrack/Rewind
The system administrator may remove the last one or many sessions from the DB.

© Copyright 1974 to current year. 1:27 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Introduction to Database Concepts

© Copyright 1974 to current year. 1:28 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Navigation and Query Syntax

2 Database Navigation and Query Syntax

This section covers aspects of database navigation. Many examples are given during a
DESIGN session but are also relevant to the Outfitting Draft module.

2.1 Current Element

The database has a concept of current element. This is often referred to as the CE. The
current element is highlighted in the explorer. In the 3D view the current element is shown in
a different colour.
Many PML commands work on the current element.
The current element can be changed in the following ways:
• By picking an element in the explorer
• By picking an element in the 3D view
• By typing an element name into the name box
• By typing a navigation command at the command line

2.2 Current Position

There is also a concept of a current position. The concept of current position is only used
when creating elements or when navigating down to the next level.
By default the current position is before the first member.
This is described further in Climb Up.

2.3 PML DBRef Object

PML supports a DBREF object. A DBREF object identifies an element in the Outfitting
database. There are various methods available on the DBREF object. The methods for a
DBREF are described in the software customisation manual.

2.4 PML !!CE Variable

There is a global PML DBREF variable called !!CE that tracks the database current element.
This object may be used/queried at any time.

© Copyright 1974 to current year. 2:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Navigation and Query Syntax

2.5 Specify the Standard Name

This is the simplest way of navigating around the database. Just enter the name of the
element at the command line. A name is always preceded by a slash.
e.g.
/PUMP99
/BRANCH2
/BRANCH2 will now be the CE.

2.6 Specify the Constructed Name

Unnamed elements always have a constructed name. The constructed name consists of:
• the type and relative position in its owners list.
• the OF keyword
• the constructed name of its parent
If the constructed name is given, that element will become the CE.
e.g.
BOX 2 OF /PUMP99
NBOX 1 of CYL 2 of EQUI 4 of ZONE 9 of /MYSITE
If the element is a UDET then the UDET name must be used instead of the system type.
e.g. NBOX 1 OF :MYCYL 1 OF :PUMP 3 of ZONE 9 of /MYSITE

2.7 Specify the World

The following syntax accesses the world element by name, type:
/* or WORLD

2.8 Specify the Refno

The reference number can always be used to navigate to an element.
=1234/5678

2.9 Use the BACKREf attribute.

The BACKREf attribute brings the back pointer reference for Reference Table Attributes and
answer the question "what references me (ce)". The syntax is:
Q BACKREF [(ATTNAME att1 [, ATTNAME att2] )]
E.g. standing on a SPCO and querying for BACKREf (attname SPREF ) will return all
elements referencing that SPCO.
Q BACKREF( attname SPCO)
Excluding the argument will list all Reference Table Attributes referencing CE.
E.g. Q BACKREF

© Copyright 1974 to current year. 2:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Navigation and Query Syntax

2.10 Specify a Relative Position in the Hierarchy

Relative navigation can be done using a number of commands as follows:
• Climb up
• Move within current level
• Move to next lower level

2.10.1 Climb Up
The following syntax is valid:

OWNER climb to owning element. The owning element becomes the CE. The
current position is then before the first member

END climbs to owning element. The owning element becomes the CE. The
current position is at the previous element

<Element type> climb to element of that type. This element becomes the new CE. This
leaves the current position at the immediate member element that
was climbed through.

e.g. consider the following hierarchy:

/*
/MYSITE
/MYZONE
/MYEQUI
/MYBOX
If the CE is /MYBOX, then:

OWNER The CE becomes /MYEQUI. The current position is now before the
first member.

END Also climbs to /MYEQUI, but leaves the current position at /MYBOX

EQUI Also climbs to /MYEQUI, and leaves the current position at /MYBOX

SITE Climbs to /MYSITE, and leaves the current position at /MYZONE

2.10.2 Move within the Current Level

Next Goes to next element in at current level

Next int Goes to next nth element at current level
Next <element type> Goes to next element of given type at current level
Next int <element type> Goes to next nth element of given type at current level
Prev Goes to prev element at current level
Prev int Goes to prev nth element at current level
Prev <element type> to previous element of given type at current level
Prev int<element type> to previous nth element of given type at current level

© Copyright 1974 to current year. 2:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Navigation and Query Syntax

First Goes to first element at current level

First int Goes to nth element at current level
First <element type> Go to first element of given type
First int <element type> Go to nth element of given type
Last Go to last element at current level
Last int Go to nth from last element at current level
Last <element type> Go to last element of given type
Last int <element type> Go to nth last element of given type
<element type> int This is the same as ‘First int <element type>’

If a UDET, then the UDET type must be given.

Example
Current list is:
1 BOX /MyBoxA
2 CYL /MyCylA
3 CYL /MyCylB
4 RTOR /MyRtorA
5 CYL /MyCylC
6 BOX /MyBoxB
7 BOX /MyBoxC
8 CYL /MyCylD
9 BOX /MyBoxD
The Current element is /MyCylC, as highlighted.

NEXT Moves CE to /MyBoxB

NEXT 3 Moves CE to /MyCylD
NEXT CYL Moves CE to /MyCylD
NEXT 3 BOX Moves CE to /MyBoxD

PREV Moves CE to /MyRtorA

PREV 2 Moves CE to /MyCylB
PREV BOX Moves CE to /MyBoxA
PREV 2 CYL Moves CE to /MyCylA

FIRST Moves CE to /MyBoxA

FIRST 2 Moves CE to /MyCylA
FIRST CYL Moves CE to /MyCylA
FIRST 3 CYL Moves CE to /MyCylC
BOX 2 This is the same as FIRST 2 BOX. Moves CE to /MyBoxB.

© Copyright 1974 to current year. 2:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Navigation and Query Syntax

LAST Moves CE to /MyBoxD

LAST 2 Moves CE to /MyCylD
LAST CYL Moves CE to /MyCylD
LAST 3 CYL Moves CE to /MyCylB

2.10.3 Move to Next Lower Level

The syntax for moving down a level shares much of the syntax for moving within the level.

Int descend to nth child

First Member Goes to 1st member

Last Member Goes to last member

First <element type>, Goes to first member of given type

FirstMember<element type>

First int <element type> Go to nth element of given type in members list

Last <element type>, Goes to last member of given type

LastMember<element type>

Last int <element type> Go to nth last element of given type in members list

Next <element type> Goes to next element in member list from current position

Next int <element type> Goes to next nth element in member list of given type
from current position

Prev <element type> Goes to next element in member list from current position

Prev int <element type> Goes to previous nth element in member list of given type
from current position

<element type> int descend to nth child of given type

Example
We can use the same example as before but in this case we are positioned at the owning
equipment, say /MYEQUI. The current position is defaulted to the start of the list. The
member list being:
1 BOX /MyBoxA
2 CYL /MyCylA
3 CYL /MyCylB
4 RTOR /MyRtorA
5 CYL /MyCylC
6 BOX /MyBoxB
7 BOX /MyBoxC
8 CYL /MyCylD
9 BOX /MyBoxD

© Copyright 1974 to current year. 2:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Navigation and Query Syntax

5 Moves CE to /MyCylC (5th member)

FIRST MEMBER Moves CE to /MyBoxA
LAST MEMBER Moves CE to /MyBoxD
FIRST CYL Moves CE to /MyCylA
FIRST 3 CYL Moves CE to /MyCylC
LAST CYL Moves CE to /MyCylD
LAST 2 CYL Moves CE to /MyCylC
NEXT CYL Moves CE to /MyCylA (same as FIRST CYL)
NEXT 2 CYL Moves CE to /MyCylB (same as FIRST 2 CYL)
PREV CYL Invalid as there are no cylinders before the current position
BOX 4 Moves CE to /MYBoxD

In the above examples, the use of NEXT had the same result as using FIRST. The use of
PREV was invalid. This is because the current position was off the start. We can change the
current position using the END syntax to give more meaningful examples
e.g.
/MyCylB
END
The CE is /MyEqui as before, but with the current position at /MyCylB

NEXT CYL Moves CE to /MyCylC

NEXT 2 CYL Moves CE to /MyCylD
PREV CYL Moves CE to /MyCylA

© Copyright 1974 to current year. 2:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Navigation and Query Syntax

2.11 Syntax Ambiguity Between Moving Across and Down

In most cases there is no ambiguity with having some of the same syntax for moving down
and moving across. This is because it is rare to have the same element type as a sibling and
a member. However there are some situations where this does occur. In these cases, the
default is to move down rather than across.
e.g.

If the CE is /SUBE1, then

BOX 1 Moves CE to /BoxX (NOT /BoxA)

NEXT BOX Moves CE to /BoxX (NOT /BoxB)

LAST BOX Moves CE to /BoxY (NOT /BoxB)

2.12 Climb up by Default

The commands to move to an element at the same level, may also be used for elements at
any higher level. i.e. if the command is invalid at the CE, Outfitting will keep on climbing until
the command becomes valid.
e.g. for the previous example, with the CE at /BoxY:

SUBE 2 Moves CE to /SUBE2

LAST SUBE Moves CE to /SUBE2

FIRST ZONE Moves CE to /Zone1 (assuming that this is the first zone)

2.13 Use the ‘OF’ Syntax

The commands described so far all work on the CE. It is allow able to do a navigation
relative to any element by using the ‘OF’ syntax.

© Copyright 1974 to current year. 2:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Navigation and Query Syntax

e.g. FIRST MEMBER OF /ZONE1

The ‘constructed’ name is actually an example of the use of the ‘OF’ syntax.
The ‘OF’ syntax can be nested as much as required.
e.g. FIRST MEMBER OF FIRST BOX OF NEXT EQUI

2.14 Other Syntax

2.14.1 Use the GOTO Syntax

The GOTO command can be used to go to any reference attribute. E.g.
GOTO CREF This will go to the element pointed to by the CREF of the CE.
As with other navigation commands, the ‘OF’ syntax may be used to go to reference on a
different element.
e.g GOTO HREF OF /BRANCH88
Pseudo attributes can be specified after GOTO. A particularly useful pseudo attribute is
FRSTW. This goes to first world of a given type.
e.g. GOTO FRSTW CATA
This will go to the first catalogue world.

2.14.2 Return to the Previous Current Element

The SAME command will always return to the previous current element.
e.g.
/VESS1
/SECTION99
SAME
The current element will now be /VESS1.

2.15 ID Expressions
The above commands are all examples of an ID (identification) expression. The one
exception is the ‘GOTO’ syntax. This keyword is omitted within an ID expression. ID
expressions should be enclosed in brackets, although in most cases, they will work without
the brackets. An ID expression may itself be queried or assigned to a PML variable.
Querying an expression or assigning it to a PML variable dos NOT change the CE.
Q ( NEXT BOX)
!MyEle = ( next box )
!MyEle = ( next box of /VESS1 )
!MyEle = (SPRE )
Assigning an ID expression to a PML variable is a common way to write PML.

© Copyright 1974 to current year. 2:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Navigation and Query Syntax

2.16 Special Cases

2.16.1 UDETs
A UDET may be used wherever an element type is valid.
e.g.
(:MYBOX 1 OF /VESS1 )
NEXT :MYBOX
FIRST 2 :MYBOX
The following exception applies:
• When climbing, either the UDET or the base type may be specified.
e.g.
At a BOX below /VESSEL which is a :MYEQUIP
:MYEQUIP - will climb to /VESSEL
EQUIP - will also climb to /VESSEL

2.16.2 Trace Command

If in TTY mode, the TRACE ON/OFF command can be turned on track changes in current
element. The default is on.

© Copyright 1974 to current year. 2:9 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Navigation and Query Syntax

2.17 Pseudo Attributes Relating to Navigation

The following pseudo attributes relate to the database hierarchy. These can be queried
directly or via a PML variable.

Attribute Name Data Type Qualifier Description

ALLELE DBREF ElementType All elements in the MDB of a particular type

CONNECTIONS DBREF array Connections

CONNECTIONSH DBREF array Connections for all descendants

CONNER String Int Connection error message

DDEP Int Database depth within hierarchy (World is 0)

FRSTW DBREF String Reference of first world of given DB type in

current MDB

MAXD Int DB hierarchy depth of lowest level item

beneath element

MBACK DBREF array *ElementType Members in reverse order

MCOU Int *ElementType Number of Element Members of Given type

MEMB DBREF array *ElementType All members, or members of specific type

OWNLST DBREF array Owning hierarchy

PARENT DBREF *ElementType Reference of ascendant element of

specified type

SEQU Int Sequence Position in Member List

TYSEQU Int Type Sequence Number

‘*’- qualifier is optional

© Copyright 1974 to current year. 2:10 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

3 Attributes

3.1 Attribute Types

Attributes can be the following types:
• Integer
• Real
• Bool (or Logical)
• String (or Text)
• Ref
This is a pointer to another element by storing its internal database reference (as
Integer(2) array)
• Position
This is a special form of Real(3) array containing 3 distances
• Direction
This is a special form of a Real(3) array
• Orientation
This is a special form of a Real(3) array
• Word
This a character string of up to either 4 or 6 ASCII upper case character string stored
as an integer which is often interpreted either as an enumerated value or as a user
readable name. Words are used for the simple names and for many enumerated
integer values. They are often called hash codes.
If more than 4 (or 6) characters are entered only the first ones will be used, but without
generating an error. Lower case characters will be converted to uppercase, and non
ASCII unicode characters will be ignored. The word cannot contain a space. The space
is one of the characters that will automatically delimit the string.
Different attributes are limited to either 4 or 6 characters, although attribute and
element type names do have up to 6. Whether 4 or 6 are allowed is an implementation
issue and the older attributes existing in originally introduced in earlier databases tend
to be limited to 4 characters.
Examples of their use are TYPE of elements and attributes.
• Modifier attributes (JUST = TOP, BOT)
• Pline names
Unit field of real attributes and dimension setting attributes (PTYPE = DIST, BORE,
NONE etc)
Attributes may also be arrays of simple attributes Those supported are:
Integer Array
Real Array

© Copyright 1974 to current year. 3:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

Bool (or Logical) Array

Ref Array

3.2 Real Attributes of Physical Quantities

Real attributes can be purely numeric, but often they may be representing physical
quantities. The type of a physical quantity is its (physical) dimension.
Attributes of physical quantities are consistently stored in the database in defined database
units, irrespective of the current working units, or of the units of any value entered by the
user. The whole system operates on the expectation that all stored values of physically
dimensioned quantities are in their relevant standard database units.
The following table lists the dimensions understood by the system giving:
Their name (or description) recognised by the system,
The assigned hashcode,
The database storage units.
Supported standard units for the quantity
For example attributes of length have a hash code of DIST are stored in mm and other
standard units include inch, cm, ft, metre etc.

Name of HashCode/ Database Other Specific Comments

Dimension Word Units Units
AbsPressure ABSP pascal bar atm PSI torr pressure may be
mmHg inHg absolute or gauge

Angle ANGL degree radian grade arcmin

arcsec

AngularMomentum ANGM N.m.s

Area SQDI mm2 acre hectare

Bore BORE mm in Range of bore units

limited to mm and
inch (and Finch)

Capacitance CAPA farad

Charge CHAR coulomb

Conductance COND siemens

Content PCUD mm-3

Currency CURY USDollar UKPound Euro

Current CURR ampere

Density DENS kg/m3

DensityMANDB MAND kg/mm3 densities stored in

MANU database

ElectricConductivity CNDT Si/m

ElectricField EFLD V/m2

© Copyright 1974 to current year. 3:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

Name of HashCode/ Database Other Specific Comments

Dimension Word Units Units
EMF EMF volt

Energy ENER kiloWatthour joule BTU cal

EnergyDensity EDEN kg/m3

Force FORC newton poundal dyne kgF

lbF

FoulingFactor FFAC m2.K/W

Frequency FREQ hertz rpm

GaugePressure GAGE pascal bar atm PSI torr pressure may be

mmHg inHg absolute or gauge

HeatCapacity ENTR J/m

HeatingValue HVAL J/m3

HeatTransferCoeff HTRA W/m2/K

Impedance IMPE ohm

Inductance INDU henry

Inertia INER kg/m2

KinematicViscosity KVIS m2/s

Length DIST millimetre m in ft cm km mile

yard micron thou
angstrom

LinearDensity PDIS mm-1

MagFieldIntensity MFIN A/m

MagFluxDensity MFXD tesla

MagneticFlux MGFX weber

Mass MASS kilogram gram tonne pound

oz longTon shortTon
cwt

MassFlow MFLO kg/s

Momentum MOME N.s

Permeability PMBT H/m

Permittivity PMTT F/m

Power POWE kiloWatt hp watt

Pressure PRES pascal

RadiationDose RDOS sievert radd rem gray

Radioactivity RADY bequerel curie

Resistivity REST ohm/m

RotationalStiffness STFR N.m/rad

© Copyright 1974 to current year. 3:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

Name of HashCode/ Database Other Specific Comments

Dimension Word Units Units
SpecHeatCapacity SHCP N/K

SpecificEnergy SENG J/kg

Speed SPEE m/s

Stiffness STIF N/m

SurfaceDensity PSQD mm-2

Temperature TEMP degCelsius degF K degRankine

TemperatureGradient TPDI degC/mm

ThermalConductivity TCON W/m/K

ThermalResistance TRES K/W

Time TIME second min hr day month

week year

Torque TORQ N.m

UnitMass UMAS kg/mm

ViscosityDynamic VISC s/Pa

Volume CUDI mm3 litre ImpGallon

USGallon

VolumetricFlow VFLO m3/s

None NONE numerical real

attribute

WORD WORD used in assigning

parameter
dimensions etc.

Parameter UNIPAR used for parameter

attributes

3.2.1 Values of Physical Quantities

A value of a real physical quantity has a numerical value (the number) and defines units of
measure which are the units in which the quantity is measured. For example a distance can
be 25.4mm or 1inch but regardless of the number it is the same distance because there is a
known conversion factor between millimetres and inches.
Value may be entered into the system with a unit qualifier which determines the dimension
of the physical quantity and sets its value in those units.
The system will automatically convert from the input unit to the database unit, and from
database unit to a presentation unit (for example the 'current' unit) using internally defined
conversion factors. For compound units (e.g. from 'pound per square inch' to 'pascal') the
conversion factors of the component units are combined together.
The internal conversion units used are sourced as accurately as possible. Some
conversions are arithmetically exact for example, inches:mm, and SI conversions as listed
by Bureau International des Poids et Mesures:

© Copyright 1974 to current year. 3:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf
Some conversions are experimentally determined (e.g. conversion from Kg force to
Newton) and precise published values are used.
All the values are consistent with those published, for example, by US National Institute of
Standards and Technology and listed at
http://physics.nist.gov/Pubs/SP811/appenB8.html
When more accurate values greater than 7 significant figures are obtainable from other
sources such as
http://en.wikipedia.org/wiki/Template:Convert
and elsewhere these have been used in preference.
There is one exception to this rule. The British Thermal Unit (BTU) which is defined by
PDMS to be a 'typical' value of 1055.16kJ and not that defined by Fifth International
Conference value of 1055.05585262kJ.

3.2.2 Standard Units

There are a set of standard specific units that the system will understand. Ideally the unit
qualifier should be appended to the value (e.g. 6.5inch) but often it can be recognised if
separated from its value (e.g. 6.5 inch); but not always.
For each unit there is an abbreviated form, a long form, and a full form (which are often
identical) (e.g. mm and millimetre). All can be understood including curtailed versions of the
long form (e.g. metre and met etc.) always providing there are no other ambiguities.
However in general, the long form will be necessary if the unit is solitary (i.e. not part of a
compound unit) and especially if the unit qualifier is space separated from its value.
The set of standard units are:

Abbreviation Long Name Fullname Hash Code Physical Dimension

arcmin arcmin arcmin ARCM Angle
arcsec arcsec arcsec ARCS Angle
deg degree degree DEG Angle
grad grad grade GRAD Angle
rad radian radian RAD Angle
acre acre acre ACRE Area
ha hectare hectare HECT Area
F farad farad FARA Capacitance
C coulomb coulomb COUL Charge
mho mho mho MHO Conductance
Si siemens siemens SIEM Conductance
EUR EUR euro EURO Currency
GBP GBP GBPound UKPD Currency

© Copyright 1974 to current year. 3:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

Abbreviation Long Name Fullname Hash Code Physical Dimension

USD USD USDollar USDO Currency
A ampere ampere AMP Current
V volt volt VOLT EMF
BTU BTU BTU BTU Energy
cal calorie calorie CALO Energy
J joule joule JOUL Energy
kWh kWh kiloWatthour KWH Energy
dyn dyne dyne FORC Force
kgf kgf kgForce KGF Force
lbf lbf poundForce LBF Force
N newton newton NEWT Force
pdl pdl poundal PDL Force
Hz hertz hertz HERZ Frequency
rpm rpm rpm RPM Frequency
ohm ohm ohm OHM Impedance
H henry henry HENR Inductance
Angst angstrom angstrom ANGS Length
cm cm centimetre CM Length
ft ft foot FOOT Length
in in inch INCH Length
in inch inch FINC Length
km km kilometre KM Length
m metre metre METR Length
micron micron micron MICR Length
mile mile mile MILE Length
mm mm millimetre MM Length
thou thou thou THOU Length
yd yd yard YARD Length
T tesla tesla TESL MagFluxDensity
Wb weber weber WEBE MagneticFlux
cwt cwt hundredweight CWT Mass
g gram gram GRAM Mass
kg kg kilogram KG Mass

© Copyright 1974 to current year. 3:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

Abbreviation Long Name Fullname Hash Code Physical Dimension

lb lb pound POUN Mass
oz oz ounce OZ Mass
shortTon shortTon shortTon STON Mass
ton longTon longTon TON Mass
tonne tonne tonne TONN Mass
hp hp horsePower HP Power
kW kW kiloWatt KWAT Power
W watt watt WATT Power
atm atm atmosphere ATM Pressure
bar bar bar BAR Pressure
inHg inHg inHg INHG Pressure
mmHg mmHg mmHg MMHG Pressure
Pa pascal pascal PASC Pressure
PSI PSI PSI PSI Pressure
torr torr torr TORR Pressure
Gy gray gray GRAY RadiationDose
radD raddose radDose RADD RadiationDose
rem rem rem REM RadiationDose
Sv sievert sievert SIEV RadiationDose
Bq bequerel bequerel BEQU Radioactivity
Ci curie curie CURI Radioactivity
knot knot knot KNOT Speed
degC degC degCelsius CELS Temperature
degF degF degFahrenheit FAHR Temperature
degRan degRan degRankine RANK Temperature
K kelvin kelvin KELV Temperature
day day day DAY Time
hr hour hour HOUR Time
min minute minute MINU Time
mth month month MONT Time
s second second SECO Time
wk week week WEEK Time
yr year year YEAR Time

© Copyright 1974 to current year. 3:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

Abbreviation Long Name Fullname Hash Code Physical Dimension

P poise poise POIS ViscosityDynamic
ImpGal ImpGal ImpGallon GALI Volume
l litre litre LITR Volume
USGal USGal USGallon GALU Volume

Where there are US and SI spelling alternatives BOTH versions are supported for example
litre and liter, millimetre and millimeter etc.

Special Units for Combined Feet and Inches Units (FINCH)

There is a significant extension of input in feet and inches (so-called FINCH format).
A double quote (") may be used as a unit qualifier for inch in any context (decimal inch input,
or finch input).
In FINCH format a single quote (') is accepted as an abbreviation for feet and must be used
for non format controlled input) and a double quote for inches.

Note: " and ' qualifiers are NOT accepted for minutes and seconds or arc units.

The feet and inch value is entered using both feet and inch unit qualifiers, and the fractional
part of inches can either be entered as a decimal, 5'2.125" or as a fraction 5'2.1/8". The inch
qualifier can be any inch qualifier or none (as it is syntactically redundant).

Additions for Format Controlled Finch Input

If the input is controlled by a format object the foot qualifier can be any foot qualifier (ft, foot,
blip) and the inch qualifier can be placed after the integer inch value OR at the end of the
inch value, or omitted.

3.2.3 SI Unit Prefixes

Any unit may have an SI unit prefix preceding it which can be applied either directly (as in
hectogramme) or with an intervening underscore (hecto_gramme).
Unlike the units themselves the SI prefix cannot be abbreviated as it would introduce too
much syntax ambiguity.
Many standard units actually incorporate the SI prefix in them (mm, cm, kg) these are still
standard units so it is actually (although misleadingly) possible to duplicate this as in millikg
(which is, equivalent to a gram).
The system does not forbid use of SI prefixes with imperial units, although, this is not to be
encouraged.
The set of prefixes supported are:

Prefix Multiplier

Exa 1E+18

Peta 1E+15

Tera 1E+12

© Copyright 1974 to current year. 3:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

Giga 1E+09

Mega 1000000

kilo 1000

hecto 100

deca 10

deci 0.1

centi 0.01

milli 0.001

micro 0.000001

nano 1E-09

pico 1E-12

femto 1E-15

3.2.4 Compound Units

Units may have powers applied by immediately appending an integer power. This is often
the only way of inputting the units of some values. Limited alternative verbose forms are
supported using additional words square and cubic (which can be abbreviated down to SQU
and CUB). For example:
25ft2
25 square feet
300cm3
300 cubic centimetres
However the verbose syntax will not work with all abbreviations of standard units.
For compound units requiring more than one unit these should be appended either using a
dot (.) or a slash (/) which inverts the following power. Density, Speed and Moments can be
input using forms such as:
300kg/m3
55mile.hr-1
100newton.metre
Again limited verbose forms are also supported using either concentrated units or the
additional word 'per' as in
55 lb per cubic foot
60 mile per hour
100 newton metre
However whenever values are reported back the verbose forms are generally NOT used.
In general there is no serious limit to the complexity of compound units that may be entered.

© Copyright 1974 to current year. 3:9 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

However when compound units are stored by the system, in particular when setting current
working units or setting PML variables, there are limitations to the complexity of compound
units that can be maintained.
No more than 4 component units can be used.
Each component unit can have:
• The named unit itself
• An optional power of the unit (multiple and/or reciprocal)
• An optional SI Prefix
When there is only one component it can be one of:
• Any standard unit
• -8>power>+8
• SI Prefixes femto to Exa
If there are two components these are defined with:
• Any standard unit
• -8>power>+8
• SI Prefixes femto to Exa for first component, and milli to Mega for second
If there are three components these are defined with:
• Any standard unit for first components, limited to 64 common units for last
• -8>power>+8
• NO SI Prefixes
If there are four components these are defined with:
• Limited to a set of 32 common units
• -2>power>+2 except the last unit which has power range of +/-4
• NO SI Prefixes
When the choice of units, powers or prefixes are restricted, the order of components may be
adjusted to match a compound unit in range.

3.2.5 Units of Absolute and Gauge (gage) Pressures

A trailing qualifier of .abs or .gauge or .gage when added to any pressure unit will be
accepted on input and in string conversion.
• The trailing qualifier will create a quantity with dimension of either absolute or gauge
pressure.
• This trailing component can be added to both standard units such as pascal, bar, psi,
atmosphere (bar.abs) and compound units (N/m2.abs, lbf/in2.gauge).
Note: The user cannot apply a single “a” or “g” as this means ampere or gram!

• The .gauge or .abs will be appended to compound units when quantities are formatted
as gauge or absolute pressures.
A trailing “a” or “g” will be accepted on standard units (and their abbreviations) on input, and
on string conversion.
• The trailing g or a will create an object with dimension of either gauge or absolute
pressure, for example pascala, barg, psig, Paa, Pag
• It will be appended to standard units when quantities are formatted as gauge of
absolute pressures

© Copyright 1974 to current year. 3:10 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

When gauge and absolute pressures are used in expressions they will always revert back to
generic pressures. In particular there is no conversion factor applied between gauge and
absolute pressures and so absolute is considered the same as generic pressures.
The two additional pressure dimensions are supported for absolute and gauge pressures
(ABS_PRESSURE and GAUGE_PRESSURE)
• These can be set in format objects (both PML and .Net) and used to format generic
pressure quantities.
• They can be set for UDAs or Properties to define values of these will always be output
as gauge or absolute quantities
• They will be able to have their own current units, distinct from generic pressure units.
(similarly to DIST and BORE)

3.3 Query Attributes

3.3.1 Query the List of Attributes

The attributes available for an element will depend on its type, e.g. a site will have different
attributes to a branch. The lists of valid attributes can be obtained as follows:
1. The ATTLIS attribute returns the list of all non pseudo attributes for that element. This
list includes UDAs and hidden attributes. The same list is used for the PML DBREF
ATTRIBUTES method.
2. The ATTOUT attributes is as for ATTLIS but excludes hidden attributes. This list is
used when doing a ‘Q ATT’ and by the attribute utility form. Attributes that are hidden
can still be queried individually in the normal way.
3. The valid UDAs can be queried using the UDALIS attribute. This includes hidden
UDAs.
4. The PSATTS attribute returns the list of valid pseudo attributes. Typically this list is
large, running into the hundreds. N.B. querying PSATTS can be slow.

3.3.2 Standard Attribute Query

An attribute value may be obtained as follows:
Specify the attribute name after QUERY or on the RHS of a PML assignment. This will
return the attribute value, if valid, for the CE.
Q XLEN
!A = XLEN
Via a DBREF object using the attribute name as a method, or using the ‘Attribute’ method.
Q var !!CE.XLEN
!A = !!CE.ATTRIBUTE(‘XLEN’)
The querying is the same for UDAs or pseudo attributes.
!RESULT = !!CE. ATTRIBUTE(‘ATTLIS’)
!RESULT = !!CE. ATTRIBUTE(‘:MYUDA’)
The type of the PML variable will depend on the type of the attribute and whether it is an
array or not. Attributes of INTEGER type will be assigned to a PML variable of type REAL.
Attributes of type WORD are assigned to PML variable of type TEXT.

© Copyright 1974 to current year. 3:11 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

If the attribute is a DISTANCE attribute and current DISTANCE units are inch or finch, then
the value will be converted to inches. If the attribute is a BORE attribute and current BORE
units are inch or finch, then the value will be converted to inches.
If the attribute is a REAL attribute and it is defined to be one a physical quantity (distance,
angle, mass, whose metal data UNIT is set to a dimensions such as DIST, ANGL, or MASS
etc.) then the attribute is returned in the current units of that quantity.
If it is an attribute of volume capacity (CUDI) and the current units are derived from current
distance units of INCH or FINCH the value will be reported in cubic inches.

PML1 Syntax
PML1 syntax allows an attribute to be passed to a PML variable without the ‘=’ operator. If
this is done then the value will always be formatted to a TEXT using the current units if
applicable.
VAR !RESULT XLEN
!RESULT will be of type TEXT
The VAR command has many forms but in all cases it creates PML STRING variables, not
Numbers. If the contents are values and numbers then where these are physical quantities
they will be appended with the units of the values as stored in the system.
VAR !RESULT XLEN
Will store the text equivalent of the value of the XLEN attribute in current distance units.
Q VAR !!CE.XLEN
Will return the text string form of !!CE.XLEN. It does this by using the STRING (actually
queryString) method of the (temporary) real variable created by !!CE.XLEN. The real
variable will be created in current units and the STRING method will append the unit
qualifier to the value output
<REAL> 18.1102362204724in

Use the OF Syntax

Attributes my be queried on other elements by using the ‘OF’ syntax.
Q XLEN of /MYBOX
!RESULT = XLEN OF /MYBOX
The syntax following the OF may be any ID expression.
!RESULT = XLEN of NEXT BOX
!RESULT = DESC OF CREF.

3.3.3 Query Arrays

If the attribute is an array, the query will return a list of values. Individual elements can be
queried by passing in the index number.
!VALUE = !!CE.DESP[2]
!VALUE = DESP[2]
Alternatively, the NUM keyword can be used for PML 1 syntax. A range of values can be
returned using the TO keyword.

© Copyright 1974 to current year. 3:12 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

VAR !VALUE DESP NUM 3 - to retrieve the 3rd value

VAR !VALUE DESP NUM 3 TO 5 - to retrieve 3rd to 5th values
Q DESP NUM 3 TO 5
An error will occur if attempting to query off the end of the array.
Within a PML1 expression, a position attribute may be queried as an array in order to
access the individual coordinates.
VAR !X (POS[1] ) - This will return the X coordinate.

3.3.4 dot Notation in PML

For reference attributes, the PML dot notation can be used to achieve a similar result.
!RESULT = !!CE.ATTRIBUTE(‘CREF’).DESC
This will return the description of the element pointed to by the CREF attribute on the CE.

3.3.5 Qualifier
Many pseudo attributes take a qualifier. The qualifier is the extra information required to
make the query. Examples of where a qualifier is used are:
1. Querying a ppoint position (PPOS) requires the ppoint number
2. The ATTMOD attribute can be used to query when an attribute was modified. The
qualifier is the attribute to test for modification.
3. A direction/position may be queried wrt another element.
The definition of what pseudo attributes take what qualifier is described in the data model
reference manual.
The qualifier follows the attribute name in brackets. Attribute qualifiers must be preceded by
the keyword ATTNAME and element types must be preceded by the keyword TYPENAME.
Q PPOS(1) - PPOS has an int qualifier
Q LASTMOD(ATTNAME XLEN) - LASTMOD has an attribute qualifier
Q MEMBER(TYPENAME BOX) - MEMBER has an optional element type qualifier
For PML variables, the qualifier should be assigned to a PML array object and passed to the
‘Attribute’ method as the second argument:
to query PPOS 1
!q=object array()
!q[1] = 1
q var !!ce.attribute('PPOS', !q)
to query list of nominal bores:
!q=object array()
!q[1] = 'BORE'
q var !!ce.attribute('NOMBMM', !q)
to query Equipment members:
!q=object array()
!q[1] = object elementtype('EQUI')
q var !!ce.attribute('MEMBER’, !q)

© Copyright 1974 to current year. 3:13 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

3.3.6 Relative Positions, Directions, Orientations

Positions, Orientations, directions can be queried relative to another element using the WRT
syntax.
Q POS WRT /MYBRAN
Q PPOS(1) WRT /MYBRAN
The use of WRT is described more fully in the Expressions.

3.3.7 Summary of Related Pseudo Attributes

Pseudo attributes relating to the list of attributes.

Attribute Data Type Qualifier Description

Name
ATTLIST WORD(300) List of all visible attributes for element
PSATTS WORD(500) List of pseudo attributes
UDALIS WORD(300) List of UDAs
UDASET WORD(300) List of UDAs set

Pseudo attributes relating to the name.

Attribute Data Type Qualifier Description

Name
CUTNAM STRING(700) NUMBER Full name of element, truncated to n
characters
CUTNMN STRING(700) NUMBER Full name of element (without leading slash)
truncated to n characters
FLNM STRING(700) Full name of the element
FLNN STRING(700) Full name of the element (without leading
slash)
ISNAMED BOOL True if element is named
NAMESQ STRING(700) Type. sequence number and name of element
NAMETY STRING(700) Type and name of the element
NAMN STRING(500) Name of the element (without leading slash)
NAMTYP STRING(700) Type and full name of element

Pseudo attributes relating to the type.

Attribute Data Type Qualifier Description

Name
ACTTYPE WORD Type of the element, ignoring UDET, truncated
to 4 or 6 characters.
AHLIS WORD(200) List of actual types in owning hierarchy

© Copyright 1974 to current year. 3:14 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

Attribute Data Type Qualifier Description

Name
OSTYPE WORD Short cut for "Type of owner"
TYPE WORD Type of the element, ignoring UDET, truncated
to 4 or 6 characters

3.4 Set Attributes

3.4.1 Standard Syntax

Attribute values can be set in two ways:
1. By assigning a value via a PML variable e.g. !!CE.XLEN = 99
Note: There must be a space between the ‘=’ and a digit. “!!CE.XLEN =99” would not be
valid.

2. Use the attribute name to assign a value to the CE e.g. XLEN 99

The following general rules must be followed:
• The value assigned must be the correct type for the attribute type (see examples
below)
• PML variables can not be directly used if using method (2). The PML variable must be
expanded using the late evaluation syntax, i.e. ‘XLEN !A’ is invalid but ‘XLEN $!A’ is
OK. This also applies to any PML variables within expressions.
The behaviour for each attribute type is described below:
REAL attribute - allows an int, real or real expression
!A = 1000
!!CE.XLEN= !A
!!CE.XLEN= (99.9 + !A )
XLEN $!A
XLEN (99.9 + $!A )
XLEN (99 + XLEN OF PREV BOX )
INTEGER attribute - allows an int, a real or real expression. The result will be rounded to
the nearest integer.
!!CE.AREA = 99.6
Q AREA – will now return 100
TEXT attribute - allows a text value, a text expression, or UNSET. Assigning UNSET will
result in a zero length string.
!A = ‘Some text ‘
!!CE.DESC = ‘My description’
!!CE.DESC = (!A + ‘extra text’)
DESC UNSET
LOGICAL attribute - allows FALSE, TRUE or logical expression.
SHOP TRUE
!A = 99
!B = 100

© Copyright 1974 to current year. 3:15 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

!!CE.SHOP ( !A GT !B)
SHOP ( $!A GT $!B)
DATETIME attribute - allows a datetime value, NOW sets current date and time whereas
TODAY sets current date. The datetime is parsed from a text and formats supported are
ISO and the current locale.
!!CE.STADAT= ‘2012-05-20 11:00:00’
STADAT NOW
STADAT TODAY
STADAT UNSET’
REF attribute - allows a name, refno, ID expression, or UNSET, NULREF keywords. The
UNSET and NULREF keywords both result in a null reference (=0/0) being assigned.
CREF =123/456
CREF /MYBRAN
CREF UNSET
CREF NULREF
!!CE.CREF (FIRST MEMBER OF /PIPE1 )

Note: There must be a space between the name and the ‘)’

WORD attribute - If assigning to a PML variable, then allows a text value or text expression.
!A = ‘FLG’
!!CE.TCON = !A + ‘D’
If assigning via the attribute name, then it must be a word.
TCON FLGD
POSITION attribute - allows a position or position expression.
HPOS N 100 U 100
!!CE.POS = (N 100 from /MYEQUIP )
AT N 100 from /MYEQUIP

Note: The POS attribute can not be set by name, use AT syntax instead.
Do not use brackets if setting by attribute name.

DIRECTION attribute - Allows a direction or direction expression

HDIR N 45 U
HDIR TOWARDS /MYEQUIP
!!CE.HDIR = (TOWARDS /MYEQUIP )

Note: Do not use brackets if setting by attribute name.

ORIENTATION attribute - Allows an orientation or an orientation expression

ORI N IS U
!!CE.ORI = (N IS E WRT /VESS1 )

Note: Do not use brackets if setting by attribute name.

The value being assigned to an attribute must either be dimensionally equivalent to the
attribute, or else a numerical value (which is taken to be in current working units of the
dimension). If there is a clash of physical quantity an error will occur. The following will all
generate errors.
XLEN 5kg

© Copyright 1974 to current year. 3:16 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

!!CE.XLEN = 5kg
XLEN $!W where !W has been set to 5kg

3.4.2 Set a UDA Back to a Default

A UDA may be set back to it’s default by using the DEFAULT keyword.
:MYUDA DEFAULT

3.4.3 Set an Array

If assigning via a PML variable, an array attribute must be assigned from a PML array
object.
!!CE.DESP = !MYARRAY
If assigning via the attribute name, then a list of values must be given.
DESP 1 2 3 4 5

3.4.4 Single Value of an Array

If assigning via a PML variable, an index number may be specified in square brackets.
!!CE.DESP[2] = 99
If assigning via the attribute name, a single value of an array may be set using the NUMB
keyword. The NUMB keyword follows the attribute name, and is followed by the index
number.
DESP NUMB 2 99

This sets the 2nd value of the array to 99.

The NUMB command actually specifies the start point for a list of values.
DESP NUM 3 99 100 101

This would set the 3rd value to 99, the 4th to 100 and the 5th to 101.
The new values may go off the end of the existing array, but the start point must not be more
than one beyond the existing end point.
DESP 1 2 3 - set up initial values
DESP NUMB 4 99 - OK, as at end
DESP NUMB 6 100 - Error, as would leave a gap

3.4.5 Special Syntax for Names

Name Design Elements

All elements except the WORLD can be named. Although Design elements are often given
suitable names while being created, later name changes can be made by giving a new

© Copyright 1974 to current year. 3:17 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

name or by removing the old name. The name of any element must be unique; that is, not
already used for another currently accessible element.

Examples:

NAME /ZONE5D The current element is given the specified name provided it
has not been used elsewhere.

UNN The current element loses its name (it is still identifiable by its
automatically allocated reference number).

Command Syntax:
>-- NAMe --+-- ALL name name --.
| |
‘-- name -----------+-->
>-- UNName -->

Rename Elements and Their Offspring

The name of the current element and offspring can be modified where a standard name part
occurs.

Example:

REN ALL /Z1 /Z2 All occurrences of /Z1 in the names of the current element
and its offspring will be changed to /Z2.

Command Syntax:
>-- REName --+-- ALL name name --.
| |
‘-- name -----------+-->

3.4.6 Special Syntax for LOCK

Lock Elements Against Alteration and Deletion

Locking a design element prevents it from being modified or deleted. The LOCK command
allows either a single element to be controlled, or all its offspring too. (A complete Site can
be locked if required.) This provides you with personal security control over your area of
work. (General security restrictions affecting the whole Project are established in the
ADMINISTRATION module of Outfitting.)

Examples:

LOCK ALL The current element and all its offspring are locked.

UNLOCK The current element is unlocked.

Command Syntax:
>--+-- LOCK ----.

© Copyright 1974 to current year. 3:18 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

| |
‘-- UNLOck --+-- ALL --.
| |
‘---------+-- <snoun> --.
| |
‘-------------+-->

3.4.7 Related Pseudo Attributes

Attribute Data Type Qualifier Description

Name
DACMOD BOOL ATTR True if DAC allows attribute of element to be
modified
MODATT BOOL ATTR True if attribute of element can be modified
MODERR STRING(120) ATTR Returns the error text that would occur if
attribute was modified

3.5 PML Attribute Class

3.5.1 Creation
A PML attribute instance may be created for a system attribute or a UDA.
!AXLEN = object attribute('XLEN')
!UINT = object attribute(':UINT')
The class should not be confused with the attribute value. The actual Attribute value for a
particular Element can only be accessed via the DBREF class or via the QUERY command.
Comparing two Attributes just compares whether they identify the same attribute, the
comparison does not look at attribute values in any way.

3.5.2 Methods
The Attribute instance can then be used for querying the ‘meta data’. i.e. data about data.
The methods of the class allow the following to be queried.

String Type() Attribute type

String Name() Attribute name
String Description() Attribute description
Int Hash() Attribute hash value
int Length() Attribute length
bool IsPseudo() Whether pseudo or not
bool IsUda() Whether a UDA or not
string querytext() As output at the command line when querying attribute

© Copyright 1974 to current year. 3:19 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

string units Either BORE, DISTANCE or NONE

Returns the unit field of the attribute which is the string of the
hash code of the dimension of the attribute (BORE, DIST,
MASS, ANGL, or for numbers of no physical quantity
NONE). For UDAs it is the value of the UTYP attribute.
bool Noclaim() Whether attribute can be changed without doing a claim
ElementType array List of Elements for which the attribute is valid. This only
ElementTypes works for UDAs
Real array limits Min/Max values for real/int types
String array List of valid for text attributes. The list may vary with element
ValidValues(ElementType) type
string DefaultValue Attribute default. This only works for UDAs
(ElementType)
string Category() Determines the grouping of attributes on the ‘Attribute Utility’
form
bool hyperlink() if true then the attribute value refers to an external file
bool connection() if true then the attribute value will appear on the reference
list form
bool hidden() If true then attribute will not appear on the Attribute utility
form or after ‘Q ATT’
bool protected() if true then attribute is not visible if a protected DB

Note: We do yet not support direct usage of this class in other syntax.

3.6 PML ElementType Class

3.6.1 Creation
An ElementType instance may be created for a system Element type or a UDET.
!EQUI = object elementtype('EQUI')
!UEQUI = object elementtype(':MYEQUI')
The ElementType instance can then be used for querying the ‘meta data’. i.e. data about
data. The methods of the class allow the following to be queried.

3.6.2 Methods
The available methods are:

string Name() Name of element type

string Description() Description of element type
int Hash() Hash value
bool IsUdet() Whether a UDET or not
Attribute array List of system attributes (excludes UDAs)
systemAttributes()

© Copyright 1974 to current year. 3:20 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

string array DbType()s List of valid DB types

string ChangeType() Indicates if an element of this type may have it’s type changed
ElementType for UDETs this is the base type
SystemType()
ElementType array UDETs derived from this type
bool Primary() Whether the element is primary or not
ElementType array Valid members, including UDETs
MemberTypes()
ElementType array Valid parents, including UDETs
ParentTypes()

Note: We do yet not support direct usage of this class in other syntax.

3.6.3 Related Pseudo Attributes

There are a number of pseudo attributes that return values according to the element type,
as follows:
Attribute Data Type Qualifier Description
Name
HLIS WORD(2000) List of all possible types in owning hierarchy
LIST WORD(2000) List of all possible member types
LLIS WORD(2000) List of all possible types in member hierarchy
OLIS WORD(2000) List of all possible owner types
REPTXT STRING Reporter text used for element type

© Copyright 1974 to current year. 3:21 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Attributes

© Copyright 1974 to current year. 3:22 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Modification

4 Database Modification

This chapter describes the commands to create, copy and modify database elements.

4.1 Modify the Content of a DB

As well as accessing the current content of a DB, you may also (if you have Read/Write
access rights) modify a DB in any of the following ways:
• Create a new element at an appropriate level of the DB hierarchy; see Create a New
Element
• Delete an element from the DB hierarchy; see Delete an Element
• Reorganise the hierarchy by rearranging members of an element into a different list
order or
by moving an element from one part of the hierarchy to another; see Reorganise the
DB Hierarchy
• Define the attributes and offspring of a new element by copying the corresponding
attribute
settings and member lists from another element; see Copy Attributes from One
Element to Another

4.1.1 Create a New Element

To create a new element within an existing DB, you must first ensure that the Current
Element is at a level within the hierarchy which can legally own the element to be created.
For example, a Site can own a Zone, but it cannot own a Valve. To create a new Valve, you
must be at Branch level. You must therefore navigate to the correct level by using one of the
command options described in Database Navigation and Query Syntax.

Note: The Q LIST query will tell you which element types you can create as members of
the Current Element.

You can then create a new element, set its attributes and, if required, create further
elements as its members.

Create an Element After the Current List Position

If you create an element without explicitly identifying its position in the Member List of the
Current Element, the new element is inserted immediately after the Current List Position. To
use this option, enter the command

NEW element_type element_name (element_name is optional)

For example, if the Current List Position is at member 4 (/VALV1) of the Member List.

© Copyright 1974 to current year. 4:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Modification

Figure 4:1. Current Element and its Member List (illustrating movement along list)

the command
NEW TEE /TEE2
adds a new Tee at list position 5 (between /VALV1 and /ELBO2) and names it /TEE2. The
Member List of /BRAN1 thus becomes

Figure 4:2. Result of adding a new Tee

To insert the new Tee as the first or last component in the Member List, access the Branch
Head or Tail, respectively, before giving the NEW TEE command.

Create an Element at a Specified List Position

To create a new element at a specified list position, identify a list position adjacent to the
required position and state which side of it the newly-created element is to go. The
command syntax is one of the following:
NEW element_type element_name BEFore list_position
NEW element_type element_name AFTer list_position
where element_name is again optional and where list_position may be specified in any of
the ways described in Database Navigation and Query Syntax.
Consider the following examples. Starting from the configuration shown, any of these
commands creates a new Tee between /ELBO3 (list position 7) and /FLAN2 (list position 8):

NEW TEE AFTER /ELBO3 Specify name or refno

NEW TEE BEFORE 8 Specify list position number
NEW TEE BEFORE FLAN 2 Specify member type and number (second Flange
in the list)

© Copyright 1974 to current year. 4:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Modification

NEW TEE AFTER LAST ELBO Specify first or last member of a given type (last
Elbow in the list)
NEW TEE AFTER NEXT 3 Specify position relative to Current List Position
NEW TEE BEFORE LAST FLAN Specify first or last member of a given type

The new Tee, which is unnamed, becomes list member 7, /ELBO3 becomes list member 8, /
FLAN2 becomes list member 9, and so on.

Creating a Top Level Element in a Specific Database

To create a new top level element in a specific database there is a DB keyword available in
the syntax of the ‘NEW’ command as follows:
NEW element_type element_name DB database_name
where element_name is again optional and where the database_name is expressed as a
fully qualified database name, i.e. team/database.
The following command will create a new SITE named /MYSITE in the MYTEAM/MYDB
database.
NEW SITE /MYSITE DB MYTEAM/MYDB

4.1.2 Delete an Element

You can delete either the entire Current Element or some or all of its offspring. When you
delete the Current Element, you also delete all of its offspring (that is, its members, their
members, etc.) from the hierarchy. The command must therefore be used with care. When
an element has been deleted, its Owner becomes the new Current Element.
As a safeguard against accidental deletion of parts of a DB, the deletion function operates
only on the Current Element. As further safeguards, the DELETE command word must be
entered in full and the command syntax requires that you confirm the generic type of the
Current Element. Furthermore, access to the required element and its subsequent deletion
must be specified in two separate command lines.
To delete the Current Element and all its offspring, enter
DELETE element _type
For example, to delete a Nozzle, make the Nozzle the Current Element and then enter
DELETE NOZZ
The Equipment which owned the Nozzle becomes the Current Element.
To delete a complete Zone, including all Equipment, Piping, Structures etc. owned by it,
make the Zone the Current Element and then enter
DELETE ZONE
The Site which owned the deleted Zone becomes the Current Element.
To delete only specified members of the Current Element, use one of the following forms of
the command syntax:

DELETE element_type MEMbers (deletes all members)

DELETE element_type MEMbers integer (deletes one member)
DELETE element_type MEMbers integer TO integer (deletes a range of members)

© Copyright 1974 to current year. 4:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Modification

Consider the following examples, where the Current Element is /BRAN1 with the Member
List illustrated in Figure 10-2:

DELETE BRAN MEMBERS Deletes all components from the Branch,

leaving only the Branch Head and Tail

DELETE BRAN MEMBER 6 Deletes only /TEE1

DELETE BRAN MEMBERS 5 TO 7 Deletes /ELBO2, /TEE1 and /ELBO3

4.1.3 Reorganise the DB Hierarchy

You can reorganise the structure of the DB hierarchy, without elements being added to or
removed from its contents, in either of two ways:
• By rearranging the order of the Member List of a single element
• By relocating an element to a different part of the hierarchy
In both cases elements and their offspring are transferred to new positions in the hierarchy.
In the first case the element's owner remains unchanged, while in the second case the
element's owner changes.
To rearrange the Member List of the Current Element, use one of the commands:
REOrder element_id
REOrder element_id BEFore list_position
REOrder element_id AFTer list_position
where element_id specifies an element which is to be moved (which must be a member of
the Current Element) and where list_position may be specified in any of the ways described
in Database Navigation and Query Syntax.
If list_position is omitted, the intended position is assumed to be immediately after the
Current List Position.
For example, starting with the previous Member List:

Figure 4:3. Example Member List

the command
REORDER /ELBO3
moves /ELBO3 to position 5, immediately following the Current List Position, giving the new
Member List

© Copyright 1974 to current year. 4:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Modification

Figure 4:4. Example of REORDER

Starting from either of the above configurations, the command

REORDER /ELBO3 BEFORE FIRST ELBO
moves /ELBO3 to position 3, immediately before /ELBO1, thus

Figure 4:5. Example of REORDER

To insert an existing element into the Member List of the Current Element, when it is not
already a member of that list, use one of the commands
INCLude element_id
INCLude element_id BEFore list_position
INCLude element_id AFTer list_position
where element_id specifies an element which is to be moved (which may be anywhere
within the DB hierarchy as long as it is at an appropriate level) and where list_position may
be specified in any of the ways described in Database Navigation and Query Syntax.
If list_position is omitted, the intended position is assumed to be immediately after the
Current List Position.
For example, starting with the simple hierarchy

© Copyright 1974 to current year. 4:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Modification

Figure 4:6. Example Hierarchy

the command
INCLUDE /PIPE2
moves /PIPE2 (and all its offspring) to the position immediately following the Current List
Position. Ownership of /PIPE2 passes from /ZONE2 to /ZONE1, resulting in the new
hierarchy

Figure 4:7. Example Hierarchy after INCLUDE /PIPE2 command

4.1.4 Copy Attributes from One Element to Another

It is often convenient to create a new element as a copy of an existing element which has
the same, or similar, attribute settings or members to those required. You do this in two
stages:
1. Create a new element (as described in Create a New Element), which becomes the
Current Element.
2. Copy the attributes of another element (the 'source' element) so that they also become
the attributes of the newly created Current Element (the 'target' element). The existing
attribute settings, usually the defaults, are overwritten by the copied settings.
When an element is 'cloned' in this way, all attributes are copied from the source element to
the target element except NAME (which must be unique) and LOCK (which is always

© Copyright 1974 to current year. 4:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Modification

unlocked in the target element). Additionally, and this is what makes the facility so powerful,
all offspring of the source element are copied as offspring of the target element.

Note: If the Current Element already has members, it is not possible to make it a copy of
another element in this way.

You may specify automatic renaming of the Current Element and its offspring as part of the
copying process. Without this the new elements will be unnamed, since Outfitting does not
permit two elements in the same DB hierarchy to have identical names. You may also
choose to copy only the members (and their offspring) of the source element, leaving the
attributes of the Current Element itself unchanged.
To copy a complete element and all of its offspring, after creating a new Current Element
of an appropriate type, enter
COPY element_id
where element_id identifies the source element to be copied.
For example, to create a new item of Equipment which is an exact replica of a previously-
defined Equipment, you might use the command sequence (at Zone level)
NEW EQUI /EQUIPB
COPY /EQUIPA
This creates /EQUIPB as the Current Element and then turns it into an exact copy of /
EQUIPA. All attributes and members of /EQUIPB now have the same settings as those of /
EQUIPA, including its position, orientation etc., and so you will probably now want to move
one of the Equipments to a different location.
To copy all offspring of an element, so that they create duplicate offspring for the Current
Element, enter
COPY MEMbers OF element_id
The position, orientation, etc., of the Current Element now remain unchanged, but it
acquires new members which are derived from the specified source element and which are
correctly positioned relative to the Current Element.
To copy selected offspring of an element, so that they create duplicate offspring for the
Current Element, enter
COPY MEMbers integer TO integer OF element_id
For example, the command sequence
NEW BRAN /SIDEARM
COPY MEMBERS 12 TO 20 OF /MAINLINE
creates a new Branch named /SIDEARM whose components replicate that part of the
existing Branch /MAINLINE between the specified list positions. The attributes of the Branch
/SIDEARM itself are unaffected by the COPY command, so that its position, orientation, etc.
(as defined by its Head and Tail settings) remain unchanged by the addition of its new
members.
To copy attributes from an identified element into the current element, type
COPY ATTributes OF element_id
This causes all attributes (except for references to elements in DESI databases and
OWNER) to be copied to the current element. Or:
COPY LIKE element_id

© Copyright 1974 to current year. 4:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Database Modification

This is similar to the ATTRIBUTES option, except that as well as DESI references not being
copied, neither are any position, direction, orientation or angle attributes.
In both cases, the SPREF and CATREF are also not copied between elements of different
types.
To copy elements alongside their original positions, type
COPY ADJ/ACENT select
This option causes a list of elements, defined by the selection criterion select, to be copied
alongside their original positions in the database. So if the list includes a SCTN and a PNOD
(for example) then each of these items would be copied so that the new SCTN shares the
same owner as the old SCTN and the new PNOD shares the same owner as the old PNOD.
As this option copies elements, rather than just attributes, other COPY options, such as
RENAME, are valid.
To copy all or part of an element and rename the copies, append the command
... REName old_name new_name
to the corresponding COPY command line.
For example, the command
COPY /FRACT1/PIPE RENAME /FRACT1 /FRACT2
copies all attributes and offspring of /FRACT1/PIPE into the Current Element. Where /
FRACT1 occurs as the name or part of the name, it is changed to /FRACT2 in the Current
Element and its offspring. Thus the Current Element itself is now named /FRACT2/PIPE,
and so on.

Related Pseudo Attributes

Attribute Data Type Qualifier Description

Name
DACCOH BOOL True if DAC allows element hierarchy to be
copied to another DB
DACCOP BOOL True if DAC allows element to be copied to
another DB
DACCRE BOOL NOUN True if DAC allows element to be created
DACDEL BOOL True if DAC allows element to be deleted
DACERR STRING(120) ATTR Returns the DAC error
MODATT BOOL ATTR True if attribute of element can be modified
MODDEL BOOL ATTR True if element can be deleted

© Copyright 1974 to current year. 4:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Save Work and Get Work

5 Save Work and Get Work

SAVEWORK saves the current DESIGN changes without leaving DESIGN. It is good
practice to use this command on a regular basis during a long session to ensure maximum
data security.
As well as a comment, an optional number n can be used to specify a particular database
for the command. The number is the number of the database in the order output by the
STATUS command (see Project). If no number is given, the SAVEWORK applies to the
whole MDB. An example of Savework syntax is SAVEWORK ‘comment’ 1.
GETWORK refreshes the view of all READ databases to pick up any changes that other
users may have made since you first opened them. The optional n works in the same way
as for SAVEWORK. You would normally only use GETWORK if you know of specific
changes you wish to pick up and use. Please note that GETWORK slows up subsequent
database access, as the information has to be re-read from disk. Therefore, you should use
this command sparingly.

5.1 Sessions
Each time you enter DESIGN or save your design changes, a new session is created for
each database changed. You can then query when specific items of design data were
modified by reference to the corresponding session number(s). Sessions can be used by
the System Administrator to backtrack changes to a given date or session if necessary.

5.2 Session Comments

You can add a comment for each session, which can help identify the work done in each
session.
Lets you associate comment text with the current DESIGN session. You can query this text
later to help you identify a particular session in which modifications were made to elements
and/or attribute settings. You can enter the session comment before you issue a
SAVEWORK command, or as part of a SAVEWORK command for example SAVEWORK
‘MY COMMENTS’.

Note: Sessions 1 and 2 are created in ADMIN (when the DESIGN DB and its World
element, respectively, are created), so the first true session will be Session 3.

Example:

SESSION COMMENT ’Addition of upper platform’

© Copyright 1974 to current year. 5:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Save Work and Get Work

Command Syntax:
>-- SESSION COMMENT -- text -->

Querying:
Q SESSComment integer
where integer is the session number.
Each time you enter DESIGN or save your design changes, a new session is created for
each database changed. You can then query when specific items of design data were
modified by reference to the corresponding session number(s). Sessions can be used by
the System Administrator to backtrack changes to a given date or session if necessary.

© Copyright 1974 to current year. 5:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Multiwrite Databases Claims and Extracts

6 Multiwrite Databases Claims and Extracts

If a DESIGN or Outfitting Draft DB has been created as a multiwrite database, several

users can write to it simultaneously, although they cannot change the same element.
Multiwrite databases can either be Standard multiwrite databases, or Extract databases. In
both types, an element must be claimed before it can be modified. Claiming an element
prevents other users claiming (and modifying) the element; the element must be released
before another user can change it.

Claiming can be either explicit, where the user must use the CLAIM command before
attempting to modify the element, or implicit, where the claim is made automatically when
the user tries to modify the element. The claim mode is set when the DB is created. For full
details see the Administrator Command Reference Manual.

6.1 User Claims

In a Standard multiwrite database, you must claim an element before changing it. This is
known as a user claim. If the claim mode is explicit (see below for details of how to check
this), you must first claim each element that you want to modify using the CLAIM command.
If the claim mode is implicit, the claim will be made automatically (although you can still give
explicit CLAIM commands if you want to prevent other users claiming specific elements).
Only primary elements can be claimed, these are listed in the Data Model Reference
Manual.
You can claim a specified element only, or a specified element plus all of the significant
elements below it in the hierarchy. If the claimed element is not a significant element, the
significant element above it in the hierarchy will be claimed.
An element must be unclaimed before another user can claim it and change it. User claims
are always unclaimed when you change modules or leaves Outfitting, and you can also
unclaim elements at any time during an Outfitting session using the UNCLAIM command.

Examples:
CLAIM /ZoneA /EQUIP100 /PIPE-100-A
Claims named elements
CLAIM /ZoneA HIERARCHY
Claims named element and all of its owned hierarchy
CLAIM /ELBOW-33
Claims Branch which owns named component, since ELBO is not
a significant element

© Copyright 1974 to current year. 6:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Multiwrite Databases Claims and Extracts

Examples:
UNCLAIM /PIPE-100 /PIPE-200
Unclaims named elements
UNCLAIM ALL
Unclaims all elements currently claimed

Command Syntax:
.---------------.
/ |
>-- CLAIM ----*-- elementname --+-- HIERARCHY ---.
| |
‘----------------+-->

.---------------.
/ |
>-- UNCLAIM ---*-- elementname --+-- HIERARCHY ---.
| | |
‘-- ALL ----------+----------------+-->

6.1.1 Notes on Standard Multiwrite DBs

• Elements cannot be claimed if recent changes have been made to them by other users.
You must issue a GETWORK command first.
• Elements cannot be unclaimed if there are updates outstanding. You must issue a
SAVEWORK command first.
• You can insert/remove primary elements in a members list without claiming the owner.
For example, you can add a Branch to a Pipe without claiming the Pipe. Thus two
users can add different Branches to the same Pipe: any discrepancies will be resolved
when a SAVEWORK is attempted.
• Before an element can be deleted, that element and all of its sub-hierarchy must be
claimed.
• The following potential problems may not be revealed until you try to save changes:
1. If two concurrent users allocate the same name to different elements, the second user
to attempt a SAVEWORK will show up an error. The second user must rename their
element.
2. If one user inserts a significant element into another element’s list, while a concurrent
user deletes the latter element, an attempt to SAVEWORK will show up an error. Either
the first user must delete or move the significant element, or the second user must
QUIT without saving the deletion.

6.1.2 Extract Databases

Unlike standard multiwrite databases, extracts allow users to keep elements claimed when
they exit from Outfitting or change to another module. They can also be used, together with
Data Access Control, to manage workflow. See the Administrator User Guide for more
information.

© Copyright 1974 to current year. 6:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Multiwrite Databases Claims and Extracts

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

empty, with pointers back to the owing or master database. Extracts can only be created
from Multiwrite databases. 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, an extract claim is made as well as a user claim.
If the claim mode is explicit, the extract claim will be made automatically when you make a
user claim using the CLAIM command. You can also claim to the extract only using the
EXTRACT CLAIM command.
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:
• 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.
• 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 or issued.
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. The changes
made to the extract can be written back to the master, or dropped. Also, the extract can be
refreshed with changes made to the master.

Examples:
EXTRACT CLAIM /STRU1 /STRU2 /STRU3
Claims named elements to the extract
EXTRACT CLAIM /STRU1 /STRU2 /ZONE-A HIERARCHY
Claims the named elements, and all the elements in the hierarchy
to the extract
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.
EXTRACT FLUSH DB PIPE/PIPE ‘Description of flush’
Writes all changes to the database back to the owing extract. The
Extract claim is maintained.
EXTRACT FLUSH /STRU1 /STRU2 /STRU3 ‘Flushing three structures’
Writes the changes to the named elements back to the owing
extract. The Extract claim is maintained.
EXTRACT ISSUE DB PIPE/PIPE ‘Issuing /pipe’
Writes all the changes to the database back to the owning extract
and releases the extract claim
EXTRACT ISSUE /ZONE-A HIERARCHY ‘Issuing /zone’

© Copyright 1974 to current year. 6:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Multiwrite Databases Claims and Extracts

Examples:
Writes all the changes to the named element and all elements
under it in the hierarchy back to the owning extract and releases the
extract claim
EXTRACT ISSUE /STRU1 /STRU2 /STRU3 ‘Issuing three structures’
Writes the changes to the named elements back to the owning
extract and releases the extract claim
EXTRACT RELEASE DB PIPE/PIPE
Releases the extract claim: this command can only be given to
release changes that have already been flushed.
EXTRACT RELEASE /STRU1 /STRU2 /STRU3
Releases the extract claim: this command can only be given to
release changes that have already been flushed.
EXTRACT RELEASE /ZONE-A HIERARCHY
Releases the extract claim to the named element and all: elements
under it in the hierarchy.
EXTRACT DROP DB PIPE/PIPE ‘Dropping /Pipe’
Drops changes that have not been flushed or issued. The user
claim must have been unclaimed before this command can be
given.
EXTRACT REFRESH DB MYTEAMPIPING
This will refresh the extract MYTEAMPIPING with changes made
on the parent extract,

The elements required can be specified by selection criteria, using a Programmable Macro
Language (PML) expression. For example:
EXTRACT CLAIM ALL STRU WHERE (:OWNER EQ 'USERA') HIERARCHY

Command Syntax:
>- EXTRACT -+- FLUSH ---------------.
| |
|- FLUSHWithoutrefresh -|
| |
|- RELEASE -------------|
| |
|- ISSUE ---------------|
| |
|- DROP ----------------| .-------<-------.
| | / |
‘- REFRESH -------------+--*-- elementname --+- HIERARCHY -.
| |
| |
| |
‘-- DB dbname ---------------------+->

© Copyright 1974 to current year. 6:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Multiwrite Databases Claims and Extracts

6.1.3 How to Find Out What You Can Claim

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.
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 Figure 6:1.: Querying extract claimlists.

Note: Q CLAIMLIST EXTRACT

tells you what you can flush

Q CLAIMLIST OTHERS
tells you want you can't claim

© Copyright 1974 to current year. 6:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Multiwrite Databases Claims and Extracts

Figure 6:1. Querying extract claimlists

When you create an element, Outfitting 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:
• 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

© Copyright 1974 to current year. 6:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Multiwrite Databases Claims and Extracts

Common Extract Commands

Q DBNAME Returns the name of the database which you are actually
writing to.
Q CLAIMLIST Outputs a list of all elements currently claimed by yourself:
Q CLAIMLIST OTHE Outputs a list of all elements currently claimed by other
users who are accessing the same DB:
Q CLAIMLIST Shows the extract claimlist for all the writable extracts in the
EXTRACT MDB.
Q CLAIMLIST Shows the extract claimlist for the named extract DB.
EXTRACT DB dbname
Q CLAIMLIST Shows the elements claimed to the current extract and not
EXTRACT FREE DB claimed to another extract or user. That is, the elements
dbname which can be released.
Q CLAIMLIST Shows the elements claimed to the current extract and
EXTRACT OTHER DB claimed to another extract or user.
dbname
Q CLAIMLIST Shows the extract claimlist for a CONTROLLED named
CONTROL DB dbname extract DB.
Q DBAC Queries the access mode of the database. DBAC can have
the text settings CONTROL, UPDATE or MULTIWRITE.
Q DBCL Queries the claim mode of the database. DBCL can have
the text settings EXPLICIT or IMPLICIT.
Q LCLM Queries whether or not the current element is claimed by
another user. Returns TRUE or FALSE.

Command Syntax:
>-- Q CLAIMLIST --+- OTHER -----.
| |
|- EXTRACT ---+- OTHER --.
| | |
| |- FREE ---|
| | |
| ‘----------|
| |
|------------------------+-- DB dbname --.
| |
‘----------------------------------------+-->

6.1.4 Related Attributes

DAC related:

Attribute Data Type Qualifier Description

Name
DACCLA BOOL True if DAC allows element to be claimed

© Copyright 1974 to current year. 6:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Multiwrite Databases Claims and Extracts

Attribute Data Type Qualifier Description

Name
DACERR STRING(120) ATTR Returns the DAC error
DACISS BOOL True if DAC allows element to be issued

Claim related:

Attribute Data Type Qualifier Description

Name

CLMID STRING(120) Unique system ID of user claiming element

CLMNUM INTEGER User or extract number claiming element. Extract num-
bers are negative
CLMTIE ELEMENT(4) Reference to elements that are automatically claimed
along with this element
EXCLFR BOOL True if element claimed from this extract. Only True for
Primary elements
EXCLHI ELEMENT(5000) Primary elements in descendant hierarchy claimed to
this extract (includes this element)
EXCLTO BOOL True if element claimed to this extract. Only True for Pri-
mary elements
EXNCLH ELEMENT(5000) Primary elements in descendant hierarchy not claimed
to this extract
EXTRC STRING(120) Name of extract claiming element
NPDESC ELEMENT(5000) List of non primary offspring
OKCLA BOOL True if element may be claimed
OKCLH BOOL True if element and hierarchy may be claimed
OKREL BOOL True if element may be released
OKRLH BOOL True if element and hierarchy may be released
PRIMTY BOOL True if element is primary
PRMMEM BOOL True if there are any primary elements amongst
descendants
PRMOWN ELEMENT Primary owning element (will be itself if primary)
USCLHI ELEMENT(5000) Elements in descendant hierarchy claimed to this user
USERC STRING(120) User name of user claiming element
USNCLH ELEMENT(5000) Elements in descendant hierarchy not claimed to this
user

© Copyright 1974 to current year. 6:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Multiwrite Databases Claims and Extracts

Extract related:

Attribute Data Type Qualifier Description

Name

EXHCNC ELEMENT(5000) As EXTCNC, but repeat test for all descendants

EXHCNN ELEMENT(5000) As EXTCNN, but repeat test for all descendants
EXHCON ELEMENT(5000) As EXTCON, but repeat test for all descendants
EXHRCN ELEMENT(5000) As EXRCN, but repeat test for all descendants
EXHRCO ELEMENT(5000) As EXTRCO, but repeat test for all descendants
EXMOC BOOL As EXMOD but ignoring changes to "noclaim" attributes
and member lists
EXPMOC BOOL As EXPMOD but ignoring changes to "noclaim"
attributes and member lists
EXPMOD BOOL True if primary and element or non-primary descendants
have been modified in this extract
EXTCNC ELEMENT(5000) As EXTCON but excluding non modified elements
EXTCNN ELEMENT(5000) As EXTCON but excluding modified elements
EXTCON ELEMENT(5000) Primary elements connected/disconnected from ele-
ment or non primary descendants in extract
EXTRCN ELEMENT(5000) As EXTCNN, but applied recursively to each connection
EXTRCO ELEMENT(5000) As EXTCON, but applied recursively to each connection
OKDROP BOOL True if element may be dropped
OKDRPH ELEMENT(5000) Primary elements preventing hierarchy drop
OKRLEH ELEMENT(5000) Primary elements preventing hierarchy release
OKRLEX BOOL True if element may be extract released

© Copyright 1974 to current year. 6:9 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Multiwrite Databases Claims and Extracts

© Copyright 1974 to current year. 6:10 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Undo and Redo

7 Undo and Redo

It is possible to undo and redo many operations. The undo mechanism is managed by
Outfitting using a stack of transaction objects.
Each transaction object records the change in the state across the transaction.
The new descriptions are then:
MARKDB ‘comment’ - Complete the current transaction and starts a new transaction.
UNDODB - Undo the last transaction. If there is a current transaction then this is completed.
Multiple Undos are allowed.
REDODB - Redo to next mark. Multiple Redos are allowed. A redo is only valid after an
UNDO. Any database change after an UNDO invalidates a REDO.

7.1 How Undo Works

Every time you select an undo operation an entry is taken off the undo stack. The state
saved in this transaction is restored, and the transaction object is placed on the redo stack.
When the undo stack is empty, then the Undo button and the Undo menu option will be
greyed out indicating that there are no operations remaining that can be undone.
If the operation of undo involves moving into or out of model editing mode, then the switch
into that mode will happen automatically, and the model editor button and menu option will
reflect the change.
The selection set and handle appropriate to the editing operation that was being used will
also be restored.
There are also a number of ways that you can perform an undo:
• By clicking on the Undo button on the appropriate toolbar.
• By selecting the Undo option on the Edit pulldown menu on the main toolbar.
• By entering the command UNDODB n where n indicates how many steps are to be
undone.
The undo stack is automatically cleared after a SAVEWORK or GETWORK.
A similar process to the one described above occurs for redo.
When a transaction is taken off the redo stack, it is put back onto the undo stack.
If the user performs any operation that changes the database after doing an undo, then the
redo stack will be cleared.
Refer to the Software Customisation Guide for controlling the undo stack from user defined
PML.

© Copyright 1974 to current year. 7:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Undo and Redo

MARKDB 'comment' Set a Database mark. Multiple marks may be set.

UNDODB Undo database to last mark. Multiple undos are allowed.

REDODB Redo to next mark. Multiple Redos are allowed. A redo is only
valid after an UNDO. Any database change after an UNDO
invalidates a REDO.

The list of marks can be obtained from PML function MARKDB.

Example:
AREA 0
MARKDB 'First Mark'
AREA 100
MARKDB 'Second Mark'
AREA 200
MARKDB 'Third Mark'
AREA 300
!MARKS = MARKDB
Q VAR !MARKS
UNDODB
Q AREA - value will be 200
UNDODB
Q AREA - value will be 100
UNDODB
Q AREA - value will be 0
REDODB
Q AREA - value will be 100
REDODB
Q AREA - value will be 200
AREA 99
UNDODB
Q AREA - value will be 200
REDODB
Q AREA - value will be 99
The system will always create an initial mark the first time the database is changed.

© Copyright 1974 to current year. 7:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Groups and Secondary Hierarchies

8 Groups and Secondary Hierarchies

A group element can hold in its members list a number of design elements from any
combination of hierarchic levels, they may also span multiple DB’s. You can use any
appropriate design operation to act upon all of these individual elements simply by carrying
out the operation on the group.
Groups are particularly useful when there is a need to create a secondary hierarchy of
elements. For example a set of elements for a project may span more that one site, if this is
the case it is difficulty to identify where in the hierarchy these elements occur. With a group
you can easily query its members and see the hierarchy of elements contained within it.
A group is a DESIGN database element in its own right, and is therefore stored
automatically for use in later sessions when you save database changes.
The Elements which make up a group within the DESIGN database are shown below:

GPWL (Group World) Is a top level administrative element. A GPWL may hold multiple
GPSET (Group Set) elements.
GPSET contains groups of items (GPITEM). A GPSET element has Name, DESC, and
FUNCTION attributes.
GPITEM These are elements within a database which are to be grouped under a Group Set
(GPSET). Elements from different databases can all be grouped into the same Group Set. A
GPITEM has the following attributes Name, DESC and SITEM.
It is possible to nest Group Sets within other Group Sets. To achieve this structure a GPSET
can own another GPSET or a GPITEM can point back onto a GPSET. The following figure
illustrates this:

© Copyright 1974 to current year. 8:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Groups and Secondary Hierarchies

Maintain Groups using the Groups form

The DESIGN module contains a user interface for maintaining and creating Groups, this is
accessed through the Create > Group pulldown within the DESIGN Module. Selecting this
will open the window below.

© Copyright 1974 to current year. 8:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Groups and Secondary Hierarchies

By default the form is populated with all GPWLs and GPSETs in the current MDB and
defaults to the first GPSET in the first GPWL, the Group Members grid will be populated with
the contents of the GPSET.
The Groups form has the following parts:

Control Pulldown

1. Create Group World - Allows the user to create a new Group World. A Group World is
created in the hierarchy at the point of the currently selected item.
2. Create Group Set - Allows the user to create a new Group Set below the currently
selected Group World.
3. Close - Will close the Groups form.

Database Explorer Window

This allows the user to navigate the database hierarchy in exactly the same way as the
standard explorer window in the DESIGN module. The benefit of having this accessible
directly from this form allows the user to quickly select elements to include in a Group set.

Group Worlds Pulldown

This pulldown will expand to hold any Group Worlds created in the database hierarchy.
Changing this pulldown will cause the Groups sub form to display all the Group Sets under
the selected Group World.

© Copyright 1974 to current year. 8:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Groups and Secondary Hierarchies

Groups Sub Form

The Groups sub form displays all the Group Sets which have been created below a Group
World. Selecting a Group Set will cause the Group Members Grid to update.

Group Members Grid

This grid displays all of the elements which have been associated with the currently selected
Group Set (from the Groups sub form).
Maintenance of Groups is carried out through a set of menus accessible through right
clicking the mouse.
Right clicking the mouse in the explorer window will give the following options

© Copyright 1974 to current year. 8:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Groups and Secondary Hierarchies

1. Add Current Element - Add the currently selected element to the Group Set selected in
the Groups Sub Form
2. Add Current Element Members - Add currently selected element and all its members to
the Group Set selected in the Groups Form
3. Remove Current Element - Remove the currently selected element from the Group Set
selected in the Groups sub form
4. Remove Current Element Members - Remove the currently selected element and all its
members from the Group Set selected in the Groups sub form
5. Add From Current List
6. Remove From Current List
Right Clicking the mouse in the Members Grid will give the following options.

1. Remove all - Remove all of the elements and their members from the Group Set
currently selected in the Groups sub form
2. Add All to View - Will add all of the elements and members of the Group Set currently
selected in the Groups sub form into the Design layout of the current project.
3. Remove Selected - Remove the currently selected element from the Group Set
currently selected in the groups form.
4. Add Selected to View - Add the currently selected element into the design layout of the
current project.
5. Navigate - Will move the explorer window to the position in the hierarchy of the
selected element

Command Line Reference

Groups can be accessed through standard command line syntax. For example typing 'Q
MEM' at a GPSET will return all the GPITEM elements associated with the Group.
The following sections summarise the primary methods of maintaining a Group, afterward
are some examples of creating and querying Groups from the command line.

© Copyright 1974 to current year. 8:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Groups and Secondary Hierarchies

8.1 Define Group Contents

The contents of a Group are defined by adding or removing references to or from the list
part of the Group.
In order to use the commands described in this section, the current element must be the
Group whose member list you wish to modify. Specified elements are then added to the list
part of the current element starting from the current list position or are removed from the list
part of the current element such that the current list position becomes the Head position.
The elements to be added to, or removed from, the Group’s member list may be specified in
any of the following ways:
• Explicitly, by name or (system-assigned) reference number.
• As members of specified elements, where a member of an element is defined as any
element immediately below it in the DB hierarchy
• As items of specified elements, where an item of an element is any element anywhere
below it in the hierarchy which has no list part (such as a Valve, Point, Box, etc.)
• By type (such as Equipment, Branch, Pipe, etc.)

Examples:

GADD /ZONE1 /VALVE2

Adds /ZONE1 and /VALVE2 to the current Group, starting from the
current list position

GREMOVE /ZONE1 /BOX3

Removes /ZONE1 and /BOX3 from the current Group and moves
the current list position pointer to the Head position

GADD MEM OF /BRANCH1 /BRANCH2

Adds all the pipe Components in Branches /BRANCH1 and /

BRANCH2 to the current Group, starting from the current list
position

GREM MEM OF /PIPE100 MEM OF /EQUI-B

Removes all Branches of the Pipe /PIPE100 and all members of

Equipment /EQUI-B from the current Group

GREM ITEMS OF /ZONE2

Removes from the current Group all occurrences of those offspring

of /ZONE2 which are items

GADD ALL EQU BRAN OF /ZONE1 /ZONE2

Adds all offspring of /ZONE1 and /ZONE2 which are of types Equip
or Branch to the current Group, starting from the current list position

© Copyright 1974 to current year. 8:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Groups and Secondary Hierarchies

Command Syntax:
>--+-- GADD -----. .-------------.
| | / |
‘-- GREMove --+---*-- <selatt> ---+--->

8.2 Delete Groups

The action of this command differs from normal behaviour if the current element is a Group.

Examples:

DELETE GPSET

Only the current element and any Offspring that are GPSETs will be
deleted.

DELETE GPWLD

Only the current element and any Offspring that are GPSETs will be
deleted.

8.3 Copy a Group

Groups may be copied with a slightly different effect to normal elements.

Examples:

COPY /GROUP21 (At a Group)

The Current Group will contain exactly the same Members as /

GROUP21. No new elements have been created.

8.4 Define Dynamic Groups

The user may specify a dynamic selection for a GPSET. The dynamic selection consists of a
PML1 collection expression. E.g.
ALL PIPE WHERE (BORE GT 80)
ALL BRAN MEMBERS WHERE (SPREF EQ /MYSPEC ) for SITE /SITE1
The selection must be set against the SCOSEL attribute. E.g.
SCOSEL ALL EQUI FROM CLAIMLIST
The selection is evaluated dynamically whenever the group is used. Depending on the
selection used there is a performance overhead in evaluating the selection.

© Copyright 1974 to current year. 8:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Groups and Secondary Hierarchies

© Copyright 1974 to current year. 8:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

9 Expressions

This section explains the PML 1 expressions package. These facilities are needed within
AVEVA products, for example, to define report templates in Outfitting.

Note: Generally, all these facilities are compatible with PML 2.

Expressions have types. For example, you can have numeric expressions, text expressions
and logical expressions. All the elements in an expression must be of the correct type. For
example, if you have a two numbers, x and y, and two text strings text1 and text2, the
following expression is meaningless:

x + text1 $

However, both of the following expressions are valid:

x + y $ adds the values of the numeric variables.

Text1 + text2 $ concatenates the two text strings.

Real expressions also have a physical dimension. This may be NONE when all values in the
expression are purely numerical, but if any value has a physical dimension (such as being a
length or mass) then all other values must be compatible with it and the result of the
expression may have a physical dimension, or it may evaluate to a pure numerical value
(1inch / 1mm = 25.4).
The following types of expressions are available:
• Logical Expressions
• Logical Array Expressions
• Numeric (Real) Expressions
• Numeric (Real) Functions
• Text Expressions

9.1 Format of Expressions

The format of an expression, for example the use of brackets, spaces and quotes, is
important. If you do not follow the rules given below you will get error messages:
Text must be enclosed in quotes.

‘This is text’

© Copyright 1974 to current year. 9:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

There must be a space between each operator and operand. For example:

x + y

Use round brackets to control the order of evaluation of expressions and to enclose the
argument of a function.

SIN(30)

In general, you do not need spaces before or after brackets, except when an Outfitting name
is followed by a bracket. If there is no space, the bracket will be read as part of the name.

(NAME EQ /VESS1 )

9.1.1 Operator Precedence

Operators are evaluated in the order of the following list: the ones at the top of the list are
evaluated first.

Operator Comments

BRACKETS Brackets can be used to control the order in which

operators are evaluated, in the same way as in
normal arithmetic

FUNCTIONS

*/

+-

EQ, NEQ, LT, LE, GE, GT

NOT

AND

OR

9.1.2 Nesting Expressions

Expressions can be nested using brackets.

( (SIN(!angleA) * 2) / SIN(!angleB) )

9.2 Logical Expressions

Logical expressions can contain:
• Outfitting attributes of type logical e.g. BUILT.
• Logical constants. The constants available are: TRUE, ON, YES for true, and FALSE,
OFF, NO for false.
• Logical operators.

© Copyright 1974 to current year. 9:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

• Logical functions.

9.2.1 Logical Operators

Logical expressions involving physical quantities.
If the expression contains unit qualified values, or attributes with a physical dimension then
these values are converted to consistent units before comparison
(2lb equal 32oz) returns TRUE
If a value is not unit qualified it is assumed to be in current units of the quantity defined by
the other value (i.e. the context of the expression). For example if current units of mass
(colloquially weight) are oz then
(2lb equal 32) returns TRUE.
But if current units of mass are kg then expression will return FALSE as 2lb is not equal to
2kg.
If the units are not units of the same physical quantity FALSE will always be returned as the
two values are completely incompatible (as are apples and pears) and a warning issued
(e.g. (2lb equal 32mm).
The logical operators available are:

Operator Comments

AND

EQ, NE The operators EQ and NE may be applied to any pair of values

of the same type.

GT, GE, LE, LT The operators GE, LE, GT and LT may only be used with
numbers and positions. For more information, see Positions,
Directions and Orientations in Expressions.

NOT

OR

Note: The operators EQ, NE, LT, GT, LE and GE are sometimes referred to as comparator
or relational operators; NOT, AND and OR are sometimes referred to as Boolean
operators. See also Precision of Comparisons for tolerances in comparing numbers.

© Copyright 1974 to current year. 9:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

AND

Synopsis log1 AND log2 -> logical

Description Perform the logical AND between two logical values. Treats
unset values as FALSE.

Side Effects If one of the values is undefined and the other one is FALSE,
the result is FALSE.

Example TRUE and FALSE -> FALSE

EQ and NE

Synopsis ( number1 EQual number2) -> logical

( text1 EQual text2 ) -> logical
( log1 EQual log2 ) -> logical
( id1 EQual id2 ) -> logical
( pos1 EQual pos2 ) -> logical
( dir1 EQual dir2 ) -> logical
( ori1 EQual ori2 ) -> logical
( pp1 EQual pp2 ) -> logical
( number1 NEqual number2 ) -> logical
( text1 NEqual text2 ) -> logical
( log1 NEqual log2 ) -> logical
( id1 NEqual id2 ) -> logical
( pos1 NEqual pos2 ) -> logical
( dir1 NEqual dir2 ) -> logical
( ori1 NEqual ori2 ) -> logical
( pp1 NEqual pp2 ) -> logical
Description Compare two values. A special feature is used for the
positions, only the coordinates specified are compared. See
Compare Positions for more information. Unset values result
in FALSE across EQ, TRUE across NE.

Side Effects If two positions have no common coordinate, for example,

’N 10 ne U 10’, the result is undefined. Units are
consolidated across comparisons.

Example ( 1.0 eq 2.0) -> FALSE

Errors None.

© Copyright 1974 to current year. 9:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

GT, GE, LE and LT

Synopsis ( number1 GT number2 ) > logical

( pos1 GT pos2 ) > logical
( number1 GE number2 ) > logical
( pos1 GE pos2 ) > logical
( number1 LE number2 ) > logical
( pos1 LE pos2 ) > logical
( number1 LT number2 ) > logical
( pos1 LT pos2 ) > logical
Description Compare two values. A special feature is used for positions:
only the coordinates specified are compared. See Compare
Positions for more information. For positions, since
comparisons may be performed on more than one value, LT
(GT) is not the inverse of GE (LE). Unset values result in
false

Side Effects If two positions have no common coordinate, the result is

undefined. For example, ’N 10 gt U 10’.
Units are consolidated across comparisons.

Example ( 1.0 LT 2.0) -> TRUE

( N 0 E 10 GT N 10 E 0 ) -> FALSE
( N 0 E 10 GT N 10 E 0 ) -FALSE
Errors None.

NOT

Synopsis NOT log1 -> logical

Description Perform the logical NOT on a logical value.

Side Effects None.

Example not TRUE -> FALSE

Errors None.

© Copyright 1974 to current year. 9:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

OR

Synopsis OR log2 -> logical

Description Perform the logical inclusive OR between two logical values.
(The exclusive OR is defined by using NE.)
Allows numbers instead of logical values.

Side Effects If one of the values is undefined and the other one is TRUE,
the result is TRUE.

Example TRUE or FALSE -> TRUE

Errors None.

9.2.2 Logical Functions

The logical functions available are:

BADREF

DEFINED,UNDEFINED

CREATED

DELETED

EMPTY

IFTRUE

MATCHWILD

MODIFIED

UNSET

VLOGICAL

BADREF

Synopsis BADREF (id) -> logical

Description TRUE if id is invalid, else FALSE.

Side Effects None

Example BADREF(TREF) -> ’true’ if TREF=nulref

Errors None.

© Copyright 1974 to current year. 9:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

DEFINED and UNDEFINED

Synopsis DEFined (variable_name) -> logical

DEFined -> logical
(variable_name,number)
UNDEFined (variable_name) -> logical
UNDEFined (variable_name , -> logical
number)
Description With one argument, DEFINED is true only if the scalar
variable, the array variable or the array variable element
exists.
With two arguments, DEFINED is true only if the first
argument is an array variable which has a value for the index
denoted by the second argument.
UNDEFINED( !foo ) is equivalent to NOT
DEFINED( !foo ).
Side Effects None.

Example DEFINED ( !var ) -> TRUE

DEFINED ( !array ) -> TRUE
DEFINED ( !array[1] )) -> TRUE
DEFINED ( !array , 1 ) -> TRUE
DEFINED ( !var) -> FALSE
UNDEFINED ( !array) -> TRUE
DEFINED ( !array , 3 ) -> FALSE
Errors None.

CREATED

Synopsis CREATED -> logical

Description Returns TRUE if the element has been created since the set
date.

Side Effects None.

Example CREATED -> TRUE

Errors None.

DELETED

Synopsis DELETED -> logical

Description Returns TRUE if the element has been deleted since the set
date.

© Copyright 1974 to current year. 9:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Side Effects None.

Example DELETED -> TRUE

Errors None.

EMPTY

Synopsis EMPTY(text) -> logical

Description Returns TRUE if text is a zero length string, else FALSE

Side Effects None.

Example EMPTY(‘’) -> TRUE

EMPTY(‘not empty’) -> FALSE
Errors None.

IFTRUE

Synopsis IFTrue(logical, anyA, anyB) -> logical

The first argument is a logical value or expression.

The second and third arguments may be of any type BUT
THEY MUST BE OF THE SAME TYPE.
Returns a value that is the SAME TYPE as the second and
third arguments.

Description Returns anyA if logical evaluates to TRUE, anyB if logical

evaluates to FALSE.
anyA and anyB can be IFTRUE functions themselves (as
long as they return consistent types) so IF constructs can be
nested.ds.

Side Effects None.

Example IFT (SPREF EQ /A3B/GC50, -> BLUE

'BLUE', 'RED'
->INSUL/THICK
iftrue (gwei gt 1tonne, /
INSUL/THICK, /INSUL/THIN)

Errors Normal number of argument errors and Mismatched second

and third arguments:
(2,497) TYPE MISMATCH: unmatched or illegal argument
type for IFTRUE function.

© Copyright 1974 to current year. 9:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

MATCHWILD

Synopsis MATCHW/ILD( text1, text2) -> logical

MATCHW/ILD( text1, text2, -> logical
text3)
MATCHW/ILD( text1, text2, -> logical
text3, text4)
Description Matches string text2 to string text1. If they are the same
then returns TRUE, else FALSE. text2 may contain wildcard
characters.
The defaults for wildcards are ‘*’ for any number of
characters, and ‘?’ for a single character.
With three arguments, the multiple wildcard character ‘*’ may
be redefined by text3.
With four arguments the single wildcard character ‘?’ may be
redefined by text4.

Side Effects None

Example MATCHW/ILD(’A big bottle of

beer’,’*big*’) -> TRUE
MATCHW/ILD(’A big bottle of
beer’,’??big*’) -> TRUE
MATCHW/ILD(’A big bottle of
beer’,’???*big*’) -> FALSE
MATCHW/ILD(’A big bottle of
beer’,’*big*beer’) -> TRUE
MATCHW/ILD(’** text’,’**!’,’!’) -> TRUE
Errors None.

© Copyright 1974 to current year. 9:9 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

MODIFIED

Synopsis
.-----------------------------------.
/ |
>- MODIFIED-(-+- attname -------*- DESCENDANTS --+-+-comma +-attname -’
| | | |
|- DESCENDANTS -. |- SIGNIFICANT --| |
| | | | |
|- SIGNIFICANT--| |- PRIMARY ----- | |
| | | | |
|- PRIMARY -----| |- OFFSPRING-----| |
| | | | |
|- OFFSPRING ---| ‘----------------’ |
| | |
| | |
| | |
‘---------------+--------------------+--+-- ) - OF - id Æ
|
‘-Æ

Description For sophisticated queries relating to modifications. Returns

TRUE if a modification has taken place.
Each attribute name may be followed by the following
qualifying keywords:
OFFSPRING, to check this element and members

SIGNIF, to check all elements for which this element

represents the significant one;
PRIMARY, check all elements for which this element
represents the primary one;

DESCENDANTS, this element and everything below

(descendants).
The ‘OF’ syntax may be used as for attributes.

The MODIFIED function or the GEOM, CATTEXT and

CATMOD pseudo-attributes.

The MODIFIED, DELETED and CREATED functions may go

anywhere within an Outfitting PML1 expression. i.e. after Q/
VAR and within collections

Side Effects None

Example Q MODIFIED() Returns TRUE if element has

changed at all since the
comparison date.
It will also return TRUE if the
element has been created
since the comparison date.

© Copyright 1974 to current year. 9:10 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Q MODIFIED(POS,ORI) Returns TRUE if POS or ORI

modified since the
comparison date.

Q MODIFIED(P1 POS) Returns TRUE if the position

of P1 has changed.

Q MODIFIED(GEOM Returns TRUE if any

DESCENDANTS geometry for item or any
descendants has changed

Q MODIFIED(PRIMARY) Returns TRUE if any element

for which this element is
primary, has changed.

Q MODIFIED() OF / Returns TRUE if /PIPE1 has

PIPE1 been modified since the
comparison date.

Q (BUIL OR
MODIFIED()OR
ELECREC OF NEXT )
Errors None.

The MODIFIED, DELETED and CREATED functions are not implemented within PML2
expressions.

UNSET

Synopsis UNSET(value) -> logical

Description Returns TRUE if value is unset, else FALSE. The value can
be of any data type including ARRAYS. Normally it will be an
Outfitting attribute.

Side Effects None.

Example UNSET( DESC ) TRUE where DESC is an

unset text attribute

UNSET(CRFA) FALSE where CRFA

contains unset reference
attributes

Errors None.

VLOGICAL
VLOGICAL is used for the late evaluation of variables.

Synopsis VLOGICAL ( variable_name )) -> logical

VLOGICAL ( variable_name , -> logical
number)

© Copyright 1974 to current year. 9:11 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Description With one argument, return the value of the scalar variable or
the value of the array variable element as a logical.
With two arguments, return the value of the element
corresponding to the index number as a logical.
The rules of conversion are:
TRUE for the strings ’T’, ’TR’, ’TRU’ or ’TRUE’ (case
insensitive) or any numeric value not equal to zero;
FALSE for the strings ’F’, ’FA’, ’FAL’, ’FALS’ or ’FALSE’ (case
insensitive) or a numeric value equal to zero.
Scalar variables may not be indexed. For example,
VTEXT(!var[1]) will return an error.
Array variables must have an index. For example, VTEXT
(!array) will return an error.
The value cannot be translated into a logical.
See also VTEXT, used for late evaluation when a text result
is required; and VVALUE, used for late evaluation when a
numeric result is required.

Side Effects If the scalar variable, the array variable, or the array variable
element does not exist, the result is undefined.

Example VLOG ( !array[1] ) -> TRUE

VLOG ( !array , 2 ) -> FALSE
Errors None.

9.2.3 Logical Array Expressions

Logical array expressions can contain:
• Outfitting attributes of type logical array. For example, LOGARR where LOGARR is a
UDA of type logical.
• Logical constants. The constants available are: TRUE, ON, YES for true; and FALSE,
OFF, NO for false.
• Logical operators. See Logical Operators.
• Logical functions. See Logical Functions.

9.3 Numeric (Real) Expressions

In Outfitting expressions, integers are treated as reals; they are fully interchangeable.
Numeric expressions can contain:
• Numbers, for example: 32, 10.1.
• Numbers can be given as integer exponents, for example: 10 exp 5, and 5 E 6.
• Values (numbers) can be qualified by units. This introduces dimensional analysis into
the expression. The valid units are any standard appropriate unit qualifiers for example
MM, M/etres, IN/ches, FT, FEET, kg, lb, kgf/m3, pascal. These may be preceded by
SQU/are, CUBIC, CUB/e to denote non-linear Values, or alternatively they can have

© Copyright 1974 to current year. 9:12 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

power indices appended. For example: 100 mm, 10 exp 5 cubic feet, 10m3,
20newton.m-2. Feet and inches can be shown as, for example, 10'6.
• Outfitting attributes of type number, for example: XLEN.
• Position, direction and orientation attributes which have a subscript to indicate which
part of the array is required. For example, POS[2] means the second element of the
POSITION attribute; that is, the northing. Note that position, direction and orientation
attributes without subscripts can only be used in number array expressions.
• The keyword PI (3.142).
• Numeric operators.
• Numeric functions.

9.3.1 Numeric (Real) Operators

The numeric operators available are:

Operator Comments

+ Addition.

- Subtraction.

* Multiplication.

/ Division.

9.3.2 ADD and SUBTRACT (+ and -)

The add and subtract functions available are

Synopsis number + number -> number

number - number -> number
+ number -> number
- number -> number
Description Add or subtract two numbers. They can also be used as
unary operators at the beginning of a parenthesised sub-
expression.

© Copyright 1974 to current year. 9:13 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Side Effects Units are consolidated across add and subtract and the
result is returned in current units of the physical quantity, for
example when current distance units are inches
q (1ft + 100mm) will return 15.9in
If only one value has a unit qualifier the other is assumed to
be in current units of that physical quantity for example:
q (1ft + 100 ) will return 112in
If the two values have conflicting units a warning is issued
and a value is returned with no units assuming both values
are in the database units of their respective quantities which
is mm and Kg in the example:
q (1ft + 1kg ) will return 305.8

Example 1 + 2 -> 3.0

1 - 2 -> 1.0
+ 1 -> 1.0
- 1 -> -1.0
Errors Floating point underflow.

9.3.3 MULTIPLY and DIVIDE (* and /)

The multiply and divide functions available are

Synopsis number * number -> number

number / number -> number
Description Multiply or divide two numbers. They can also be used as
unary operators at the beginning of a parenthesised sub-
expression. Numeric underflow is not considered to be an
error and neither is it flagged as a warning. The result
returned is zero.

Side Effects Units are consolidated across Multiply and Divide. The result
is returned in the current units of the physical quantity of the
result for example when current units of pressure are psi
then:
q (20kgf/ 1 cm2 ) will return 284.47PSI
If one value has no unit it is assumed to be a scaling factor.
This also applies to reciprocal physical quantities. For
example:
for (10 / XLEN) will return 2mm-1 when XLEN is 5mm

Example 2 * 3 -> 6.0

2 / 3 -> 0.666666666
Errors Divide by zero.

© Copyright 1974 to current year. 9:14 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

9.3.4 Numeric (Real) Functions

All referenced units are current units. The numeric functions available are:

Function Comments

ABS ( number1 ) Gives the absolute value of a number

ACOS ( number1 ) Gives the arc cosine of a number, in degrees.

ASIN ( number1 ) Gives the arc sine of a number, in degrees.

ATAN ( number1 ) Gives the arc tangent of a number, in degrees.

ATANT ( number1, number2 )

Gives the arc tangent of number1/number2, in degrees,
with the appropriate sign.

ALOG ( number1 ) Gives the exponential function (natural anti-log) of a

number.

ARRAY(pos or dir or ori)

Converts a position, direction or orientation value or
attribute into three numbers.

ARRAYSIZE ( variable-name )
Gives the size of an array variable.

ARRAYWIDTH( variable-name )
Gives the largest display width of any string in array
variable-name.

COMPONENT dir OF Gives the magnitude of a vector drawn from E0 N0 U0 to

pos2 pos2, projected in the direction dir1.

INT ( number1 ) Gives the truncated integer value of a number.

SIN ( number1 ) Gives the sine, cosine or tangent value of a number

(considered to be in current units of angle (degrees) if
value is unqualified).

COS ( number1 ) Gives the sine, cosine or tangent value of a number

(considered to be in current units of angle (degrees) if
value is unqualified).

TAN ( number1 ) Gives the sine, cosine or tangent value of a number

(considered to be in current units of angle (degrees) if
value is unqualified).

LENGTH ( text1 ) Gives the length of text1.

LOG ( number1 ) Gives the natural logarithm of a number.

© Copyright 1974 to current year. 9:15 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Function Comments

MATCH ( text1, Gives the position of the beginning of the leftmost

text2 ) occurrence of text2 in text1. If text2 does not occur in
text1, 0 is returned.

MAX ( number1, number2[ , number3 [. . .]]) )

Gives the maximum value of the arguments.

MIN ( number1, number2[ , number3 [. . .]]) )

Gives the minimum value of the arguments.

NEGATE Multiply a number by -1.0.

NINT ( number1 ) Gives the nearest integer to a real. NINT(N+0.5) is equal to

N+1 if N is positive or equal to zero, to N if N is negative.

OCCUR ( text1, Gives the number of times string text2 occurs in string
text2 ) text1.

REAL ( text1 ) Try to read a number at the beginning of text1.

POWER ( number1, number2 )

Gives the value of number1 raised to the power number2.

SQRT ( number1 ) Gives the square root of a number.

VVALUE ( variable-name )
Used for late evaluation of variables. Gives a real value.

ABS

Synopsis ABS ( number1 ) -> number

Description Returns the absolute value of a real.

Side Effects None.

Example ABS ( -3.2 ) -> 3.2

Errors None.

ACOS, ASIN, ATAN and ATANT - Inverse Trigonometric Functions

All these will return values in current angle units.

Synopsis ASIN ( number1 ) -> number

ACOS ( number1 ) -> number
ATAN ( number1 ) -> number
ATANT ( number1, number2 ) -> number

© Copyright 1974 to current year. 9:16 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Description Return the arc-cosine, arc-sine or arc-tangent of a number,

in degrees.
ATANT returns the arc-tangent of number1/number2 with
the appropriate sign. ATANT is useful where the second
value is near or equal to zero.
For example, (6 0 ATANT) will give the correct result of 90
degrees, but (6 0 D ATAN) will indicate an error when trying
to divide by zero.

Side Effects None.

Example ACOS ( 0.8660254 ) -> 30degrees

Errors Argument of ACOS or ASIN out of range [-1.0,+1.0]
ATANT (0.0,0.0) is undefined.

ALOG

Synopsis ALOG ( number1 ) -> number

Description Return the exponential function (natural anti-log) of a
number.

Side Effects Numeric underflow causes the result to be set to zero.

Example ALOG( -0.7 ) -> 0.4965853

Errors Floating point overflow.

ARRAY

Synopsis ARRAY(pos or dir or ori) -> number

Description Converts a position, direction or orientation value or attribute
into three numbers.

Side Effects None

Example ARRAY(e100 ) -> 100 0 0

Errors None.

ARRAYSIZE

Synopsis ARRAYSize ( variable-name ) -> number

Description Give the size of an array variable.

Side Effects If the array variable does not exist, the result is undefined.

© Copyright 1974 to current year. 9:17 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Example ARRAYSIZE(!array) -> 2.0

Errors The variable is a scalar variable and not an array variable.
The variable is an array variable element and not an array
variable.

ARRAYWIDTH

Synopsis ARRAYWIDTH ( variable-name ) -> number

Description Give the largest display with of any string in array
variable_name.

Side Effects None.

Example If an array contains the following values:

!ARRAY[1] ’Bread’
!ARRAY[2] ’is’
!ARRAY[3] ’for’
!ARRAY[4] ’life,’
!ARRAY[5] ’not’
!ARRAY[6] ’just’
!ARRAY[7] ’for’
!ARRAY[8] ’breakfast’
Then
ARRAYWIDTH(!ARRAY -> 9
i.e. the length of ’breakfast’.

Errors The variable is a scalar variable and not an array variable.

The variable is an array variable element and not an array
variable.

COMPONENT ... OF ...

Synopsis COMPonent dir1 OF pos2 -> text

Description Returns the magnitude of a vector drawn from E0 N0 U0 to
pos2, projected in the direction dir1.

Side Effects None.

Example COMP E 45 N of N 0 E 100 U 50 -> 70.710

Errors None.

© Copyright 1974 to current year. 9:18 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

DISTCONVERT

Synopsis DISTConvert ( number ) -> number

Description Returns a distance value cast from the input number.
The input value is converted to its database units (if it is a
physical quantity) and then cast to database units of distance
(i.e. mm) and presented in current units of distance.

Side Effects None.

Example When current distance units are mm

distc(1000) -> 1000mm
distc(10metre) -> 10000mm
distc( 5pascal) -> 5mm
distc (5atm) -> 506625mm
When current distance units are inch
distc(1000) -> 39.4in
distc(10metre) -> 393.7in
distc( 5pascal) -> 0.2in
distc (5atm) -> 19945.9in
Errors None.

SINE, COSINE and TANGENT - Trigonometric Functions

All these will accept values qualified by angle units. If no unit is supplied the value is
assumed to be in current angle units (usually degrees).

Synopsis SINe ( number1 ) -> number

COSine ( number1 ) -> number
TANgent ( number1 ) -> number
Description Return the sine, cosine or tangent value of a number
(considered to be in degrees).

Side Effects None.

Example COS ( 0.0 ) returns 1.0

TAN ( 45.0 degrees ) returns 1.0
TAN (0.785 radians) ) returns 0.9992
Errors Division by zero for TAN if the sine is (nearly) equal to zero.

© Copyright 1974 to current year. 9:19 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

INT

Synopsis INT ( number1 ) -> number

Description Return the truncated integer value of a number.

Side Effects None.

Example INT ( 1.6 ) -> 1.0

INT ( -23.7 ) -> -23.0
Errors Integer overflow.

LENGTH

Synopsis LENgth ( text1 ) -> number

Description Return the length of text1.

Side Effects None.

Example LENGTH ( ’abcdef’ ) -> 6.0

LENGTH ( ’’ ) -> 0.0
Errors None.

ALOG

Synopsis LOG ( number1 ) -> number

Description Return the natural logarithm of a number.

Side Effects None.

Example LOG( 3 ) -> 1 0986123

Errors Negative arguments.

MATCH

Synopsis MATch ( text1 , text2) -> number

Description Return the position of the beginning of the leftmost
occurrence of text2 in text1. If text2 does not occur in text1,
0 is returned.

Side Effects None.

Example MATCH ( ’abcdef’ , ’cd’ ) -> 3.0

MATCH ( ’abcdef’ , ’x’ ) -> 0.0
MATCH ( ’abcdef’ , ’’ ) -> 1.0
Errors None.

© Copyright 1974 to current year. 9:20 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

MAX and MIN

Synopsis MAX ( number1 , number2 [ , -> number

number3 [ ... ] ] )
MIN ( number1 , number2 [ , -> number
number3 [ ... ] ] )
Description Return the maximum or minimum value of the arguments.

Side Effects Values being evaluated are assumed to of a common physical

quantity.
If no unit qualifiers are supplied they are simply numbers.
If a physical quantity is defined the result will be in current
units of that quantity.

If unqualified numbers are mixed with unit values they are

assumed to be in the current units of that physical quantity.
If quantities are in mixed units they are all compared in
comparison to a standard unit.

If quantities are of different types of physical quantities a

warning is issued and the numeric result compares the values
in their database units.
Min and Max return a value with the same dimension as that
of their arguments.

Example MAX ( 1 , 3.4 ) -> 3.4

MIN ( 7.6 , -12.33 , 2.3 ) -> -12.33
MIN (7.6ft, 12.33inch, 1000mm ) -> 12.3
in (current distance units are inch)
MAX (7.6ft, 12.33inch, 1000 ) -> 1000in
(current distance units are inch)
MAX (7.6ft, 12.33inch, 1kg ) -> 2316.5
(database mm equivalent of 7.6ft)
Errors None.

NEGATE

Synopsis NEGate ( number1 ) -> number

Description Multiply a real by -1.0.

Side Effects None.

Example NEG ( 1 ) -> -1.0

Errors None.

© Copyright 1974 to current year. 9:21 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

NINT

Synopsis NINT ( number1 ) -> number

Description Return the nearest integer to a real. NINT(N+0.5) is equal
to N+1 if N is positive or equal to zero, to N if N is negative.

Side Effects None.

Example NINT ( 1.1 ) -> 1.0

NINT ( -23.7 ) -> -24.0
NINT ( 1.5 ) -> 2.0
NINT ( -11.5 ) -> -12.0
Errors Integer overflow.

OCCUR

Synopsis OCCUR(text1, text2) -> integer

Description Counts the number of times string text2 occurs in string

text1

Side Effects None.

Example OCCUR (’ABBACCBBBBBAB’, ’BB’) -> 3

OCCUR(’ZZZZZZZZZZZ’, ’A’) -> 0
Errors None.

REAL

Synopsis REAL ( text1 ) -> number

Description Try to read a real number at the beginning of text1.
Note that if text is in the form of an exponent, (-12E-1 in the
third example), there must be no spaces in it.
Note: this function was formerly called NUMBER.

Side Effects Numeric underflow causes the result to be set to zero.

If the text string contains units they are ignored and the value
only is returned.
If the test string contains text that is NOT a valid unit it will
generate an error.
If the text string is space separated from the number it is
completely ignored.

© Copyright 1974 to current year. 9:22 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Example REAL ( ’12.34’) -> 12.34

REAL ( ’ 7.23 E 3 meters’ ) -> 7.23
REAL ( ’ -12E-1 meters ’ ) -> -1.2
REAL (' 1200 fred ' ) -> 1200
REAL (' 1200fred ' ) -> returns an error
This will return the value of the number in the string
IGNORING any unit qualifier. The unit qualifier must still be a
valid unit qualifier. This is done so that output from $! And
VAR ! commands can still be accepted by the REAL function.

Note: The extension of these functions are NOT supported

in DARS as they require PML functionality.

Errors Unable to convert the text into a real number.

POWER

Synopsis POWer ( number1 , number2 ) -> real

Description Return the value of number1 raised to the power number2.

Side Effects If the value being raised to a power is that of a physical

quantity the result is also of a physical quantity.(in relevant
current units).
If the resultant quantity is non physical (e.g. by raising to a
fractional power, or an extreme power, a warning is given and
only the value of quantity is raised to the power.
If the power is a physical quantity this also gives a warning.

Example POWER ( -2 , 3 ) -> -8

POWER ( -2inch , 2 ) -> 4in2
POWER ( 2inch, 3.5 ) -> returns 11.314
with an error (i.e. 2**3.5)
Errors Floating point overflow.
Zero first argument and non-positive second argument
(effectively divide by zero).
Negative first argument and non-integer second argument.

SQRT

Synopsis SQrt ( number1 ) -> number

Description Return the square root of a real.

© Copyright 1974 to current year. 9:23 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Side Effects Units are consolidated across SQRT. The resultant value will
be in current units of that quantity.
If the resultant quantity has no recognised physical
dimension a warning is given and the value return will be a
number relating to the input value in database units.

Example SQRT ( 4 ) -> 2.0

SQRT ( 4inch2 ) -> 2.0inch
sqrt ( 4inch3 ) -> a warning and 256.02
which is sqrt (4*25.4mm)
Errors Negative argument.

VVALUE
VVALUE is used for the late evaluation of PML variables.

Synopsis VVALue( variable_name ) -> number

VVALue( variable_name , -> number
number )
Description With one argument, returns value of the scalar variable or
value of the array variable element as a number.
With two arguments, returns value of the element
corresponding to the index number as a number.
The value of the variable will be returned, irrespective of its
units.

This will return the value of the number in the string

IGNORING any unit qualifier. The unit qualifier must still be a
valid unit qualifier. This is done so that output from $! And
VAR ! commands can still be accepted by the VVAL function.

Note: The extension of these functions are NOT supported

in DARS as they require PML functionality.

Side Effects If the scalar variable, the array variable or the array variable
element does not exist, the result is undefined.

Example VVAL ( !array[1] ) -> 1.0

VVAL ( !array , 2 ) -> 0.0
Errors Scalar variable may not be indexed. For example, VTEXT
(!var[1]) ) will return an error.
Array variable must have an index. For example, VTEXT
( !array ) ) will return an error.
The string can not be converted to a number.

9.3.5 Real Arrays

Real array expressions can contain attributes of type real array, for example: DESP.

© Copyright 1974 to current year. 9:24 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

9.4 Units and Physical Quantity Attributes in

Expressions
In real expressions the dimension of the result is tracked using:
• The dimension of any attribute values used (e.g. XLEN, BANG, DENS, GVOL)
• The unit qualifiers of any values supplied
• The known result of any function (e.g. ASIN returns an angle, POW, SQRT return a
computed dimension, MIN/MAX that of their arguments etc.)
• The computed result of multiplication and division operation. (e.g. GWEI/GVOL is a
density)
• The need for consistency for addition and subtraction operations
If at any time a value with no dimension occurs where a value with a specific dimension is
needed then the value is taken to be one of that dimension in the current working units of
that dimension (e.g. mm for distances, degrees for angles). This will occur in addition and
subtraction operations, and arguments for typed functions (e.g. trigonometric).
Whenever a clash of physical quantity occurs then either a warning or an error will be raised
(e.g. SIN(25inch).
In all expressions and functions physical quantities are tracked and the result, wherever
possible is returned in the current units of the resultant physical quantity (dimension). If the
system cannot do this (e.g. the expression is not dimensionally sound, or the dimension
exceeds the scope which the system can track) then a warning is issued and a simple
numeric result is returned.
When a user enters a literal value then the type of physical quantity is not known and the
decision as to what it is determined to make it consistent with the context with respect to
other values in the expression. When it is finally determined the value is then taken to be in
the current units of that quantity. The method of this determination is normally
straightforward and is described in specific sections above.
The units for PML variables are also unknown. Where units are known and handled similarly
in expression.
To cope with ’unknown’ units each value remembers its original units internally. An attempt
is then made to allow for ’unknown’ units across operators and within functions. In general
the physical quantity of the result of a function, or expressions, is tracked by the system and
the resulting value is one of the resultant physical quantities. For example multiplying 3
distances together gives a result of a volume which will have units such as gallons, litres or
cubic ft etc.
On comparison, addition or subtraction of two values then if one has units and the other has
none (i.e. not a physical quantity) it is assumed to be the same sort of quantity as the other,
and in the current units of that quantity.
For example:
(XLEN GT 10).
If we are working in distance units of inches, it is known that XLEN is a distance value.
Internally the value is held in mm, but the units are held as INCH. The units for ’10’ are held
as unknown. On doing the comparison, the ’10’ is assumed to be inches and thus multiplied
by 25.4 to make sure that the comparison works as expected.
Special action is also taken to preserve the correct units across multiplication, division,
POWER and SQRT, as described in the sections above.

© Copyright 1974 to current year. 9:25 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

9.5 Using IDs in Expressions

IDs can be used in expressions. IDs can be any of the following:
• Element name, for example: /VESS1.
• Refno, for example: =23/456.
• Element type further up the hierarchy, for example: SITE.
• Number within member list, for example: 3.
• Type and number within member list, for example: BOX 3.
• NEXT, PREV for next, previous within current list. Optionally with a count and/or
element type, for example: NEXT 2 BOX, LAST CYL.
• NEXT, PREV MEMBER for next, previous within member list. Optionally with a count
and/or element type.
• If the element type given is only valid as a member then MEMBER is assumed. For
example, NEXT BOX at an EQUIPMENT will assume MEMBER.
• FIRST, LAST for first and last in current list. Optionally with a count and/or element
type.
• FIRST, LAST MEMBER for first and last in member list. If the element type given is only
valid as a member then MEMBER is assumed.
• END to navigate up from current list.
• END is similar to owner but not quite the same. For example, if the current element is a
GROUP MEMBER, and it has been reached from the GROUP then END will return to
the group but OWNE will go to the true owner.
• Attribute of type ref, for example: CREF
• SAME to mean last current element
• NULREF to mean =0/0
• CE for the current element
• ’OF’ may be used to nest the options indefinitely. For example:
SPEC OF SPREF OF FLAN 1 OF NEXT BRAN.
• This denotes the SPEC element owing the SELE element pointed to by the SPREF
attribute on the first FLANGE of the next BRANCH. ILEAVE TUBE, IARRIV TUBE,
HEAD TUBE, TAIL TUBE can be added to denote tube. For example:
HEAD TUBE OF /BRAN1.
• An error will occur if there is no implied tube for the element concerned.
ID arrays can also be used in expressions. For example, CRFA.
Note: Some of the ID syntax clashes with other types. To allow for this, an id expression
may always be preceded with the keyword ID. For example, ID 3 will mean the third
member of the current list rather than a number of value 3.

9.6 Positions, Directions and Orientations in

Expressions

9.6.1 Use Positions in Expressions

The basic ways of defining a position are:
• Position attribute plus optional WRT. For example:

© Copyright 1974 to current year. 9:26 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

POS OF /VESS1 WRT /* or P1 POS OF /CYL2

• Cartesian position. For example:
N 45 W 20000 U 1000
• Cartesian position from an element. For example:
N 1000 FROM /ATEST.
• Cartesian position from a ppoint. For example:
N 1000 FROM P1 OF /BOX2.
• Cartesian position from an attribute. For example:
N 1000 FROM POSS OF /SCTN1
• Any numeric value within a position may itself be an expression. For example: the
following is a valid position expression
N (DESP[1] + 10) E
The Cartesian position may optionally be followed by WRT to specify the axis system. See
WRT.

9.6.2 WRT
The WRT keyword is used to toggle between absolute and relative units.
When we specify an element (or attribute of an element) we are specifying an absolute point
in world space. The point can be given in world space or some other axis. Normally the
answer is required relative to the owner axis system and this is taken as the default. For
example:

Q POS $ will return the position of the current element

$ relatively to its owner.

Q POS OF /EQUIP1 $ will return the position of EQUIP1 relative to its

$ owner.

If we require the result in some other axis system then the WRT keyword is used. For
example:

Q POS WRT /* $.for the position in world coordinates.

When we specify a Cartesian coordinate we are dealing with a relative position.

For example, ’N 10’ is meaningless until we specify the axis system, or default to an axis
system.
Again we use WRT to do this, although it is important to note that in this case we are going
from a relative position to an absolute position (in the previous example WRT was used to
go from an absolute position to a relative one).
For example:

N 100 WRT /BOX1 $ specifies an absolute position in world space

$ which is N100 of /BOX1.

© Copyright 1974 to current year. 9:27 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

The default is that Cartesian coordinates are in the owning element’s axis system. This
absolute position can be expressed in different coordinate systems: the default is again the
owner’s axis system.

Note: The CONSTRUCT syntax uses the world as the default axis.

Example

Item Comments

A SITE at (0,0,0) With default (World) orientation

A ZONE at (100,0,0) With default (World) orientation

An EQUIPMENT at (100,0,0) With orientation ’N IS E

A BOX at (-100,0,0) With default (World) orientation

The result of Q (N 100 WRT /BOX1), will depend on the current element.

Location Result

World (300,100,0), in World coordinates.

Site (300,100,0) in World coordinates because the World

is the owner of the current element.

Zone (300,100,0) in World coordinates, because the Site

is the owner of the current element, and the Site
coordinates are the same as the World coordinates.

Equipment (200,100,0), which is the position relative to its

owner, the Zone.

Box (100,100,0) which is the position relative to its

owner, the Equipment.

WRT can be further qualified by FROM.

9.6.3 FROM
In some cases we require an offset from a fixed point, other than the position of an item. For
example, a point or attribute.
The FROM syntax is used for this. We may still use WRT in combination with FROM, but in
this case the WRT is only used to determine the axis direction and not the offset, since the
offset is specified by the FROM part.
Consider the following:

Item Comments

A SITE at (0,0,0) With default (World) orientation

A ZONE at (100,0,0) With default (World) orientation

© Copyright 1974 to current year. 9:28 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Item Comments

An EQUIPMENT at (100,0,0) With orientation ’N IS E

A BOX at (-100,0,0) With default (World) orientation

The result of Q (N 100 WRT /* FROM /BOX1), shown as ⊗ in , will depend on the
current element.

Location Result

World, Site, and Zone (200,200,0) since the offset of N100 is applied in
world axis rather than /BOX1 axis.

Equipment (100,200,0). Note: the default axis for the result is

the Zone.

Box (200,0,0), because the default axis for the result is

the Equipment.

The result of ’Q (N 100 WRT /BOX1 FROM /* ) is different:

Location Result

Site and Zone (100,0,0)

Equipment (0,0,0)

Box (0, -100, 0), because the axis for the result is the
Equipment.

The result of ’Q (N 100 FROM /* )’ is different yet again.

For this we cannot mark an absolute point on the diagram since the default WRT will vary
with the current element. In fact for the SITE, ZONE, EQUI the point ⊗ is marked in , and for
the BOX the point coincides with the ZONE.

Location Result

Site and Zone (0,100,0)

Equipment (-100,100,0), because the default result axis is the

Zone.

Box (0, -100, 0), because the axis for the result is the
Equipment.

9.6.4 Compare Positions

Two positions can be compared with EQ, NE, GT, LT, GE or LE. The pairs of coordinates are
only compared in the coordinate axes for which the two positions are defined. A position
attribute always has all three coordinates defined.

© Copyright 1974 to current year. 9:29 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

For positions entered by the user, only those coordinates which are given by the user are
defined. For example:

’N10U3’ $ only the Y and Z coordinates are defined,

$ while the X coordinate remains undefined

For the EQ operator, all the pairs of defined coordinates should be equal. For NE, only one
pair of defined coordinates need be different. For GT (LT,GE,LE), all the defined coordinates
of the first position should be greater than (less than, greater than or equal to, less than or
equal to) the defined coordinates of the second position. This means that GE is not the
opposite of LT and LE is not the opposite of GT.
If no coordinate of the two positions are defined for a common axis (e.g. ’N10’ and ’W4D7’),
the result of the comparison is undefined.

Examples

’POS EQ W1S2D3’ $ This evaluates to true only if POS of the current $

element is (-1,-2,-3).

’POS GT N10’ or ’N10 LE $ Only the second coordinate of POS is compared;

POS’
$ if it is greater than 10, then the result is true.

’E10N10 GT E0N0’ $ Is true because the inequality is verified for the X

$ and Y axis (both coordinates are undefined for
$ the Z axis, so it is ignored).

’E10N0 GT E0N0’ $ Is false because the Y components are different $

axes.

’E10N0 GT E0U100’ $ Is true. Although no comparison can be

$ performed n either the Y or the Z axis, because
$ the components are not present in both position
$ constants, the comparison is true in the X
$ component.

’N10 EQ W4D7’ $ Is undefined (no comparison is possible).

See also Precision of Comparisons, for tolerances in comparing numbers.

9.6.5 POLAR
The POLAR keyword allows positions to be defined in terms of a distance in a particular
direction from a point.

© Copyright 1974 to current year. 9:30 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

The syntax is:

POLAR dir DISTance expr -+- FROM -+- pos -----.

| | |
| ‘- point ---|
| |
‘--------------------+--->

If FROM is not specified the default is the origin of the owner.

For example:

POLAR N 45 E DIST 20M FROM U 10 M

POLAR AXES PL OF PREV DIST ( ABORE * 10 ) FR
OM PL OF PRE V

9.6.6 Direction
The basic ways of defining a direction are:
• Direction attribute plus optional WRT. For example,
HDIR OF /PIPE1 WRT /*
• Cartesian direction. For example,
N 45 W
• Cartesian direction WRT to an element.
• All Cartesian directions are returned in the axis of the owner of the current element. For
example:
(U WRT CE )
• will return the Z axis of the current element relative to its owner.
Q ( Z WRT /SCTN )
• will return the Z axis direction of /SCTN relative to the owner of the current element. For
example, if the result is required in world coordinates the current element must be the
World or a Site.
• FROM pos2 TO pos2. For example
FROM N 50 WRT CE TO N 100
• Keyword AXES followed by a p-point or pline.

© Copyright 1974 to current year. 9:31 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

• The CLOSEST keyword, which will find the closest element in a particular direction.
The syntax is:

>- CLOSEST type -+- WITH exp -.

| |
‘------------+- DIRECTION dir -+- EXTENT val -.
| |
‘--------------+--> cont

continued >-+- AFTER val -.

| |
‘-------------+- FROM ? -.
| |
‘----------+-->

• In the above graph the keywords are:

• EXTENT, which is how far to search in the direction specified, default 10M
• AFTER, or the distance along vector after which to start search, default 0M
• FROM, which specifies an alternative start point other than current element. This is of
particular use for a branch where you might want to specify the HPOS or TPOS.
• Examples are:
CLOSEST DIR E
CLOSEST BOX WITH ( PURP EQ ’FLOO’ ) DIR D WRT /
* EXTENT 20M
CLOSEST VALVE DIR N 45 U FROM E100 N200 U300
CLOSEST BRAN HANG AFTER 2M

9.6.7 Orientations
The basic ways of defining an orientation are:
• Orientation attribute plus optional WRT. For example:
ORI OF /BOX1 WRT /*
• Cartesian orientation. For example:
dir IS dir AND dir IS dir
• For example to set an orientation of an element to that of a section, rotated by 90
degrees use:
(E IS U WRT /SCTN1 AND N IS E WRT /SCTN1)
• The AXES keyword, which will allow you to use P-points to specify orientations.

© Copyright 1974 to current year. 9:32 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

• The syntax is:

----<---------.
/ |
>-- AXES --*--- PArrive ---|
| |
|--- PLeave ----|
| |
|--- PTail -----|
| |
|--- HHead -----|
| |
|--- HTail -----|
| |
‘--- PPOINT n --+-- OF - <gid> ---->

• An example is:
( AXES PLEAVE IS AXES PLEAVE OF PREV AND AXES P3 IS UP )
• This will orient a branch component, such as a valve, so that it is aligned with the
previous component and its P3 is up.
See also Compare Positions.

9.7 Text Expressions

Text expressions can contain the following:
• A text string, which must be enclosed in quotes. For example: ’FRED’.
• An Outfitting attribute of type text or word. For example: FUNC
• A single element of a word array attribute. For example: ELEL[2].
• Text operators
• Text functions

9.7.1 Text Operator

The text operator available is +, used for concatenation.

Synopsis text1 + text2 -> text -> text

Description Return the concatenation of two text strings.

Side Effects None.

Example ’no’ + ’space’ -> ’nospace’

Errors Text result too long.

© Copyright 1974 to current year. 9:33 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

9.7.2 Text Functions

The text functions available are:

AFTER

BEFORE

DIMENSIONOF, DIMOF

DIMWOOD

DISTANCE

LOWCASE, UPCASE

PART

REPLACE

STRING

SUBS, DSUBS

TRIM

UNITSOF

VTEXT

AFTER

Synopsis AFTER ( text1 , text2 ) -> text

Description Return the substring of text1 which is after the leftmost
occurrence of text2 in text1.
If text2 does not occur in text1, the null string is returned.

Side Effects None.

Example AFTER ( ’abcdef’ , ’cd’ ) ->’ef’

AFTER ( ’abcdef’ , ’x’ ) -> ’’
AFTER ( ’abcdef’ , ’’ ) -> ’abcdef’
Errors None.

BEFORE

Synopsis BEFORE ( text1 , text2 ) -> text

Description Return the substring of text1 which is before the leftmost
occurrence of text2 in text1. If text2 does not occur in text1,
text1 is returned.

Side Effects None.

© Copyright 1974 to current year. 9:34 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Example BEFORE ( ’abcdef’ , ’cd’ ) -> ’ab’

BEFORE ( ’abcdef’ , ’x’ ) -> ’’
BEFORE ( ’abcdef’ , ’’ ) -> ‘’
Errors None.

DIMENSIONOF, DIMOF

Synopsis DIMensionof or DIMOF -> text

(any real variable or
expression)

Description Evaluates the real expression and returns its physical

dimension as a text string. This is name of the dimension in
the table in Standard Units.
The argument can be a single real value (with or without unit
qualifier) or any real expression.

Side Effects None.

Example Dim (1) -> NONE

dim(1kg) -> Mass
dimof(1kg/m3) -> Density
dimensionof (1 curie) -> Radioactivity
dim (1joule / 1 day / sqrt (1 -> GENERIC
m4))
dim (1 newton / sqrt ( 1 m4) -> Pressure

Errors

DIMWOOD

Synopsis DIMWORD -> text

(any real variable or
expression)
Description Evaluates the real expression and returns its physical
dimension as a word string. This is HASH name of the
dimension in the table in Standard Units.
The argument can be a single real value (with or without
unit qualifier) or any real expression.

Side Effects None.

© Copyright 1974 to current year. 9:35 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Example Dimword (1) -> NONE

dimword (1curie) -> RADY
Dimword (1kg/5litre) -> DENS
dimword (1curie) -> RADY
dimword (1kg/5litre) -> DENS
dimword (1joule / 1 day / sqrt -> GENERIC
(1 m4))
dimword (1 newton / sqrt (1 -> PRESS
m4)
dim(1kg) -> Mass

Errors

DISTANCE

Synopsis DISTance ( number1 ) -> text

DISTance( number1, -> text
logical1, logical2,
logical3, number2,
logical4)
Description For the one-argument form, if the current distance units are
FINCH, text is the conversion of the decimal inches value
number1 into the format ’aa’bb.cc/dd’. Otherwise, text is
the STRING conversion of number1.

The six-argument form is more complex. The format is:

DIST/ANCE (distance, feet, usformat,
fraction, denom_or_dp, zeros)
where:
• distance is the numeric distance in inches that is to be
formatted.
• feet is a logical flag set to true if output is to be in feet
and inches and to false if output is to be in inches.
• usformat is a logical set to true if US format is to be
used or false if Outfitting format is to be used.

• fraction is a logical set to true if the fractional

component is to be output as a fraction or false if to be
output as a decimal denom_or_dp is a number
representing the largest denominator if fraction is
TRUE or representing the number of decimal places if
it is FALSE.
• zeros is a logical set to true if zeros are to be shown
when that component of the output has no value..

© Copyright 1974 to current year. 9:36 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Outfitting
For both US and Outfitting formats the following rules are
observed:
• If distance is negative, the first symbol is a minus sign.
• If feet is true and the distance is at least a foot, then
the number of feet is output next, followed by a single
quote (’). Only if zeros is true will the number of feet be
output as 0 for distances less than a foot. Otherwise
the feet will be omitted.

• If feet have been output, the inches will be at least two

characters wide. Numbers less than ten will be
preceded by a space if US format is being used or a
zero if Outfitting format is used. A zero will be output if
there are no whole inches.

• If no feet have been output and the distance is at least

an inch, then the number of inches is displayed but
without any preceding spaces. Only if zeros is true will
a 0 be output for distances of less than an inch.
• If inches have been output and fraction is true, these
will be followed by a decimal point (.).

• If fraction is TRUE and the number has a fractional

component, then the numerator and the denominator
are shown separated by a slash (/). This is then blank
padded up to the width that the largest numerator and
denominator would take.

• If fraction is FALSE and the number of decimal places

is greater than zero, then the decimal point (.) is
displayed followed by the remainder up to the
appropriate number of decimal places. If the number of
decimal places is 0 then the decimal point is not shown
either.
• If US format has been selected then the following
additional rules are observed on output:

• The (’) after the number of feet is followed by a dash

(-).
• The decimal point separating the inches from the
fraction is replaced by a space.

The inches and fraction of inches are followed by a double

quote(”).

Side Effects None.

© Copyright 1974 to current year. 9:37 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Example If the current distance units are FINCH:

DISTANCE ( 17.5 ) -> ’1’5.1/2’
Some examples, where the current distance units are feet
and inches:
DIST(34.5,TRUE,TRUE,TRUE,100,TRUE) -> 2’-10.1/2.
DIST(34.5,FALSE,TRUE,FALSE,1,TRUE) -> 34.5”
DIST(34.5,FALSE,TRUE,TRUE,4,FALSE) -> 34 1/2”
DIST(128.5,TRUE,FALSE,TRUE,2,TRUE) -> 10’08.1/2”

The following table shows sets of options that could have

been chosen and the format of the output produced for
different numbers. Blanks output by the system are
represented by underscores(_).

Distance Feet & Inch Feet & Inch Inches Inches Feet & Inch
US US US US Outfitting
Fraction Fraction Decimal Fraction Fraction
Denom 100 Denom 32 DP 1 Denom 2
Zeros No Zeros Zeros Denom 4 Zeros
No Zeros

128.5 10’-_8_1/2”___ 10’-_8_1/2”__ 128.5” 128_1/2” 10’08.1/2

120.0 10’-_0”_______ 10’-_0”______ 120.0” 120”____ 10’00____

11.5 0’-11_1/2”___ 11_1/2”__ 11.5” 11_1/2” 0’11.1/2

0.75 0’-_0_3/4”___ 3/4”__ 0.8” 3/4” 0’01____

0.0 0’-_0”_______ ______ 0.0” ____ 0’00____

-10.0 -0’-10”_______ -10”______ -10.0” -10”____ -0’10____

Errors The value is too big to be converted.

LOWCASE and UPCASE

Synopsis UPCase ( text1 ) -> text

LOWCase ( text1 ) -> text
Description Return an upper or lower case version of text1.

Side Effects None.

Example UPCASE ( ’False’) -> ’FALSE’

LOWCASE ( ’False’) -> ’false’
Errors None.

© Copyright 1974 to current year. 9:38 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

PART

Synopsis PART(text1, number1) -> text

PART(text1, number1 , -> text
text2)
Description With two arguments, returns the number1 component of
text1 assuming that text1 is split on any whitespace
characters. If number1 is negative, counting of components
starts from the right.
With three arguments, as above, but use text2 as the
separator on which splitting takes place.

If the user gives a part number higher than the number of

components in the string, the function returns an empty
string.

Side Effects None.

Example PART (’x-y-z’, 1, ’-’ -> ’x’

PART (’a b c d e’, 4-> ’d’
PART (’/PIPE45/B9’, -1, ’/’) -> ’B9’
PART(’aa bb cc’, 2) -> ’bb’
PART(’aa-bb-cc’,3,’-’) -> ’cc’
Errors None.

REPLACE

Synopsis REPLace (text1,text2,text3) -> text

REPLace(text1,text2,text3,i -> text
nt1)
REPLace(text1,text2,text2,i -> text
nt1,int2)
Description Replace search string text2 in input string text1 with
replacement string text3.
If int1 is given this specifies the first occurrence of text2 at
which to start replacement.
If int2 is given this specifies the number of replacements to
make. int1 and/or int2 may be negative to indicate that the
direction is backwards.

Side Effects None.

Example Three arguments:

REPLACE (’cat dog cat cat dog ’, ’cat’,
’dog’ ) -> ’dog dog dog dog dog’
All occurrences of ’cat’ are replaced with ’dog’.

© Copyright 1974 to current year. 9:39 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Four arguments: start occurrence given:

REPLACE (’cat dog cat cat cat dog’, ’cat’,
’dog’, 2) -> ’cat dog dog dog dog dog
All occurrence of ’cat’ from the second occurrence onwards
are replaced with ’dog’

REPLACE(’cat dog cat cat dog’ ,’cat’,

dog’, -2 -> ’dog dog dog cat dog’
All occurrences starting at the second occurrence from the
end of the string and moving backwards are replaced Note
that a negative fourth argument without a fifth argument
implies backwards mode.

Five arguments: start occurrence and number of

replacements given. Replace two occurrences of ’cat’ starting
at second occurrence:
REPLACE (’cat dog cat cat cat, ’cat’,
’dog’, 2,2) -> ’cat dog dog dog cat’
Replace two occurrences in backwards direction starting at
the second occurrence:
REPLACE (’cat dog cat cat cat’, ,’cat’,
’dog’, 2, -2) -> ’dog dog dog cat cat ’
Replace two occurrences in forwards direction starting at
second occurrence from the end of the string:
REPLACE (’cat cat cat cat dog’, ’cat’,
’dog’,-2,2) -> ’cat cat dog dog dog’
Replace two occurrences in backwards direction starting at
second occurrence from the end of the string.
REPLACE (’cat cat cat cat dog’,’cat’,
’dog’, -2, -2) -> ’cat dog dog cat dog’
The following examples all give the same result:
REPLACE(’cat1 cat2 cat3 cat4 cat5 cat6 cat7 cat8
cat9 cat10’, ’cat’, ’dog’, 4, 2)
REPLACE(’cat1 cat2 cat3 cat4 cat5 cat6 cat7 cat8
cat9 cat10’, ’cat’, ’dog’, 5, -2)
REPLACE(’cat1 cat2 cat3 cat4 cat5 cat6 cat7 cat8
cat9 cat10’, ’cat’, ’dog’,-6, -2)
REPLACE(’cat1 cat2 cat3 cat4 cat5 cat6 cat7 cat8
cat9 cat10’, ’cat’, ’dog’, -7, 2)

In each case, the output string is

’cat1 cat2 cat3 dog4 dog5 cat6 cat7 cat8
cat9 cat10’

© Copyright 1974 to current year. 9:40 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

If the replacement string text3 is a null string the required

number of occurrences of the search string text2 are
removed. For example:
REPLACE (’AAABBABZ’, ’B’, ’’) -> ’AAAAZ’
REPLACE (’AAABBABZ’, ’B’, ’’, -1, -1) ->
’AAABBAZ’

Errors If the input string text1 is a null string or an unset text attribute,
the input string text1 is returned unchanged. For example:
REPLACE (’’, ’A’,’B’) -> ’’
If the search string text2 is longer than the input string text1,
the input string text1 is returned unchanged. For example:
REPLACE(’AA’, ’AAAAA’ , ’B’) -> ’AA’

If no occurrence of the search string text2 is found, the input

string text1 is returned unchanged. For example:
REPLACE( ’AAAAAA’,’B’,’C’) -> ’AAAAAA
If required occurrence int1 is not found the input string text1 is
returned unchanged. For example:
REPLACE(’AAAAAA’, ’A’, ’B’, 10 ) -> ’AAAAAA’

If the number of replacements required int2 is greater than the

actual number of occurrence from the specified start
occurrence, replacements are made up to the end of the string
( or beginning in backwards mode). For example:
REPLACE(’AAAAAA’, ’A’, ’B’, 2, 8) ->
’ABBBBB’
REPLACE (’AAAAAA’, ’A’, ’B’, -3, 8) ->
’BBBBAA’

STRING

Synopsis STRing ( any scalar type ) -> text

STRing ( number , text1 ) -> text
STRing ( pos , text1 ) -> text
Description Turns a value into a text string.
With a single argument the STRING function can be applied
to the following scalar data types:
• Numeric
• Logical
• Id
• Position
• Direction
• Orientation

© Copyright 1974 to current year. 9:41 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

With only one argument, decimal places are output to give a

maximum of six significant figures. Trailing zeros are always
removed in this case.

With two arguments the data type may be either numeric

(scalar) or position or direction. With two arguments, convert
a number or position into a text string using the format
described by text1, which may take any of the values
between ’D0’ and ’D6’ (or ’d0’ and ’d6’), where the number
indicates the number of decimal places.

For numbers, STRING always outputs values as millimetres.

If unit conversion is needed then the DIST function should be
used. For positions, the current distance units are used.

Side Effects None.

Example STRING ( 1 ) -> ’1’

STRING ( 1 , ’D3’ ) -> ’1.000’
STRING ( 1.23456789 ) -> ’1.23457’
STRING(1.1230000) ->’1.123’
STRING ( 1.23456789 , ’D3’ ) -> ’1.235’
STRING (9*9 LT 100) -> ’TRUE’
STRING (OWN OF CE) -> ’/PIPE1’
STRING(POS) -> ’W1000 N20000 U18000’
STRING(POS, ’D4’ ) -> ’W10000.1234 N20000.1234
U18000.1234’
STRING(HDIR OF /PIPE1-1) -> ’D’
STRING(E 22.0125 N, ’D2’) -> ’E 22.01 N’
STRING (ORI OF NEXT) -> ’Y IS D AND Z IS U’

Errors

SUBSTRING

Synopsis SUBString ( text1 , -> text

number1 )
SUBString ( text1 , -> text
number1 , number2 )
Description With two arguments, return the substring of text1 beginning
at the position number1 to the end of text1.
With three arguments, return the substring of text1
beginning at the position number1 and of length number2. If
number1 is negative, then counting of characters starts from
the RHS of the input string. If number2 is negative, then
characters up to and including the start position are returned.

Side Effects None.

© Copyright 1974 to current year. 9:42 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Example SUBSTRING ( ’abcdef’ , 3 ) -> ’cdef’

SUBSTRING ( ’abcdef’ ,-3 ) -> ’abcd’
SUBSTRING ( ’abcdef’ , 3 , 2 ) -> ’cd’
SUBSTRING ( ’abcdef’ , -3, 2 ) -> ’de’
SUBSTRING ( ’abcdef’ , 3 , -2 ) -> ’bc’
SUBSTRING ( ’abcdef’ , 10 ) -> ’’
SUBSTRING ( ’abcdef’ , -10 , 2 ) -> ’ab’
Errors None.

TRIM

Synopsis TRIM ( text1 ) -> text

TRIM ( text1, text2 ) -> text
TRIM ( text1, text2, text3 ) -> text
Description When only one argument is supplied, TRIM removes all
spaces to the left (leading) and right (trailing) of text1 and
returns the answer in text.
When two arguments are supplied, text2 specifies where the
spaces should be removed from: either ’L’ or ’l’ for left, ’R’ or
’r’ for right, and ’M’ or ’m’ for multiple (where multiple
occurrences of blanks are squeezed to a single spaces) or
any combination of the three key letters. So the default is ’LR’
when this field is omitted.
When the third argument text3 is also supplied, this should
only be a single character which overrides the space
character as the character being trimmed.

Side Effects None.

Example TRIM ( ’ How now, brown cow ’, ’LRM’ ) ->

’How now, brown cow’
TRIM ( ’10.3000’, ’R’, ’0’ ) -> ’10.3’
Errors None.

© Copyright 1974 to current year. 9:43 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

UNITSOF

Synopsis UNITSOF or UNIT -> text

(any real variable or
expression)
Description Evaluates the real expression and returns its current units a
text string. This is standard unit qualifier that would be output
with the value when queried.
The argument can be a single real value (with or without unit
qualifier) or any real expression.

Side Effects None.

Example Note these are only possible results, depending on current

units
UNITOF (1) -> ‘’
UNITOF (1kg) -> lb
UNITOF (1kg/m3) -> lb/ft3
UNITOF (1 curie) -> curie
UNITOF (1joule / 1 day / sqrt (1 -> j/s/mm2
m4))
UNITOF (1 newton / sqrt (1 m4)) -> bar

Errors None.

VTEXT
VTEXT is used for the late evaluation of variables.

Synopsis VTEXT ( variable-name ) -> text

VTEXT ( variable-name , -> text
number )
Description With one argument, it gets the value of the scalar variable or
the value of the array variable element.
With two arguments, it gets the value of the element
corresponding to the index number.

The value is returned as a text string.

See also VLOGICAL used for late evaluation when a logical
result is required, and VVALUE used for late evaluation when
a numeric result is required.

Side Effects If the scalar variable, the array variable or the array variable
element does not exist, the result is undefined.

© Copyright 1974 to current year. 9:44 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Example VTEXT ( !var ) -> ’hello’

VTEXT ( !array[1] ) -> ’1.00’
VTEXT ( !array , 2 ) -> ’0.00’
Errors Errors Scalar variable may not be indexed (e.g. VTEXT
(!var[1]) ).
Array variable must have an index (e.g. VTEXT ( !array ) ).

9.8 Late Evaluation of Variables in Expressions

The functions VVALUE, VLOGICAL and VTEXT are used for late evaluation of PML
variables, that is, they enable you to specify PML variables in expressions which will not be
evaluated until the expression is evaluated. For example, when you are creating a report
template, you are actually creating a macro which will run when a report is generated. All
variables in a report template must therefore be preceded by a suitable late evaluation
operator; otherwise the system will try to substitute a value for the variable when it is
entered on the form. The difference between the operators is the type of output. VVALUE is
used to output a numeric value, VLOGICAL to output a logical variable and VTEXT to output
a text variable.

9.9 Attributes in Expressions

All attributes and pseudo-attributes may be recognised within expressions. Optionally they
may be followed by ’OF’ to denote a different element to the current one; e.g. POS OF /
VESS1. Brackets may be used to denote an element of an array, for example DESP[8 +
1] for the ninth value of DESP. Since syntax clashes are possible, the keyword ATTRIB
may be used to denote that an attribute follows. For example, ATTRIB E will denote the
pseudo-attribute EAST as opposed to the start of a position or direction. Attributes are
described in the Data Model Reference Manual.

9.10 Query Expressions

All expressions may be queried. Arrays are always concatenated into a single variable.
Imperial values are always output as inch to variables. This preserves maximum accuracy.
To output in FINCH, then the DISTANCE function must be used. In general expression do
not have to be enclosed in brackets, but to be sure that other queries are not picked up by
mistake then it is advisable to do so.
Particular queries that could lead to confusion are those available both outside and inside
expressions. These are:
• Q PPOINT n
• Q POS or cartesian position
• Q ORI or cartesian orientation
The functionality may vary between outside and inside expression queries. For example, ’Q
N 100 FROM /POSS’ is not valid. It must be entered as Q N 100 FROM /POSS ).

© Copyright 1974 to current year. 9:45 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

9.11 Precision of Comparisons

To allow for small losses of accuracy, the following tolerances are used.

Object Tolerance

Number Tolerance factor of 0.000001.

In other words, if the difference between two reals is not
greater than 0.000001* (maximum of the two values)
then the values are considered to be equal. e.g.
• (1.000001 GT 1) is FALSE as it considers
1.000001; and 1 to be equal;
• (1.000002 GT 1) is TRUE.

Position Considered to be equal if within 0.5 mm of one another.

Direction or Orientation Considered to be equal if values are within 0.005.

9.12 Undefined Values

In order to permit expressions like ((DIAM GT 200.0) OR (TYPE EQ ’BOX’)),
expressions must be able to cope with undefined values. Generally, applying an operator to
one or more undefined arguments has an undefined result.
Two exceptions are: the use of the AND operator with a false argument, will result in FALSE,
regardless of whether or not the remainder of the arguments are defined; and OR which
returns TRUE if any of its arguments is TRUE. For example, consider applying the above
expression when the current element is a box. DIAM is undefined; therefore (DIAM GT
200.0) is also undefined. However, (TYPE EQ ’BOX’) is certainly true and so the final
result of the whole expression evaluates to TRUE.
An undefined result occurs when:
• One of the operands or arguments of a function (except some cases of AND and OR) is
undefined.
• An attribute is unavailable for the corresponding element (e.g.’DIAM OF OWNER’
when the current element is a box).
• An element is undefined (e.g. ’OWNER’ when the current element is the WORLD).
• An attribute is unset (e.g. text attribute or UDA of length 0).
• A variable is undefined (e.g. ’VVAL(!ARC6)’ where !ARC6 has never been
initialised).
• Two position constants are compared with GT, GE, LT or LE and they have no common
coordinates (e.g. ’N10 EQ E5’).
• If the result of the whole expression is undefined, an error occurs.

9.13 Unset Values

A particular class of undefined values are unset values. The concept exists for attributes
which are valid for a given element, but for which no value has been assigned. Typically
these may be elements of an array, or ’word’ attributes. References of value =0/0 are also
treated as unset.

© Copyright 1974 to current year. 9:46 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

Unset values are propagated as for undefined values (except for Boolean operations- see
below). Undefined values take precedence over unset. There is a specific logical function
UNSET to test if a values is unset.
Across comparisons, unset values are not propagated, but are treated as follows:

Operator When Applied to an UNSET

EQ, GT, GE, LT, LE Results in FALSE.

NE Results in TRUE.

OR , AND Values are treated as FALSE.

For example, if DESP(2) and LVAL(3) are unset then:

(DESP(2) GT 99) -> False
(DESP(2) NE 33) -> True
(:LVAL(3) AND TRUE) -> False

© Copyright 1974 to current year. 9:47 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Expressions

© Copyright 1974 to current year. 9:48 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Rules to Define Attribute Settings

10 Rules to Define Attribute Settings

Rather than being set explicitly, the values of some types of attribute can be specified in
terms of rules; that is, expressions from which the attribute values can be evaluated. Rules
can be set only for attributes of the following types (including user-defined attributes): text,
scalar (integer, real or logical), position, orientation, direction; they cannot be set for
reference attributes. A static rule will change the attribute setting only when verified or
executed explicitly, whereas a dynamic rule will update the attribute setting whenever any
part of the expression changes (the default type is static).

10.1 Set Attribute Rules

Lets you set a rule for the value of a single named attribute. The rule may contain any valid
expression of the type applicable to the attribute setting.

Examples:

RULE SET ZLEN (XLEN + YLEN)

Sets rule that ZLEN of the current element is the sum of its XLEN and
YLEN values. The ZLEN will be updated to reflect changes to XLEN or
YLEN only when the rule is verified or executed (i.e. it is a static rule).

RULE SET XLEN DYNAM (YLEN + 2)

XLEN will be updated automatically whenever YLEN is changed.

RULE SET POS (N300 E400 U500) ON ALL BOX FOR /PUMP1

Sets rule for position attribute for all boxes in /PUMP1

RULE SET POS DYNAM (N100 FROM /BOX2 )

If BOX2 moves, the element with this attribute rule will move with it
automatically. (Note space between last character of element name
and closing parenthesis.)

Command Syntax:
>- RULE SET - attribute_name -+- STAtic --.
| |
|- DYNamic -|
| |
‘-----------+- <expre> -+- ON -.
| |
‘------+-.
|

© Copyright 1974 to current year. 10:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Rules to Define Attribute Settings

.------’
|
‘-+- <selatt> -.
| |
‘------------+->

Querying:

Q ATT Displays all attribute values and all rules for the current
element.

Q RULES Displays all rules for current element.

Q RUL OF XLEN Displays rule for XLEN attribute of current element.

10.2 Verify Attribute Rules

When a rule is verified, the expression held in the rule is evaluated and both the result of the
evaluation and the current value of the attribute are displayed.

Examples:

RULE VERIFY ALL

Verifies all rules for the current element.

RULE VER HEIG ON CYLI 1 FOR /PUMP1

Verifies rule for height attribute on first cylinder of /PUMP1.

Command Syntax:
>-- RULE VERify --+-- attribute_name --.
| |
‘-- ALL -------------+-- ON --.
| |
‘--------+-- <selatt> --.
| |
‘--------------+-->

10.3 Execute Attribute Rules

When a rule is executed, the expression held in the rule is evaluated and the value of the
attribute is replaced by the result of the evaluation.

Examples:

RULE EXECUTE :TEMP1

Executes rule for uda :TEMP1 for the current element.

RULE EXE ALL ON ALL BOX FOR /PUMP1

Executes all rules for all boxes owned by /PUMP1.

© Copyright 1974 to current year. 10:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Rules to Define Attribute Settings

Command Syntax:
>-- RULE EXEcute --+-- attribute_name --.
| |
‘-- ALL -------------+-- ON --.
| |
‘--------+-- <selatt> --.
| |
‘--------------+->

10.4 Delete Attribute Rules

Lets you delete one or more rules for the current element or for specified elements.

Examples:

RULE DELETE ALL

Deletes all rules for the current element.

RULE DEL ALL ON ALL FOR /PUMP1

Deletes all rules for all primitives owned by /PUMP1.

Command Syntax:
>-- RULE DELete --+-- attribute_name --.
| |
‘-- ALL -------------+-- ON --.
| |
‘--------+-- <selatt> --.
| |
‘--------------+-->

10.5 Rules for Arrays

Rules can be set for array attributes by using the NUM syntax, e.g. the following sets rules
for the first 3 design parameters.
RUL SET DESP NUM 1 ( DESP(1) OF /RULE-SCTN )
RUL SET DESP NUM 2 ( DESP(4) OF /RULE-SCTN )
RUL SET DESP NUM 3 ( 100 + DESP(2) OF PREV )

© Copyright 1974 to current year. 10:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Rules to Define Attribute Settings

© Copyright 1974 to current year. 10:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Collections

11 Collections

You can create an array which includes a number of elements which all satisfy specific
selection criteria, as defined by yourself. This is a useful way of collecting information on
particular elements. You use the syntax:

VAR !Array COLLECT selection criteria

!Array is the name of the array that will be created to contain the elements selected.
The following general criteria can be used to define the selection:
• A class of elements or element types.
• A logical expression to be satisfied at all selected elements.
• A physical volume in which all selected elements must lie.
• A point in the hierarchy below which all selected elements must lie.
All criteria (except for class) are optional.
Class is essentially a list of element types (or possibly of actual elements). This list can be
optionally qualified to indicate whether members should be included, or whether only ‘items’
(that is, the lowest level components in the hierarchy below a given element) should be
included.
For example:

Command Effect

ALL Selects all elements

ALL FRMW Selects all framework elements

ALL BRANCH MEMBERS Selects all piping components

ITEMS OF EQUI /VESS1 Selects all primitives below /VESS1

( /PIPE1 /PIPE2 ) Selects only /PIPE1 and /PIPE2.

The command:
VAR !PIPECOMPS COLLECT ALL BRANCH MEMBERS
Would create the array !PIPECOMPS and set it to contain the reference numbers of every
piping component in the MDB.
Logical expressions, which return TRUE or FALSE, can be used. They are most likely to be
used to check the value of an attribute for collection. The WITH or WHERE options introduce
the expression. For example:
VAR !LENGTHS COLLECT ALL WITH ( XLEN * YLEN 8 ZLEN GT 1000 )

© Copyright 1974 to current year. 11:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Collections

would collect all elements for which the attributes XLEN, YLEN and ZLEN match the criteria
in the array !LENGTHS.
A volume is defined by the WITHIN keyword. You can define the volume either in terms of
two diagonally opposite points of an enclosing box, or as a volume around an element (with
an optional clearance around the box which contains the element). For example:
VAR !VOLUME COLLECT ALL WITHIN W800N17000U0 TO W1400N13500U1200
collects all elements in the defined volume into the array !VOLUME.
VAR !P COLLECT ALL PIPE EXCLUSIVE WITHIN VOLUME /PUMP1 1500
collects all piping components within the volume defined by a box ‘drawn’ 1500 mm around
/PUMP1 and puts them into the array !P. The EXCLUSIVE keyword indicates that only the
chosen elements exclusively within the given volume are to be selected.
In Marine there are structural design data, termed DESIGN, and detailed design data,
termed PRODUCTION. These two sets of data represent the same model and occupy the
same 3D space. For a volumetric query you only want one of the sets of data returned.
These two options allow you to choose which set of data will be returned by the volumetric
query.

Example:

Q VOLUMEOPTION HULL DESIGN Returns DESIGN data

Q VOLUMEOPTION HULL PRODUCTION Returns PRODUCTION data

Command Syntax
>--- VOLUMEOPTION ---+--- HULL DESIGN ---.
| |
| |
‘- HULL PRODUCTION -+--- ON ---.
| |
| |
‘--- OFF ---+--->

Hierarchy criteria can be defined by the FOR keyword. It identifies a list of elements below
which all selected elements must occur. You can also include an exclusion list. For example:
VAR !BRANCH COLLECT ALL BRANCH MEMBERS FOR /PIPE1 /PIPE2
EXCLUDE BRAN 1 OF /PIPE2
You can append the results of such a collection to an existing array using the APPEND
keyword. For example:
VAR !BENDS APPEND COLLECT ALL ELBOWS
Would add the references for all elbows to the array !BENDS.
You can also overwrite elements in the array by specifying the first index in the array which
you want to be overwritten. The specified index, and the indexes following it, will be
overwritten by the results. For example:
VAR !BENDS[99] COLLECT ALL ELBOWS
Would place the reference for the first ELBOW selected at position 99 in the array !BENDS,
overwriting any existing data, and subsequent selections in the array elements that follow.

© Copyright 1974 to current year. 11:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Collections

If you specify more than one criteria, the specifications must be in the above order Some
more examples:

ALL Selects all elements

ALL FRMW Selects all framework elements
ALL BRANCH MEMBERS Selects all piping components
ITEMS OF EQUI /VESS1 Selects all primitives below /VESS1
( /PIPE1 /PIPE2 ) Selects just /PIPE1 and /PIPE2
ALL WITH (XLEN GT 1000 ) Selects all elements where XLEN is greater than
1000mm
ALL WITHIN W8000N17000U1000 TO W1400N13500U1200
Selects all elements within the defined volume
ALL PIPE WITHIN VOLUME /PIPE1 1500
Selects all piping elements within a volume defined as a
box drawn around /PIPE1, with a clearance of 1500mm
between the edges of /PIPE1 and the volume box.

Note: This selection mechanism is a very powerful tool for searching whole databases and
MDBs. However, if you're not careful the selection process could be very time
consuming and tie up a lot of computer resource. Therefore, it is important that
selection is performed as efficiently as possible. Marine tries to apply the above
criteria so that the fastest condition is applied first and the most expensive is left to
last.

Typically, the expression is the slowest condition to evaluate, so it is important to limit the
selection as much as possible. For instance, take the example which appeared above:
ENHANCE ALL WITH ( XLEN * YLEN * ZLEN GT 100 0 )
Since only BOXes (and NBOXes) meet this criterion it would be sensible to limit the search
by specifying an appropriate class:
ENHANCE ALL BOX WITH ( XLEN * YLEN * ZLEN GT 100 0 )
This cuts the time to execute the selection. This is because the selection system knows that
BOXes only occur in DESI databases. Therefore it does not search other types of database.
It also knows where boxes are in the hierarchy, and so does not search unnecessary
elements.
Even greater performance savings can be gained by explicitly limiting the elements which
have to be visited by the search:
ENHANCE ALL BOX WITH ( XLEN * YLEN * ZLEN GT 1000 ) FOR /*
By default, the entire MDB is searched. But by specifying a hierarchy criterion, the selection
time can be cut considerably.
Limiting the volume of the search also cuts the number of elements which have to be
checked. However, it should be noted that this criterion is applied by determining whether
element limit boxes fall within the specified volume, using the spatial map. This is a fast
approach, but is not meant to provide the same accuracy as is used in on line clashing.
VAR IPIPECOMPS COLLECT ALL BRANCH MEMBERS

© Copyright 1974 to current year. 11:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Collections

will set up the array IPIPECOMPS to contain the reference numbers of every piping
component in the MDB, e.g.
IPIPECOMPS [1] = '=20/302'
IPIPECOMPS [2] = '=20/303'
IPIPECOMPS [3] = '=20/304'
.
.
.
IPIPECOMPS [354] = '=25/510'
Every flange could then be extracted as follows:
VAR !FLANGES COLLECT (ALL FLANGES) FROM IPIPECOMPS
and then enhanced (highlighted):
ENHANCE ALL FROM !FLANGES
This could alternatively be performed in one step:
ENHANCE ALL FLANGES FROM IPIPECOMPS
Collections may be joined or concatenated by preceding the COLLECT keyword by
APPEND:
VAR !BENDS APPEND COLLECT ALL ELBOWS
Alternatively, the following:
VAR !LIST[99] COLLECT ALL SLCY
would place the reference of the first SLCY at position 99 in !LIST overwriting any data that
already exists at that and subsequent elements of the array.
If a selection contains elements of type TUBIng, then the collection describes it as the Leave
Tube of an existing database element:
VAR !TUBING COLLECT (ALL TUBI) FOR /*
Then !TUBING would contain something like the following:

!TUBING[1] 'IL TUB OF =20/302'

!TUBING[2] 'IL TUB OF =20/303'

The evaluate command allows an expression to be evaluation for all members of a

collection.
The syntax is:
VAR !variable EVALUATE expression For selection e.g. to get the description of all
equipment you can do:
var !cln collect all EQUI
var !name evaluate (description) for all from !cln
or
var !name evaluate (description) for all EQUI
The PML collection object can also be used as an alternative to the COLLECTION syntax.
This object is described in the Software Customisation Reference Manual.

© Copyright 1974 to current year. 11:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Collections

The name of a given prefix may be collected using the 'FROM TABLE NAME PREFIX'
option.
e.g.
COLLECT ALL FROM TABLE NAME PREFIX '/B'
This will find all names starting with 'B'.
The syntax may be used in conjunction with the standard options. E.g.
COLLECT ALL NOZZ WHERE (HEIGHT GT 100) FROM TABLE NAME
PREFIX '/B'
Some reference attributes index the attribute values. For these the indexed values can be
accessed directly using FROM TABLE XXXX VALUE YYYY, where XXX is the attribute
name and YYYY is the attribute match.
e.g.
VAR !COLL COLLECT ALL FROM TABLE SPRE VALUE /RF300/100G
This will return all elements with SPRE set to /RF300/100G.
The syntax may be used in conjunction with the standard options. E.g.
VAR !COLL COLLECT ALL FLAN FROM TABLE SPRE VALUE /RF300/
100G
Searching using indexes directly will be considerably faster than the standard searches. i.e.
VAR !COLL COLLECT ALL WHERE (SPRE EQ /RF300/100G)
The referenced attributes that are indexed are:

Catalogue DB

CATR Catalogue reference

PTRE Point set reference
GMRE geometry set reference
DTRE Data set reference
PSTR Structural Pline set reference
GSTR Structural geometry set reference
NGMR Negative geometry set reference
PAIREF Reference to a PAINT element
SRFTRE Reference to a SRFTRT element
SLOREF Pipe slope reference
INSURE Reference to a INSCMP element
Design DB

DOCREF Cross reference DOCU elements

© Copyright 1974 to current year. 11:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Collections

CATR Catalogue reference

SPRE Sprec reference
LSTU Tube spec
ISPE Insulation ref
HSTU Head tube spec
INRE Insulation reference
HCREF References to head connected branches
TCREF References to tail connected branches
GOBREF Hull Generating OBject REFerence
CONNRE Connections on nodes
POSREF Reference to point
MDSYSF model reference
ACCREF Access element reference
HDBREF Hull generic references
HTPREF Hull topological object model reference
SCHLNK Connectivity link to schematic item references
DESLNK Connectivity link to design model item
references
ENGLNK Connectivity link to design model item
references
PRODRF reference from outfitting element to hull
element
SPBREF Space boundary element reference
SPINRE Space inventory element reference
INPRTR Inside Paint Reference
OUPRTR Outside Paint Reference
ASSTAR Association target reference
MARKRF Cable Mark points
ASSTMP Assembly template reference
ROUTND Cable Preliminary route point
SLOREF Pipe slope reference

© Copyright 1974 to current year. 11:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Collections

To benefit from indexing the user must use the 'FROM TABLE' syntax in collections. This
syntax is similar the same as for system attributes.

For Text UDAS:

VAR !COLL COLLECT ALL for /* FROM TABLE :MYTEXTATT VALUE
'fred'
will find all elements in current DB with :MYTEXTATT set to 'fred'
VAR !COLL COLLECT ALL for /* FROM TABLE :MYTEXTATT PREFIX
'fred'
will find all elements in current DB with :MYTEXTATT starting with 'fred'

For Integer UDAS:

VAR !COLL COLLECT ALL FROM TABLE :MYATT VALUE 100
This will find all elements with a :MYATT of 100
VAR !COLL COLLECT ALL FROM TABLE :MYATT VALUE 100 TO 110
This will find all elements where :MYATT is between 100 and 110.

For Ref Attributes:

VAR !COLL COLLECT ALL for /* FROM TABLE :MYREFATT VALUE /
PIPE1
will find all elements in current DB with :MYREFATT set to /PIPE1
The new syntax may be combined with existing collection syntax. E.g.
VAR !COLL COLLECT ALL for /* FROM TABLE :MYREFATT VALUE /
PIPE1
Currently a collection can be restricted to a specific DB by navigating to a specific DB and
setting the scope of /*. Eg.
Q ALL … for /*
At 12.1 the DB name may be specified as part of the collection.
e.g.
VAR !COLL COLLECT ALL BOX FOR DB CTBATEST/DESI
or
VAR !COLL COLLECT ALL WHERE (SITE EQ /ATEST) FOR DB
CTBATEST/DESI FROM TABLE SPRE VALUE /RF300/100G
Or
VAR !COLL COLLECT ALL FOR DB CTBATEST/DESI FROM TABLE NAME
PREFIX '/B'

© Copyright 1974 to current year. 11:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Collections

© Copyright 1974 to current year. 11:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

12 Comparisons Across Sessions and Stamps

12.1 Change Management

You can query the following aspects of the history of modifications to the current database:
• When and by whom an element or attribute was last modified.
• A complete history of the sessions in which an element or attribute has been modified.
• Details of a given session.
• The session number for a given date.

12.1.1 Query the Last Modification to an Element or Attribute

Lets you query details of the most recent change to a given element or attribute.

Examples:

Q LASTMOD Gives date for last modification to current element.

Q SESSMOD Gives session number for last modification to current

element.

Q USERMOD Gives name of user who last modified current element.

Q LASTMOD HIER Gives dates for last modifications to current element and its
members.

Q LASTMOD XLEN Gives date for last modification to XLEN attribute of current
element.

Command Syntax:
Q --+-- LASTMod --.
| |
|-- SESSMod --|
| |
‘-- USERMod --+--+-- <selatt> --.
| | |
| ‘--------------+-- HIERarchy --.
| | |
| ‘---------------+-->
|
‘-- attribute_name -->

© Copyright 1974 to current year. 12:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

12.1.2 Query the Session History for an Element or Attribute

Lets you query modification history for a given attribute; i.e. session numbers during which
the attribute was modified.

Examples:

Q HISTORY DIAM Gives all sessions in which DIAM attribute was modified.

Note: HISTORY is an array type pseudo-attribute, so that qualifying positions may be

appended to query specific occurrences in the modification history. For example:

Q HISTORY[2] DIAM

gives second most recent session in which DIAM attribute was modified.

Note: History records are restricted to a maximum of 120 sessions.

Command Syntax:
Q HISTORY attribute_name

12.1.3 Query Details of a Specific Session

Lets you query details of any specific session. This is particularly useful to get details of
sessions listed by a HISTORY command.

Examples:

Q SESSCOMM 58 Gives comment text associated with session 58

Q SESSUSER 58 Gives name of user responsible for session 58.

Q SESSDATE 58 Gives date and time at which session 58 was created.

Note: All session queries are for the current DB.

Command Syntax:
Q --+-- SESSComment --.
| |
|-- SESSUser -----|
| |
‘-- SESSDate -----+-- integer -->

12.1.4 Query Session Number for a Given Time

Lets you query which session was current at a given time. (This is the inverse of the Q
SESSDATE option described in Query Details of a Specific Session.)

© Copyright 1974 to current year. 12:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

Examples:

Q SESSION ON 12:00 22 August 1995 Q SESSION ON 9 /9 /96

Time defaults to 23:59, so returns last session number

on given date.

Command Syntax:
Q SESSION ON <date>
where <date> is a standard syntax graph. Remember that <date> actually specifies a time
(to the nearest minute), so take care if you use any defaults here.

12.2 Comparison Date

It is only by comparing a drawing at two states or sessions that it is possible to determine
what has changed. Using the current state of the drawing as one state we must then
reference an earlier state in order to make the comparison. We do this by specifying a
Comparison Date (COMPDATE), that is, the drawing state at a time that we wish to use as a
baseline or datum.

12.2.1 Set the Comparison Date

You can enter a comparison date, either for the entire MDB or an individual DB. For
individual DBs, you can also enter a specific session number and extract number.

Examples:

SETCOMPDATE 31 March 2002

SETCOMPDATE STAMP /STAMP1

SETCOMPDATE NOW (will compare against the start values)

SETCOMPDATE FOR CTBATEST/DESI to session 99

SETCOMPDATE FOR CTBATEST/DESI to EXTRACT (this will compare

against the parent)

SETCOMPDATE FOR CTBATEST/DESI to CTBATEST/MASTER (CTBATEST/

MASTER must be up the extract hierarchy)

Command Syntax:
-SETCOMPDATE--|---date->
| --STAMP------name->
‘-FOR--DB--dbname--TO--|--date-->
|--Session -int-|--|-EXTRACT--|—- int---->
‘---------------‘ ‘--> |-- Dbname->
‘---------->

The ‘date’ subgraph takes the keyword NOW This in effect sets the comparison date to the
start of the session. This can be useful for querying the original value of an attribute.

© Copyright 1974 to current year. 12:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

The EXTRACT keyword sets the comparison to an extract DB. This extract DB must be one
further up the extract hierarchy. If the EXTRACT keyword is used by itself, the comparison is
set to the parent extract. Thus this enables you to find out what has been changed in this
extract.

12.2.2 Query the Comparison Date

The query will return the comparison session number or extract number for a DB.

Examples:

Q COMPDATE EXTRACT FOR DB CTBATEST/DESI to get extract

Q COMPDATE COMPDATE SESSION FOR DB CTBATEST/DESI to get session

Q COMPDATE DATE to get date

Q COMPDATE STAMP to get stamp

Note: Note that if a stamp is used to set the comparison date, this will set the comparison
session for each database within the stamp. It will also reset any comparison dates
set previously.

The query for the comparison date will only return a value if the COMPDATE was set using
a single date. Otherwise it will return ‘unset’. Similarly querying a stamp is only valid if the
COMPDATE was set using a stamp.

Command Syntax:
Q ----------|-COMPDATE-|--SESSION--|--FOR---dbname--->
VAR -vname--‘ |—EXTRACT---´
|----DATE--------->
‘----STAMP-------->

12.2.3 MODIFIED Function

For the more sophisticated queries relating to modifications, the MODIFIED function tells
you if the given element has changed since the comparison date. This function is not
implemented within PML2 expressions.

Examples:
To return true if element has changed at all since the comparison date use:
Q MODIFIED()
It will also return true if the element has been created since the
comparison date.
To return true if POS or ORI have been modified since the comparison date use:
Q MODIFIED(POS,ORI)
To return true if the position of P1 has changed use.
Q MODIFIED(P1 POS)

© Copyright 1974 to current year. 12:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

Examples:
You may follow each attribute name with the qualifying keywords below.
To check this element and members use:
OFFSPRING
To check all elements for which this element represents the significant one use:
SIGNIF
To check all elements for which this element represents the primary one use:
PRIMARY
To check this element and everything below (descendants):
DESCENDANTS
You can use the keywords below on their own to test for any attribute change. e.g. to
return true if any geometry for item or any descendants have changed use:
Q MODIFIED(GEOM DESCENDANTS)
To return true if any element for which this element is primary, has changed use:
Q MODIFIED(PRIMARY)
You may use the ‘OF’ syntax as for attributes. e.g. to return true if /PIPE1 has been
modified since the comparison date use:
Q MODIFIED() OF /PIPE1
You may put the new functions anywhere within an Outfitting PML1 expression. i.e. after
Q/Var and within collections. e.g.
Q (BUIL OR MODIFIED() OR ELECREC OF NEXT )

Command Syntax:
.------------------------------------.
/ |
>-MODIFIED-(-+--attname-------|--*--DESCENDANTS--+--+-comma--+--attname--´
| | | |
|--DESCENDANTS--. |-- SIGNIFICANT-| |
| | | | |
|--SIGNIFICANT--| |--PRIMARY----- | |
| | | | |
|--PRIMARY------| |--MEMBERS------| |
| | | | |
|--MEMBERS------| ‘---------------‘ |
| | |
| | |
| | |
‘---------------+----------------------+--+--) ---OF --id-->
|
‘-->

© Copyright 1974 to current year. 12:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

12.2.4 CREATED Function

Determine if an element has changed since the Comparison Date. The functionality of
CREATED() is identical to using the pseudo attribute ELECREC.

Examples:
Q ( CREATED() )

12.2.5 DELETED Function

Determine if an element has been deleted since the Comparison Date. The functionality of
DELETED() is identical to using the pseudo attribute ELEDELC.

Examples:

Q ( DELETED() )- returns deleted since comparison date

However if the element has been deleted then you cannot have navigated to it in the first
place, hence DELETED() by itself will always be true. There are two ways around this.

Either include the element’s reference number e.g.:

Q (DELETED() of =15752/234 )

Or use it as part of the 'old' syntax. e.g.:

Q OLD (DELETED() of /VESS2)

12.2.6 GEOM, CATTEXT, and CATMOD Special Attributes

There are three new special attributes ‘GEOM’, ‘CATTEXT’, and CATMOD (previously
called ‘CATA’).

GEOM Special Attribute

The GEOM attribute returns true if any aspect of the evaluated geometry has changed.
The definition of evaluated geometry change includes:
• Any dimension of a primitive has changed
• Any ppoint changes
• Pos/ori change
The level information used to determine the geometry is set by the ‘REPRE MASS’
command. The ‘REPRE MASS’ command is also available in ISODRAFT.

CATTEXT Special Attribute

This will return true if any part of the evaluated detail or material text has changed.

CATMOD Special Attribute

Special attribute CATMOD will return true if any value in the catalogue has changed. i.e.
• SPREF
• Changes to SPCO element
• Changes to COMP element

© Copyright 1974 to current year. 12:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

• Changes to any PTSE, GMSE, ppoint, geometry elements

• Changes to any dataset elements
• Changes in DTEXT,MTEXT elements
Note that there is a subtle difference between CATMOD and the other two: the
CATTEXT and GEOM keywords work on the evaluated values.
Thus it is possible that the geometry element has changed but the GEOM keyword returns
false, e.g. a UDA value may have changed, but this has no effect on the evaluated
geometry.
The CATMOD keyword on the other hand will return true for any change.
You can use the CATMOD keyword on any element. It will return ‘false’ if the element does
not have a SPREF or CATREF reference pointing into the catalogue database. It will return
‘true’ if the element has a SPREF or CATREF attribute and either (a) this reference attribute
has itself changed in value or (b) the catalogue element pointed at, or any catalogue
element owned by or pointed at by this element, either directly or indirectly, has changed in
any way.
The exception is that elements pointed at by UDA’s are not compared, although the value of
the UDA itself is checked. Thus if a reference valued UDA has been changed then this will
count as a change, but if only the element pointed at has changed, then this will not count.

12.2.7 Query Any Attribute at the Comparison Date

The ‘OLD’ syntax enables you to query any attribute at the comparison date.
You can use the syntax in front of any expression or attribute. The whole expression will
then be evaluated at the comparison date. e.g.
Q OLD XLEN
If a name is given, the name will be for the item at the comparison date, not now. Thus
values of deleted items may be accessed. e.g.
Q OLD REF OF /OLDPIPE
Where /OLDPIPE no longer exists.
The ‘OLD’ syntax may also be used after ‘VAR’. This includes collections e.g.
VAR !PIPES OLD COLLECT ALL PIPES
This would return a collection of all PIPES at the old version.
If the functions MODIFIED, CREATED, DELETED are used on the old version then the
comparison is made with the current version.
For example to get a list of deleted pipes between the comparison date and now, then the
following collection could be used. e.g.:
VAR !PIPES OLD COLLECT ALL PIPES WITH ( DELETED() )
There is also a pseudo attribute, DSESS. that returns the session number when an element
was deleted. i.e. having got the deleted PIPES from the previous query, we can now find out
when they were deleted.

© Copyright 1974 to current year. 12:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

12.3 Compare Database Changes

12.3.1 Compare Database States at Different Times

You can compare details of your current database settings with the corresponding settings
at a specified earlier time and generate a report listing all differences. The types of change
reported include:
• Creation and deletion of elements.
• Changes to the attribute settings of elements.
• Changes in the list order for BRANCH, POGON, DRAWI and BOUND elements.

Keywords:

DIFFERENCE SINCE

Description:
Lets you report all changes to one or more specified database elements since an earlier
version of that database. The output is in the form of a report listing all elements and
attributes which have changed, with their old and new values. The report can be sent to a
file by using the ALPHA FILE or ALPHA LOG commands.

Note: The database states are compared between SAVEWORK operations. For example,
if you last saved your design changes at 9:30 and ask for a comparison since 10:00,
the current settings will be compared with those at 9:30.

Examples:

DIFFERENCE ALL BRANCH FOR /ATEST SINCE 21 JANUARY

DIFF CE SINCE 10:00 Assumes current day.

DIFF /ZONE Compares current settings with those at your

last SAVEWORK command.

DIFF SITE SINCE SESSION 66 Compares current settings with those at the end
of session 66 of the current database.

Command Syntax:
>- DIFFerence <selele> SINCE -+- <date/time> -+-----------------------.
| | |
|- LATEST ------| |
| | |
|--SESSION nn --| |
| | |
‘---------------+- EXTRACT -+- extname -|
| |
‘- extno ---+->

© Copyright 1974 to current year. 12:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

12.3.2 Model Changes

Model Changes provides a mechanism for exploring change and highlighting changed
elements in the 3D Graphical View. Select Query > Model Changes from the main menu to
display the Model Changes window.

Note: The previous DB Changes appware is now available by selecting Utilities > DB
Listing.

The Model Changes window has two vertically split panes. The top pane contains a Design
Explorer while the lower split contains the following tabs.
• Model Timeline
• Stamps
• Element History
• Key.

© Copyright 1974 to current year. 12:9 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

The Element History and Key panes are for information only while the Model Timeline
and Stamps panes allow the selection of a session or stamp upon which to base the display
of changes in the explorer pane, and optional highlighting of changed elements in the 3D
graphical view. Once a session or stamp is selected changes can be highlighted by
Refresh.

Model Timeline
Clicking Model Timeline displays every session for every Design database in the current
MDB, ordered chronologically.

Stamps
Clicking Stamps lists details of every stamp that records session numbers for all of the
Design databases in the MDB.

© Copyright 1974 to current year. 12:10 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

Element History
Clicking Element History lists the details of every database session in which the selected
Current Element has changed.

Key
Clicking Key displays a static tree control with images, colour and text explaining explorer
annotations used to display changes in the explorer control.

© Copyright 1974 to current year. 12:11 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

Either of two modes of change reporting can be selected from the drop-down menu
according to the current selection.

All Changes Since displays only changes that have been made in all databases in the
MDB between, but not including, the selected session or stamp, and the current state of the
model but does include any unsaved changes.

Note: For large models this change analysis can take some time.

Only Changes At displays only the changes that were made when the highlighted session
was created which, may have been a savework or as the result of an extract operation, such
as a flush or refresh, as indicated by the Reason column in the Model Timeline table.
Note Highlighting in the explorer pane and in the 3D graphical view is always with reference
to the current state of the model; it is possible that no changes from a previous session will
be visible, for example if all changes were made to elements that have since been deleted.
When Refresh is clicked and the change analysis operation is complete the explorer tree is
updated with annotations which highlight the changed elements in detail.
Clicking Highlight has an immediate effect on all 3D graphical views if changes are
currently displayed in the explorer tree. Any changed elements that have graphical

© Copyright 1974 to current year. 12:12 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

representation and are in the drawlist for any active view are highlighted in colour. This uses
the same customisable colour used by the Highlight element function available via right-
click menu in the standard Design Explorer. Unchecking Highlight returns the graphical
display to normal colouring.
All panes of the Model Changes are updated and explorer annotations and 3D graphical
highlighting are reset in the following circumstances:
• further element changes
• savework, getwork, and refresh
• user or MDB switch
Following any of these operations Refresh must be clicked again in order to update the
change highlighting.

12.4 Revert Elements

Revert allows you to directly Revert an element or hierarchy of elements to a previous state.
>- REVert -+- ELEment ---.
| |
`- HIERarchy -+- <selele> -+- AT -----.
| |
`- BEFore -+- <comparison> ->

Where the <comparison> syntax is similar to that following the SINCE keyword in both of
the existing DIFFERENCE and OUTPUT CHANGES commands.
-->-+- <date/time> -+-----------------------.
| | |
|- LATEST ------| |
| | |
|---------------+- EXTRACT -+-----------|
| | |
| |- extno ---+
| | |
| '- extname -+
| |
`- STAMP - <name> ---------------------+->

If the BEFORE clause is used the elements will be reverted to the state they had before the
session that is selected by the historical specification.

Examples of the Revert Command:

REVERT HIER /EQUIP AT LATEST
Reverts the element hierarchy rooted at /EQUIP to latest saved session.
REVERT HIER /EQUIP BEFORE LATEST
Reverts the hierarchy rooted at /EQUIP to the state it had before the latest saved
session.
REVERT ELE /E1301 AT 20:16 26 / 3 / 2010
Reverts the single element /E1301 to the state it had on the given time and date.
REVERT HIER /PIPES AT STAMP /StampMilestone7
Reverts the hierarchy rooted at /PIPES to the state it had at the named stamp.
REVERT HIER CE AT EXTRACT

© Copyright 1974 to current year. 12:13 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Comparisons Across Sessions and Stamps

Reverts the hierarchy rooted at the current element to its state in the parent extract.
The revert command makes sure that every element creation, include, reorder and deletion,
and every attribute change is allowed before proceeding. If any of these tests fail, for
example due to legality checks, read-only databases or DACs, then the entire revert
operation is cancelled and the following error is generated.
(43,615) Cannot Revert elements. No changes have been made.
In this case a series of warning messages is written to the console indicating the causes of
the error, for example:
DAC prevents deletion of element /DELETE_UDET_B
DAC prevents creation of element =15752/1363
DAC prevents modification of attribute Built on element /
MODIFY_B_VESS1
Element locks do not prevent a revert operation if those elements were unlocked in the
previous state.

Note: this command is not directly related to the REVERT <database name> command
available in the Admin module. This command allows an entire database to be
reverted to the state it had at a previous session.

© Copyright 1974 to current year. 12:14 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

13 Output Syntax

The OUTPUT command is used to scan specified parts of the Project DBs and to output, in
the form of a structured list, the data held there. The output is presented in such a way that
it is both easy to interpret and suitable for reinput as design data to appropriate Outfitting
modules.
Output takes the form of macro files whose contents precisely recreate the hierarchical
structure of the elements currently listed in the selected DBs, including the settings of all of
their attributes. Facilities are provided for controlling the precise layout of the output files
and the amount of information presented. Element cross-referencing (indexing) is also
available, to assist in interpreting the data. The macro is sent to a file by using the standard
ALPHA FILE or ALPHA LOG commands.
You may view the output lists directly on your screen, or you may send them to text files for
subsequent inspection or printing. The latter files can be read back as input to say a
different constructor module form that from which the data was derived, either in the same
or in a different project. You can include only the elements which have been changed since
a specified time (i.e. those elements which would be listed by the DIFFERENCE command).
The macro files created can be used for the following purposes:
• To copy part of a design.
• To modify part of a design. The output macro file containing the relevant design data
can be edited using operating system facilities and can then be reinput to the
appropriate DB. You could use this method, for example, to change Nozzle Catalogue
References in a pipework subsection.
• To transfer part of a design from one DB to another or from one project to another.
• To archive all or part of the Project DB. Listings may be read in at any future revision of
Outfitting, making such as archive more secure in some respects than the Project DB
itself.
• To give you a quick-reference listing of the DB contents to provide a rapid answer to a
specific question (such as where a particular element is stored in the hierarchy).
The output is generated in three stages:
1. Any elements which were originally locked are unlocked. Element deletions, name
changes and type changes are output. Note that reordering or insertion of elements in
their owner’s members list is treated as deletion followed by creation, so that Refno
attribute settings may be changed.
2. Newly created elements and all standard attribute settings are output.
3. Reference attribute settings and rules are output. Elements which were originally
locked are relocked and GADD commands are included if any elements were included
in Groups.

© Copyright 1974 to current year. 13:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

13.1 General Features of Output Lists

Output by default is in a format suitable for direct reinput to most Outfitting implementations.
You may, however, modify several aspects of the output format if necessary for specific
purposes.
To ensure the successful reinput of data, macro files output have the following features:
• Attributes and other data which are output for information only, and which cannot be
reinput (such as the time and date of the report, the element owners, etc.) are enclosed
by the delimiter codes $ (and $). They are, in consequence, treated as comments on
reinput and are ignored as data.
• Cross-reference attributes (for example HREF, CREF) are enclosed between the
comment delimiters $ (and $) where they occur with their elements, and are output
again collectively at the end of the list. This ensures that all elements which are
referenced in the list are present in the database before any references to them are set.
• An END command is output after each new element has been created. This moves the
Current Element pointer up to its original level in the hierarchy, ensuring that those
elements (such as BOX) which may appear at two different levels in the hierarchy are
reinput at the correct level.
• The single apostrophe character ‘ is output as ‘ ‘ when it occurs within text.
• The units of measurement used to output dimensional and positional attributes are,
where possible, appropriate to the input requirements of the modules in which they will
be used. For example, the Bolting attributes BDIA and LENG are always in millimetres,
so as to be consistent with the input to PARAGON.
• Millimetre coordinates and dimensions are normally listed to three decimal plates (i.e.
to an accuracy of 0.001mm), and so a previous list may be used to check design data
which has been created with a lower precision in another module. This could be useful,
for example, in assessing a misalignment reported by a data consistency check.
Note: Numerical accuracy deteriorates after six significant figures. The number of decimal
places output can be varied using the PRECISION command.

• ORI and ANGLE attributes are listed to four decimal plates. Orientations are output as
angles using the ORIANGLE attribute to give more accurate output, and (as comment
text) in XYZENU axis form. For example
AT W17246.099 N12125.000 U4130.000 ORIA 180.000 -75.000
90.000 $ ( ORI Y IS E AND Z IS N 15.000 D $)
• Nozzles are treated somewhat differently to other elements in that their positions and
orientations are output twice; first in Owner coordinates (for normal reinput), and
secondly in Zone coordinates. The latter data enables them to be checked directly
against Branch head and Tail positions, which are always stored in Zone coordinates.
(Examples are given later in this section).
Note: The lengths of output lists are normally minimised by omitting all attributes which
have the Outfitting default values, since the use of such values in input data
generally has no effect. The omission of data in this way can, however, cause
problems under some circumstances, and so may be overridden if required.

13.2 Principles and Limitations

Output listing can be used as a convenient medium for transferring data from one project to
another or from one computer to another. Such lists may also be useful when a Project DB
is upgraded to a newly released version of Outfitting. This chapter summaries the
procedures which you might follow when carrying out such tasks.

© Copyright 1974 to current year. 13:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

The design to be transferred can include some of all of the following major categories of
data:
• The Project Configuration
• Catalogue items, including Bolt Tables, Connection Compatibility Tables, etc.
• Material Properties
• Component Specifications
• Three-dimensional Design layouts
• User-Defined Attributes (UDAs)
• Drawing Libraries and Drawings
To transfer a complete Project you would normally use the ADMIN Module. You would
usually use output lists only for transferring specific parts of the Catalogue, Design, Drawing
(PADD) or Dictionary (UDA) data.
Output cannot be used to transfer the Project Configuration; you must use ADMIN to output
the configuration in a suitable format for transfer. This operation is included in this chapter
simply to show where it fits into the overall operation.
Before any transfer takes place, you should consolidate the Project DB by removing all DB
copies, leaving only the Master versions. You should also ensure that individual DBs have
consistent and unique contents, thus avoiding, for example, an attempt to transfer two
similar (but not identical) copies of the Catalogue.
When an Outfit listing is to be input to a Project DB, it is essential that all elements which are
referred to in the list, but which are specified outside the list, have already been loaded into
that DB. After the transfer of data to a new Project, the element reference numbers will
almost certainly be different from the original and no reliance should be placed on their
meaning. As a general rule, therefore, all items which are reference (such as Catalogue
Components, Specification Components, etc.) should be named.
Note particularly that, if you use Outfit to transfer data from Design, Catalogue or Drawing
(PADD) DBs which include User-defined Attributes (UDAs), the reloading process will fail if
there are any UDSs for which definitions are not available in the target Project of if the
definition in the target project is inconsistent with the definition in the source project. For this
reason, UDA definitions held in the Dictionary DBs should be transferred first.

Note: Cross-references between Branches and attached Nozzles may be lost during the
transfer process. In this case, they must be reset in the newly created DB.

Note: Datal listings containing Hull elements should not be manually edited. Hull elements
contain binary data and manual editing may break the consistency of the hull data
model.

13.3 OUTPUT Command

The following options are available:

OUTPUT CHANGES
Incorporates INCLUDE command for named items. The item must be named in both the
current and referenced session. For unnamed items, a DELETE, CREATE sequence is
followed.

© Copyright 1974 to current year. 13:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

OUTPUT REVERSE CHANGES

This is the opposite of the current OUTPUT CHANGES command: that is the output is
generated can be read back in to restore the given data to how it was at the given session.

OUTPUT CHANGES SINCE

Lets you output all changes to one or more specified database elements since an earlier
version of that database. The output is in the form of a macro which can recreate the
changes when run on, say, a copy of the original DB. The macro is sent to a file by using the
standard ALPHA FILE or ALPHA LOG commands.

Examples:
OUTPUT /ZONE-A
Outputs all elements, whether or not they have ever been changed.
OUTPUT ALL PIPE FOR /ZONE CHANGES SINCE 21 JANUARY
Outputs all changes to named element and its members since the given date.
OUTPUT /PIPE-100 CHANGES
Outputs all changes to named element and its members since last SAVEWORK
command.
OUTPUT /PIPE-1 CHANGES SINCE EXTRACT
In an extract database, outputs all changes since the extract was created.
OUTPUT /PIPE-1 CHANGES SINCE LATEST EXTRACT
In an extract database, outputs all changes compared with the latest version of the
parent extract.
OUTPUT /PIPE-1 CHANGES SINCE EXTRACT 44
OUTPUT /PIPE-1 CHANGES SINCE EXTRACT PIPE/PIPE-X1
In an extract database, outputs all changes compared with the latest version of the
given extract, which must be higher in the extract hierarchy.
OUTPUT /PIPE-1 CHANGES SINCE SESSION 77 EXTRACT 44
OUTPUT /PIPE-1 CHANGES SINCE OCT 2000 EXTRACT PIPE/PIPE-X1
In an extract database, outputs all changes compared with the given extract, which
must be higher in the extract hierarchy, at the given session or date.
The macro is sent to a file by using the standard ALPHA FILE or ALPHA LOG commands.
You can also give an Outfitting session number. The database states are compared
between SAVEWORK operations. For example, if you last saved your design changes at
9:30 and ask for a macro containing changes since 10:00, the macro will contain all changes
since 9:30.

Command Syntax:
>- OUTPUT <selele> SINCE -+- <date/time> -+-----------------------.
| | |
|- LATEST ------| |
| | |
|--SESSION nn --| |
| | |
‘---------------+- EXTRACT -+- extname -|
| |
‘- extno ---+->

© Copyright 1974 to current year. 13:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

• The following options are not available with the OUTPUT CHANGES functionality.
Once one (or more) of these options have been specified then REVERSE, CHANGES,
etc. cannot be specified following the element to be output.

COMMENT
This specifies that certain comments will be added to the OUTPUT output. The reference
number of each element will be shown immediately after the NEW (or OLD) command, the
owner of each element will be given, and each reference valued attribute will be output as a
comment during the first pass (normally, reference valued attributes are ignored entirely
during the first pass). In addition, the position and orientation of Nozzles will be written in the
coordinate system of their ZONE. All these comments will be enclosed between the
standard comment delimiters, that is:
$(' comment_text '$)
TABULATE n
This specifies that the output will be tabbed by n*d spaces at the beginning of each line,
where d is the depth of the element. Note that where a logical line is split over more than
one physical line in the file (which can happen very easily when a short line length has been
specified on the 'ALPHA FILE' command) then subsequent physical lines are not tabbed.
n must be between 0 and 6.
TABULATE 0 is equivalent to no tabbing.

INDEX
This specifies that
• Each line of the output will be numbered and
• Indexes by reference number and name will be written at the end.
As with tabulate, only logical lines will be numbered; continuation lines will not be numbered.

BRIEF
This specifies that only the NEW or OLD command line will be written, that is, no attributes
will be written.

NOUDA
This specifies that user defined attributes will not be written.
ONLY NOUN or
ONLY (NOUN …. NOUN)
These options specify that only elements of the given types will be output. If more than one
type is to be specified, then the list must be enclosed in brackets. At most 10 types may be
specified.
PASS n
This specifies that only the first pass (element definitions; no reference valued attributes) or
the second pass (reference valued definitions, connections) will be written. n must be 1 or 2.

OLDFORMAT
This specifies that element definitions will be written using the OLD (rather than the NEW)
command, that is, elements are to be updated when the file is re-read.

© Copyright 1974 to current year. 13:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

Locate
If the LOCATE option is used and 'output /VESS1', then the output will contain the following:
NEW LOCATE SITE /ATEST
NEW LOCATE ZONE /ZONE.EQUIP
NEW EQUIP /VESS1
Etc.

REPLACE
If the replace option is used the output will contain the following:
NEW REPLACE EQUI /VESS1
Etc.
N.B. the REPLACE command will only be output for the top level element.
If both LOCATE and REPLACE options are used, the output would be:
NEW LOCATE SITE /ATEST
NEW LOCATE ZONE /ZONE.EQUIP
NEW REPLACE EQUIP /VESS1

SAMER/EF
May be specified after the element to be output, in conjunction with the various formatting
options and with 'CHANGES SINCE date' and 'REVERSE'. If specified, each 'NEW'
command to originally define each element will be output in the form:
1. NEW <eltype> <element> REF =rrrrr/rrrrr
Thus when the file is read back in, the element will be assigned the same reference
number as previously. Of course, this requires that the reference number is suitable in
the environment in which the file will be read.
Examples:
• OUTPUT CE SAMEREF
• OUTPUT INDEX /HTEST SAMEREF
• OUTPUT /STAN.CATA CHANGES SAMEREF
• OUTPUT CE REVERSE CHANGES SAMEREF
2. The NEW command has been extended to allow a new keyword 'REF' followed by a
reference number to be specified after the element name. If so specified, and the
reference number is valid, then the element will be created with the reference number
given.
If an invalid reference number is given, the command will be rejected. Two new error
messages may occur:
• 859: Invalid reference number: =rrrrr/rrrrr
• 860: Reference number =rrrrr/rrrrr already exists
Examples:
• NEW BOX /BOX1 REF =15772/17461

© Copyright 1974 to current year. 13:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

13.4 Some Examples of Output

The examples of output lists in this chapter illustrate the effects of the various formatting
options. Often output files are large, for illustration these have been truncated.
Each example shows the commands used to generate the style of listing following them.

Note: The examples are independent; each starts with all formatting options in their default
states.

13.4.1 Full Output

The following example shows a segment of a full output. Output contains all elements and
non-default attribute settings

Command
OUTPUT /HTEST

Output
INPUT BEGIN
NEW SITE /HTEST
POS E 0 N 0 U 1000

NEW ZONE /EQUIP

FUNC 'Equipment - above grade'
PURP EQUI

NEW EQUIPMENT /E1301

POS E 2850 N 5660 U 1470
UCOFG E 0 N 0 U 0
BUIL true
DSCO unset
PTSP unset
INSC unset

NEW CYLINDER
POS E 0 N 3299 U 0
ORI Y is D and Z is N
LEVE 0 4
DIAM 960
HEIG 6598

END
NEW CYLINDER
POS E 0 N 6848 U 0
ORI Y is D and Z is N

© Copyright 1974 to current year. 13:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

LEVE 0 4
DIAM 1020
HEIG 500

13.4.2 Comment Option

Will output in the same format as Full Output but will include comments to identify sections
of the output.

Command
OUTPUT COMMENT/HTEST

Output
INPUT BEGIN
NEW SITE /HTEST $(=15772/17197$)
$( OWNE /* $)
POS E 0 N 0 U 1000

NEW ZONE /EQUIP $(=15772/17198$)

$( OWNE /HTEST $)
FUNC 'Equipment - above grade'
PURP EQUI

NEW EQUIPMENT /E1301 $(=15772/17213$)

$( OWNE /EQUIP $)
POS E 2850 N 5660 U 1470
UCOFG E 0 N 0 U 0
BUIL true
DSCO unset
PTSP unset
INSC unset

NEW CYLINDER $(=15772/17214$)

$( OWNE /E1301 $)
POS E 0 N 3299 U 0
ORI Y is D and Z is N
LEVE 0 4
DIAM 960
HEIG 6598

END
NEW CYLINDER $(=15772/17215$)
$( OWNE /E1301 $)
POS E 0 N 6848 U 0

© Copyright 1974 to current year. 13:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

ORI Y is D and Z is N
LEVE 0 4
DIAM 1020
HEIG 500

13.4.3 Tabulate Option

Will output with the code tab indenting

Command
OUTPUT TABULATE 2 /PIPES

Output
INPUT BEGIN
NEW ZONE /PIPES
FUNC 'Piping - above grade'
PURP PIPE

NEW PIPE /100-B-1

BUIL false
SHOP false
TEMP -100000
PRES 0
PSPE /A3B
CCEN 0
CCLA 0
LNTP unset
REV 0
DUTY unset
DSCO unset
PTSP unset
INSC unset
UCOFG E 0 N 0 U 0
DELDSG unset

NEW BRANCH /100-B-1-B1

BUIL false
SHOP false
HPOS E 12490 N 12280 U 1150
TPOS E 4979 N 9887 U 13655
HDIR U
TDIR N
UCOFG E 0 N 0 U 0
LHEA true

© Copyright 1974 to current year. 13:9 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

LTAI true
HBOR 50
TBOR 100
HCON FBD
TCON FBD
DETA true
LNTP unset
TEMP -100000
PRES 0
HSTU /A3B/PA50
CCEN 0
CCLA 0
PSPE /A3B
DUTY unset
DSCO unset
PTSP unset
INSC unset
PTNB 0
DELDSG unset

13.4.4 Index Option

Will include line numbers within comments at the start of each line. At the end of a file an
index of refno/name is also included in comments

Output Syntax
OUTPUT INDEX /EQUIP

Output
$( 1. $) INPUT BEGIN
$( 2. $) NEW ZONE /EQUIP
$( 3. $) FUNC 'Equipment - above grade'
$( 4. $) PURP EQUI

$( 5. $) NEW EQUIPMENT /E1301

$( 6. $) POS E 2850 N 5660 U 1470
$( 7. $) UCOFG E 0 N 0 U 0
$( 8. $) BUIL true
$( 9. $) DSCO unset
$( 10. $) PTSP unset
$( 11. $) INSC unset

$( 12. $) NEW CYLINDER

$( 13. $) POS E 0 N 3299 U 0
$( 14. $) ORI Y is D and Z is N

© Copyright 1974 to current year. 13:10 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

$( 15. $) LEVE 0 4
$( 16. $) DIAM 960
$( 17. $) HEIG 6598

$( 18. $) END
$( 19. $) NEW CYLINDER
$( 20. $) POS E 0 N 6848 U 0
$( 21. $) ORI Y is D and Z is N
$( 22. $) LEVE 0 4
$( 23. $) DIAM 1020
$( 24. $) HEIG 500
INPUT FINISH
$(
--- REF INDEX ---
=15772/17198 ... 2
=15772/17213 ... 5
=15772/17214 ... 12
=15772/17215 ... 19
=15772/17216 ... 26
=15772/17217 ... 33
=15772/17218 ... 40
=15772/17219 ... 48
=15772/17220 ... 56
=15772/17221 ... 64
=15772/17222 ... 72
=15772/17223 ... 80
=15772/17224 ... 88
=15772/17225 ... 96
=15772/17226 ... 104
=15772/17227 ... 114
=15772/17228 ... 124
=15772/17229 ... 134

13.4.5 Brief Option

Will only output element names

Output syntax
OUTPUT BRIEF /STEEL

Output
INPUT BEGIN
NEW ZONE /STEEL
NEW STRUCTURE /EQUIPRACK

© Copyright 1974 to current year. 13:11 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

NEW FRMWORK /EQUIPRACK/MAIN

NEW SBFRAMEWORK /EQUIPRACK/MAIN/NODES
NEW PNODE /PNOD-009
NEW PJOINT
END
END
NEW PNODE /PNOD-010
NEW PJOINT
END
END
NEW PNODE /PNOD-012
NEW PJOINT
END
END
NEW PNODE /PNOD-013
NEW PJOINT
END
END
NEW PNODE /PNOD-014
NEW PJOINT
END
END
NEW PNODE /PNOD-015
NEW PJOINT
END
END
NEW PNODE /PNOD-016
NEW PJOINT
END
END

13.4.6 NOUDA Option

Will take the format of a full output, but UDA's will be suppressed.

Output syntax
OUTPUT NOUDA /HEATING-VENTS
See full output for formatting.

13.4.7 OLDFORMAT Option

Will output old commands only.

Output syntax
OUTPUT OLDFORMAT /CIVIL

© Copyright 1974 to current year. 13:12 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

Output
INPUT BEGIN
OLD ZONE /CIVIL
FUNC 'Civils'
PURP CIV

OLD STRUCTURE /F1.PLANT

UCOFG E 0 N 0 U 0
BUIL false

OLD SUBSTRUCTURE /F1.PLANT.FLR

UCOFG E 0 N 0 U 0
POS E 0 S 2000 U 0
BUIL true
SHOP false

OLD PYRAMID /F1.PLANT.FLR-1

POS E 2225 N 18525 D 232.5
ORI Y is N and Z is E
LEVE 0 8
XBOT 450
YBOT 9100
XTOP 420
HEIG 3050
XOFF 15
YOFF 2150

END

13.4.8 ONLY Option

Specify only certain elements for output. Below are examples of variations of this command

Output Syntax for Sites Only

OUTPUT ONLY SITE /HTEST

Output
INPUT BEGIN
NEW SITE /HTEST
POS E 0 N 0 U 1000

END
INPUT END /HTEST

© Copyright 1974 to current year. 13:13 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

INPUT FINISH

Output Syntax for Branches Only

OUTPUT ONLY BRAN /HTEST

Output
INPUT BEGIN
NEW BRANCH /100-B-1-B1
BUIL false
SHOP false
HPOS E 12490 N 12280 U 1150
TPOS E 4979 N 9887 U 13655
HDIR U
TDIR N
UCOFG E 0 N 0 U 0
LHEA true
LTAI true
HBOR 50
TBOR 100
HCON FBD
TCON FBD
DETA true
LNTP unset
TEMP -100000
PRES 0
HSTU /A3B/PA50
CCEN 0
CCLA 0
PSPE /A3B
DUTY unset
DSCO unset
PTSP unset
INSC unset
PTNB 0
DELDSG unset

END

Output Syntax for Nozzles and Branches

OUTPUT ONLY (NOZZ BRAN) /HTEST

Output
NEW NOZZLE /VENT_OUT
UCOFG E 0 N 0 U 0

© Copyright 1974 to current year. 13:14 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

POS E 0 S 500 U 1600

ORI Y is U and Z is S
TEMP -100000
PRES 0
HEIG 200
DUTY unset
DESP 400 200 25 5

END
NEW BRANCH /100-B-1-B1
BUIL false
SHOP false
HPOS E 12490 N 12280 U 1150
TPOS E 4979 N 9887 U 13655
HDIR U
TDIR N
UCOFG E 0 N 0 U 0
LHEA true
LTAI true
HBOR 50
TBOR 100
HCON FBD
TCON FBD
DETA true
LNTP unset
TEMP -100000
PRES 0
HSTU /A3B/PA50
CCEN 0
CCLA 0
PSPE /A3B
DUTY unset
DSCO unset
PTSP unset
INSC unset
PTNB 0
DELDSG unset

END

13.4.9 PASS Option

Optionally output 1st pass or 2nd pass only

© Copyright 1974 to current year. 13:15 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

Output syntax 1st pass only

OUTPUT PASS 1 /EQUIP

Output
INPUT BEGIN
NEW ZONE /EQUIP
FUNC 'Equipment - above grade'
PURP EQUI

NEW EQUIPMENT /E1301

POS E 2850 N 5660 U 1470
UCOFG E 0 N 0 U 0
BUIL true
DSCO unset
PTSP unset
INSC unset

NEW CYLINDER
POS E 0 N 3299 U 0
ORI Y is D and Z is N
LEVE 0 4
DIAM 960
HEIG 6598

Output Syntax 2nd Pass Only

OUTPUT PASS 2 /EQUIP

Output
INPUT BEGIN
OLD /E1301-S1
CREF /200-B-4-B1 TAIL
CATR /AAZFBD0TT

OLD /E1301-S2
CREF /250-B-5-B1 HEAD
CATR /AAZFBD0TT

OLD /E1301-S3
CREF /250-B-5-B2 HEAD
CATR /AAZFBD0TT

OLD /E1301-T1
CREF /100-C-12-B2 TAIL
CATR /AAZFBB0NN

© Copyright 1974 to current year. 13:16 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

OLD /E1301-T2
CREF /100-C-13-B1 HEAD
CATR /AAZFBB0NN

13.4.10 Option Combinations

It is possible to use all of the above options in an output syntax to achieve a combination of
results. The following commands would be valid:
OUTPUT COMMENT TABULATE 4 INDEX /RACKPIPES
OUTPUT COMMENT TABULATE 2 INDEX BRIEF /ELECT
OUTPUT ONLY (ZONE NOZZ BRAN) INDEX TABULATE 2 /HTEST
OUTPUT OLDFORMAT INDEX TABULATE 4 NOUDA /HEATING-VENTS
OUTPUT INDEX COMMENT PASS 1 /CABLETRAY

13.4.11 Locate and Replace

The following Locate and Replace syntax is possible

Output syntax locate/replace

OUTPUT LOCATE REPLACE /E1301

Output
INPUT BEGIN
NEW LOCATE SITE /HTEST
NEW LOCATE ZONE /EQUIP
NEW REPLACE EQUIPMENT /E1301
POS E 2850 N 5660 U 1470
UCOFG E 0 N 0 U 0
BUIL true
DSCO unset
PTSP unset
INSC unset

NEW CYLINDER
POS E 0 N 3299 U 0
ORI Y is D and Z is N
LEVE 0 4
DIAM 960
HEIG 6598

END
NEW CYLINDER
POS E 0 N 6848 U 0
ORI Y is D and Z is N

© Copyright 1974 to current year. 13:17 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

LEVE 0 4
DIAM 1020
HEIG 500

END

Output Syntax Replace Only

OUTPUT REPLACE /E1301

Output
INPUT BEGIN
NEW REPLACE EQUIPMENT /E1301
POS E 2850 N 5660 U 1470
UCOFG E 0 N 0 U 0
BUIL true
DSCO unset
PTSP unset
INSC unset

NEW CYLINDER
POS E 0 N 3299 U 0
ORI Y is D and Z is N
LEVE 0 4
DIAM 960
HEIG 6598

END
NEW CYLINDER
POS E 0 N 6848 U 0
ORI Y is D and Z is N
LEVE 0 4
DIAM 1020
HEIG 500

END
NEW BOX
POS E 0 N 1710 D 315
LEVE 0 8
XLEN 460
YLEN 300
ZLEN 630

END

© Copyright 1974 to current year. 13:18 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

Output syntax Locate only

OUTPUT LOCATE /E1301

Output
INPUT BEGIN
NEW LOCATE SITE /HTEST
NEW LOCATE ZONE /EQUIP
NEW EQUIPMENT /E1301
POS E 2850 N 5660 U 1470
UCOFG E 0 N 0 U 0
BUIL true
DSCO unset
PTSP unset
INSC unset

NEW CYLINDER
POS E 0 N 3299 U 0
ORI Y is D and Z is N
LEVE 0 4
DIAM 960
HEIG 6598

END
NEW CYLINDER
POS E 0 N 6848 U 0
ORI Y is D and Z is N
LEVE 0 4
DIAM 1020
HEIG 500

END
NEW BOX
POS E 0 N 1710 D 315
LEVE 0 8
XLEN 460
YLEN 300
ZLEN 630

END

13.4.12 Create Datal Interactively

In the MyData window, the Datal Listing menu item on the context menu can be used to
create a Datal file.

© Copyright 1974 to current year. 13:19 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Output Syntax

This will display the Datal Listing Options form, where different options can be set. If the
file name is left empty, the Datal will be written to the Command Window.

© Copyright 1974 to current year. 13:20 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Project Queries

14 Project Queries

14.1 MDB Mode

The MDB command puts you into MDB Mode, where you can use a limited number of
Monitor commands. This lets you change the current multiple database during a session
without having to leave the Module and enter Monitor.
When you enter MDB mode, you can either update the current MDB to save your design
changes, or ignore any changes made since your last SAVEWORK command, by specifying
UPDATE or NOUPDATE.
When you are in MDB mode, you can give the following commands, which are the same as
the corresponding Monitor commands. Refer to Monitor Reference Manual for more
information.

Examples:

MDB UPDATE Save design changes and enter MDB Mode.

MDB NOUPDATE Enter MDB Mode without saving design changes.

EXCHANGE Alter the databases in the current list of the current MDB
DEFER
CURRENT

PROTECT Temporarily alters your access rights to specified databases.

USER username Changes the current user

PROJECT code Changes the current project

LIST Allows you to query:

Users, including the number of active users,
Teams including the set (current) Team,
Databases, including copied Databases,
MDBs, Macros and Variables

/PIPING Change to MDB /PIPING.

/PIPING READONLY Change to MDB /PIPING in read-only mode.

EXIT Return to DESIGN Mode.

© Copyright 1974 to current year. 14:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Project Queries

Command Syntax:
>-- MDB --+-- UPdate ----.
| |
‘-- NOUPdate --+-->

14.2 Check the Current User Status

Gives you information about your current status as a user and about the DBs to which you
have access.

Example:

A typical response to the STATUS command could be:

Project: XYZ
User: CSI (758)
Teams: B
MDB: /DESIGN
Current DBS:
1 PIPING/SITE RW
2 MASTER/CATLOG R
Deferred DBS:
3 STRUCT/STEEL

This indicates that the designer has identified himself as being Outfitting user CSI, that he is
logged in to the computer as user 758, that he is a member of team B, that he is accessing
Project XYZ, and that he has selected an MDB called /DESIGN.

Command Syntax:
>-- STATus -->

14.3 Check the Current System Status

The SYstem STATus command gives you information about the current active status of the
project in which you are working. It lists all users who are currently accessing the project,
the modules and databases which they are using, and whether they are examining (Read-
only status) or modifying (Read/Write status) the database. It also gives the workstation
identifier for each user.

© Copyright 1974 to current year. 14:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Project Queries

Example:

A typical response to the SYSTAT command could be:

PROJECT XYZ
==============

USER SYSTEM (57b)

MODULE ADMIN
MDB ** UNSET **

USER HHJ (752)

MODULE DESIGN
MDB /STEEL

DB MODE
MASTER/AREA-A R
MASTER/AREA-B R
STRUC/AREA-C RW

This shows that two users are currently logged in and are using Outfitting for work on
Project XYZ. The Project Coordinator is using ADMIN but is not accessing any databases.
User 752 is using DESIGN. He is accessing the MDB named /STEEL, whose constituent
DBs are as listed. He has Read-only status for the DBs owned by the MASTER (System)
team and Read/Write access to the DB STRUC/AREA-C.

Command Syntax:
>-- SYStat -->

14.4 List Project Information

Lets you list most of the project information held in the System Database, with the exception
of confidential details such as other users’ passwords, which can only be listed by the
System Administrator in Outfitting ADMIN.

Examples:

A typical response to the LIST MDB command could be:

List of MDBS for project XXX

==============================
MDB: /DESIGN
Current DBS:
1 PIPING/AREA-A DESI Exclusive
2 PIPING/AREA-C DESI Update
3 MASTER/AREA-D DESI Exclusive

© Copyright 1974 to current year. 14:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Project Queries

Examples:

Deferred DBS:
4 PIPING/AREA-B DESI Exclusive
5 MASTER/AREA-E DESI Update

MDB:/STEEL
Current DBS:
1 MASTER/AREA-A DESI Exclusive
2 MASTER/AREA-B DESI Exclusive
3 STRUCT/AREA-C DESI Exclusive
Deferred DBS:
**NONE**

MDB: /ANSI
Current DBS:
1 CATAL/AREA-E CATA Update
Deferred DBS:
**NONE**

A typical response to the LIST USERS command could be:

List of USERS for project ZZZ

===============================
SYSTEM (FREE)
TEAMS :MASTER STAB

Z (FREE)
TEAMS :***NONE**

GEN (GENERAL)
TEAMS :TEST

The information generated by the LIST command can either be displayed on screen or sent
to a file.

Command Syntax:
.----<----.
/ |
>-- LIst --*-- USers --|
| |
|-- MDBs ---|
| |
|-- DBs ----|
| |
|-- TEams --’
|
‘-------------->

14.5 Query MDB Information

Lets you query details of the current MDB. This is a supplementary querying facility to the
LIST command (List Project Information). It allows specific information about features of the
project configuration to be interrogated.

© Copyright 1974 to current year. 14:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Project Queries

Command Syntax:
>-- Query --+-- USer ---.
| |
|-- USer word ---|
| |
|-- TEam word ---|
| |
|-- DB dbname ---|
| |
‘-- MDB name ----+-->

14.5.1 Query Individual Database Information

Lets you query details of the current DB for a given element.

Examples:

Q DBNAME Gives name of current DB

Q DBTYPE Gives type of current DB

Q DBFNUMBER Gives file number for current DB

Q DBFILE Gives pathname for current DB file

Command Syntax:
>-- Query --+-- DBNAme -----.
| |
|-- DBTYpe -----|
| |
|-- DBFNumber --|
| |
‘-- DBFIle -----+-->

© Copyright 1974 to current year. 14:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Project Queries

© Copyright 1974 to current year. 14:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Link Documents

15 Link Documents

The link documents mechanisms provide the ability to link external and internal documents
to database objects. Every element in the database can be associated with a resource that
is either another database element for example a drawing, or an external document such as
a file, or a web page. External documents are not stored in the Dabacon database.

15.1 Overview
Each document or other resource, either external or internal, that can be linked to a
database element is represented in the database as Link Descriptor. The Link Descriptor's
main role is to carry information about the document it describes and a Uniform Resource
Locator (URL).
It is possible for any other elements in the database to reference these Link Descriptors
through a two-way mechanism enabling users to find all elements that reference a particular
Link Descriptor and the opposite, find all documents referenced by an element.
It is also possible to assign classification information to each Link Descriptor. The
classification information provides the facility of assigning multiple class information to a
Link Descriptor so that a search for all elements that have references to documents with
specific classification assigned can be made. For example, a search can be made for all
Link Descriptors classified as "Installation"-class document or all pumps that do not
reference any "Certificate" and "Security"-class documents.
The following figure shows a schematic overview of the possible linkage to external
documents and internal drawings.

© Copyright 1974 to current year. 15:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Link Documents

Figure 15:1. Examples of references to internal and external documents

15.2 Data Structures

There are several element types used for organizing links and storing link information. All
kinds of elements may be created using standard Outfitting command syntax.

15.2.1 Link World (LINKWL)

All elements related to links are stored under Link World elements. To use links you have to
create at least one Link World. It can store Link Folders, Link Classes and Link Descriptors
which are covered in the following sections.
It is possible to assign Link Descriptors to elements in other databases. It is therefore
recommended that LINKWL elements are created in a DESIGN database of its own to
which all relevant teams have read and write access.

15.2.2 Link Folder (LNFOLD)

Under Link Worlds it is possible to organise all elements into a tree structure. You can create
Link Folders that can contain more Link Folders or Link Classes and Link Descriptors. This
way it is possible to freely configure the hierarchy.

15.2.3 Link Descriptor (LNDESC)

A Link Descriptor (LNDESC) element holds a link to documents and external resources.
Both external documents and draft drawing elements can be referenced using a LNDESC.
A Link Descriptor has the following attributes:
• NAME - user-defined name of the LNDESC element.
• DESC - description of the element.

© Copyright 1974 to current year. 15:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Link Documents

• LNKURL - a string storing raw Uniform Resource Locator of the linked document.
It can be for example a file ("file:///Docsys/ProjectX/MyDocument.doc"), a web page
("http://www.aveva.com"), an e-mail address ("mailto:[email protected]") or any
other external resource. If it is an internal database reference (e.g. to a drawing) it is
stored in a form "dabref://=12345/6789".
The following pseudo attributes may be queried:
• LNKREF - if the Link Descriptor holds a reference to an internal database element, i.e.
the LNKURL stores a "dabref://…" link, this attribute returns a reference to a database
element linked through this descriptor. Otherwise, LNKREF returns a null reference. It
is also possible to store an internal reference through this attribute.
• URL - this attribute returns merely the value of LNKURL but its main purpose is that
you can assign either an external URL or a string with reference number of a Dabacon
element, which is automatically recognised and stored as an internal link.
• LNKCLS - list of Link Class elements that classify this Link Descriptor.
• LNKELE - list of elements that have this Link Descriptor assigned.

15.2.4 Link Class (LNCLAS)

Classification of documents is possible through use of Link Classes (LNCLAS). Each Link
Descriptor (LNDESC) may be classified by multiple classes; in the diagram below see how
each LNDESC is associated with more than one LNCLAS. A single Link Class may classify
multiple Link Descriptors; in the diagram LNCLASI is associated with all three LNDESC.

A Link Class has the following attributes:

• NAME - user-defined name of the LNCLAS element.
• DESC - description of the element.
There is also a pseudo attribute available named LNKDOC that returns a list of LNDESC
elements that are classified by this LNCLAS.

© Copyright 1974 to current year. 15:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Link Documents

15.3 Command Window

Link Documents functionality is available through the command line. Standard Outfitting
command syntax can be used to create, delete or modify database elements and to query
and set their attributes including pseudo attributes.
The following sections describe the typical scenarios connected with links including
examples.

15.3.1 Configuring Links Hierarchy

Before it is possible to link documents to database elements it is necessary to create at least
one Link World (LINKWL). You can organize Link Descriptors and Link Classes into a
hierarchy of folders. An example hierarchy is shown below.

Figure 15:2. An example hierarchy under a Link World

15.3.2 Link a Document to a Database Element

To add a link between an element and a document (or an external resource):
1. Create a new Link Descriptor somewhere in the links hierarchy.
2. Set its URL to the desired internal or external reference.
3. Link it to a database element using a DLADD command.
You can also link a document to an element using an existing Link Descriptor, because
many database element can be linked to the same document:
1. Locate a LNDESC in the links hierarchy.
2. Link it to a database element using a DLADD command.
The DLADD command can be used to add links from a document to one or more other
elements. The command syntax is:
----------------+
/ |
>--- DLADD -------*-- <selatt> -----+------>

© Copyright 1974 to current year. 15:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Link Documents

It is possible to create an association both by adding a link from a Link Descriptor to a

database element and by adding a link from a database element to a Link Descriptor.
Examples are given below.
If current element is a Hull Panel Element (HPAN) named /PANEL1 the following command
assigns Link Descriptors /MYDOC1 and /MYDOC2 to /PANEL1:
> DLADD /MYDOC1 /MYDOC2
If current element is a Link Descriptor (LNDESC) named /MYDOC1 the following command
assigns this Link Descriptor to /PANEL1 and /PUMP1:
> DLADD /PANEL1 /PUMP1
The whole process of linking a document to /PUMP1 might look like this:
> NEW LNDESC /MYDOC
> URL 'http://aveva.com/all_about_vm12_link_documents.pdf'
> DLADD /PUMP1

15.3.3 Unlinking a Document from a Database Element

Once there is an association between an element and a Link Descriptor you can break the
assignment by using the DLREMOVE command. The command syntax is:
----------------+
/ |
>--- DLREMove ----*-- <selatt> -----+------>
It is possible to remove an association both by removing a link from a Link Descriptor to a
database element or by removing a link from a database element to a Link Descriptor. For
example:
If current element is a Hull Panel Element (HPAN) named /PANEL1 the following command
removes link to document described by /MYDOC1 from /PANEL1:
> DLREM /MYDOC1
If current element is a Link Descriptor (LNDESC) named /MYDOC1 the following command
removes link to document described by this Link Descriptor to /PUMP1:
> DLREM /PUMP1
The following command removes all Link Descriptor associations from the current element:
> DLREM LINks
The following command removes the first five Link Descriptor associations from the current
element:
> DLREM LIN 1 TO 5
Getting and setting link target
If the current element is a Link Descriptor you can retrieve or set the URL stored in this
descriptor. To link to an external resource you should directly set the URL:
> URL 'file:///Docsys/MyDocument.doc'
The Link Descriptor has a pseudo attribute LNKREF that returns a database reference if the
descriptor links internally to Dabacon. If you set the URL to an external resource LNKREF
returns a null reference:
> QUERY LNKREF
Url DBRef Nulref

© Copyright 1974 to current year. 15:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Link Documents

You can use the LNKREF to set link to an internal database reference e.g. a drawing:
> LNKREF /DRAWING1
> QUERY LNKREF
Url DBRef / DRAWING1

15.3.4 Classify a Link

Each Link Descriptor can have a number of Link Classes assigned. To classify a link:
1. Create a Link Class element (LNCLAS) somewhere in the links hierarchy.
2. Assign the class to the Link Descriptor with a DLADD command.
If current element is a Link Descriptor (LNDESC) named /MYDOC1 the following command
classifies this Link Descriptor as a /MYCLASS1 and /MYCLASS2 document:
> DLADD /MYCLASS1 /MYCLASS2
If current element is a Link Class (LNCLAS) named /MYCLASS1 the following command
classifies a Link Descriptor named /MYDOC1 as a /MYCLASS1 document:
> DLADD /MYDOC1

15.3.5 Unclassify a Link

To remove classification information from a Link Descriptor you can use the DLREMOVE
command.
If current element is a Link Descriptor (LNDESC) named /MYDOC1 the following command
removes /MYCLASS1 classification from the /MYDOC1 Link Descriptor:
> DLREM /MYCLASS1
If current element is a Link Class (LNCLAS) named /MYCLASS1 the following command
removes /MYCLASS1 classification from the /MYDOC1 Link Descriptor:
> DLREM /MYDOC1
The following command removes all Link Descriptor associations from the current Link
Class:
> DLREM LINks
The following command removes all classification information from the current Link
Descriptor:
> DLREM CLAsses

15.3.6 Related Pseudo Attributes

A number of pseudo attributes allow retrieval of information on the relation between Link
Descriptors, Link Classes and model elements:
1. For each element in a database you can query the LNKDOC pseudo attribute to get a
list of all Link Descriptors (e.g. documents) that are associated with this element.
2. For each Link Descriptor by querying the LNKELE pseudo attribute you get a list of all
database elements linked to the document associated with this descriptor.
3. For each Link Descriptor you can query the LNKCLS pseudo attribute to get a list of all
classes that classify the document associated with this descriptor.
4. For each Link Class by querying the LNKDOC pseudo attribute you get a list of all Link
Descriptors that have this Link Class assigned as classification information.

© Copyright 1974 to current year. 15:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Link Documents

15.4 Links Addin

The Link Addin is a customisable user form which simplifies much of the process of creating
links.

The Links Addin uses the notion of link categories to treat different types of links differently.
By default the Links Addin comes with predefined link categories for: E-mail address, Web
page, Existing file and Drawing. However, it gives the possibility to extend this set of link
types and to create additional categories. For example, one could add a category that would
accumulate links to documents or links to FTP resources if needed.
When creating a link the Links Addin gives the possibility to choose a link category and set
options for the new link. An example link creation dialog is shown below.

Each link category has a name and an icon. The dialog provides the possibility to input the
Name and Description for the link, depending on the type of link being created the form will
prompt for an appropriate resource to link to. For example when created a link to a web
page the user is prompted to enter a valid Address such as http://www.aveva.com.
Clicking OK will open a new window prompting for a container for the new link.

© Copyright 1974 to current year. 15:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Link Documents

On its first use, the ‘Select destination container’ window will appear empty. This is because
a Link World and Link Folder hierarchy has not been created.
As discussed in the section ‘Configuring Link Hierarchy’ at least one Link World should be
created.
In the ‘Select destination container’ window right click to create a ‘New world’. A ‘New folder’
must also be created below a world.

Click OK for the link to be created in the database hierarchy.

Once a link has been created it is possible to view the link attributes using the link list sub
form, launched from the ‘Show Link’ button from the toolbar. This form displays the element
the Link has been assigned to, the Link Name, Category, Description and Link URL.

© Copyright 1974 to current year. 15:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Link Documents

The Link Addin can be customised through a set of API’s, refer to the Software
Customisation Reference Manual for more information.

© Copyright 1974 to current year. 15:9 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Link Documents

© Copyright 1974 to current year. 15:10 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Inter-DB Connection Macros

16 Inter-DB Connection Macros

Access to a DB is usually controlled in such a way that only one user can modify the content
of that DB at any one time; that is, only one user can have Write access to the DB. Other
users may have simultaneous Read access, depending how access rights have been set up
in the ADMIN module.
In a multi-disciplinary project, in which different teams of users work on different aspects of
the design, an individual user will usually have Read/Write access to the DBs controlled by
their own team and Read-only access to DBs controlled by other teams. This works well
until a user needs to connect an item in their team’s DB to an item in another team’s DB; for
example, a member of the Piping team may wish to connect a Branch in a Piping DB to a
Nozzle in an Equipment DB (to which they have Read-only access). In such a case, the
design changes needed in the Equipment DB are stored in a ‘buffer’ file known as an inter-
DB connection macro. Only when this macro is run by a member of the Equipment team,
with Write access to the Equipment DB, are the changes implemented.
The sequence of events which would occur is illustrated in the following example.
Assume that Project ABC has separate Piping and Equipment design teams. Assume that
User P has Read/Write access to a Piping DB and Read-only access to an Equipment DB,
while User E has Read/Write access to the Equipment DB and Read-only access to the
Piping DB.
User P wishes to connect a Branch Tail in their Piping DB to a Nozzle in User E’s Equipment
DB; that is, they wish to set the Branch’s TREF in their Piping DB to point to the CREF of the
Nozzle (which they can do) and to set the CREF of the Nozzle to point to the TREF of their
Branch (which they can not do), thus:

Only User E
can set this
Nozzle in
Branch in Piping DB Equipment DB
owned by User P's TREF CREF
owned by User
team E's team

Only User P
can set this

• User P sets the TREF of their Branch to point to the CREF of the Nozzle in the
Equipment DB.
• When User P tries to set the Nozzle’s CREF, they receive a message telling them that
they are trying to connect to a read-only DB and that an inter-DB connection macro is
being created automatically. This macro, which stores the commands needed to set the
CREF, is given a name with the format abc001.mac (where the macro number, 001
here, is allocated sequentially), and is held in the directory ABCMAC (or as defined by
the project’s environmental variables).

© Copyright 1974 to current year. 16:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Inter-DB Connection Macros

• When User E next enters MONITOR, they receive a message asking them to run the
inter-DB connection macro abc001.mac and to delete it when they have done so.
• User E enters DESIGN and runs the inter-DB connection macro by giving the
command
$M /%ABCMAC%/abc001.mac
This sets the CREF for the Nozzle to point to the TREF of the Branch and completes
the link between the two DBs.
• User E enters MONITOR (or ADMIN if they have sufficient access rights) and deletes
the redundant macro by giving the command
DELETE MACRO 1
where 1 is the macro number. This command is valid in DESIGN, MONITOR and
ADMIN.
Note: If User P checks their DB for data consistency errors between Stages 2 and 4, when
the macro has been created but not yet run, they will get an ‘incompatible connection
reference’ message. They cannot finalise their design until User E has run the
macro. Thus, the successful use of inter-DB connection macros relies on good co-
operation between the teams involved.

Note: Inter-DB connection macros are also created in multiwrite DBs if an attachment is
claimed by another user.

© Copyright 1974 to current year. 16:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Automatically Prompt the Save Dialogue

17 Automatically Prompt the Save Dialogue

The Autosave utility in the DESIGN module prompts the user to save their work at regular
intervals, which can be determined by the user. The utility will prompt the user to confirm a
Save operation so that its effect on the current session can be managed.
In the DESIGN - General Application, the Autosave function is configured by selecting:
Settings > Save Work Options

Note: This does not effect the Save Work command itself accessed by selecting
DESIGN > Save Work.

If the Save Work Options... command does not appear in the Settings menu, then this
utility has not been installed, and the system will not prompt the user to save work at regular
intervals. Otherwise the AutoSave form displays:

The AutoSave form provides the following functions:

Operation Sets the operation to be performed:

Save Savework command only

Save/Getwork Savework and Getwork commands

Interval Sets the interval between reminders to save work to 15, 30, 45
or 60 minutes

Start Starts the service

Stop Suspends the service

Dismiss Removes the form without starting or stopping the service

Active Shows the start time and date of the current interval.

© Copyright 1974 to current year. 17:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Automatically Prompt the Save Dialogue

An interval starts when the user performs a Save Work using a the GUI, or when the service
was last started.
In normal operation, users will be prompted by a Confirm form, if they do not save work
within the time interval specified on the AutoSave form. Note that answering No to this
forms starts a new time interval even though work has not been saved.

Notes:
1. Each Save Work creates a new session on the database, which increases the size of
the database.
2. The "undo" command only operates between Save Work commands. Once a Save
Work command is performed, it is not possible to undo operations performed prior to
the last Save Work.
3. Data is permanently saved to the database when a Save Work command has been
performed. The user cannot remove changes saved to the database. A Project
Administrator can remove changes by rolling back sessions in the Administrator
module.
4. The user may experience a brief delay while the Save Work command performs its
task.

Installation
This utility is installed using the PML Add-ins mechanism described in the Software
Customisation Guide.
This add-in is specified by add-in definition file with pathname
%PDMSUI%\DES\ADDINS\asave. This add-in file is delivered with the product, but it must
be edited to enable the utility.
In order to do this, open the asave file with a text editor. It should contain the following
commented add-in instructions.
# ----------------------------------------------------------------------
#
# (c) Copyright 2007 to Current Year AVEVA Solutions Limited
#
# File: ASAVE
# Type: Add-in Definition
# Module: design
#
# Author: Malcolm Barlow
# Created: Wed Mar 28 2007
#
# Description: Add-in definition for autosave application
#
# ----------------------------------------------------------------------

© Copyright 1974 to current year. 17:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Automatically Prompt the Save Dialogue

#
# Name: ASAV
# Directory: GEN
# Title: Autosave
# Object: apphsave
# ShowOnMenu: FALSE
# ModuleStartup:!!appHsave.initialise(true)
# StartupModify: GEN :!!appHsave.modifyMenus()

Remove the # character from the lines containing add-in instructions. Leave the # character
at the beginning of comment lines. The resulting file should appear as follows:
# ----------------------------------------------------------------------
#
# (c) Copyright 2007 to Current Year AVEVA Solutions Limited
#
# File: ASAVE
# Type: Add-in Definition
# Module: design
#
# Author: Malcolm Barlow
# Created: Wed Mar 28 2007
#
# Description: Add-in definition for autosave application
#
# ----------------------------------------------------------------------
#
Name: ASAV
Directory: GEN
Title: Autosave
Object: apphsave
ShowOnMenu: FALSE
ModuleStartup:!!appHsave.initialise(true)
StartupModify: GEN :!!appHsave.modifyMenus()

Save the changes to the asave file. Restart for these changes to take effect.
By changing the asave file it is possible to configure the system to start with autosave
enabled or disabled. The file as shown above starts DESIGN with autosave enabled. In
order to start the system with autosave installed and disabled, change the following line:
ModuleStartup:!!appHsave.initialise(true)
to
ModuleStartup:!!appHsave.initialise(false)

© Copyright 1974 to current year. 17:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Automatically Prompt the Save Dialogue

© Copyright 1974 to current year. 17:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Sequence Number Generator

18 Sequence Number Generator

The Sequence Number Generator is useful to derive unique names in a concurrent

application environment. The functionality is based on a set of methods that operates
towards a separate overwrite type of database. This is storing the uniquely named
sequences and also details about the respective sequence. Name sequence elements and
their attributes are protected from being handled manually. One way to operate with name
sequences is through PML NameSeq objects.
A unique item in a sequence is made up by the name of the sequence followed by a running
number, e.g. TEST123, where TEST is the name of the sequence and 123 is the running
number.

18.1 Create a Name Sequence Database

A name sequence database, of the type NSEQ, is created by the Admin utility and selected
to an MDB as any other ordinary type of database. The options given while creating this
type of database is limited as the NSEQ type of the database is predestined to be of an
overwrite type.

18.2 Enable Usage of Name Sequences from PML

import 'aveva.pdms.nameseq'
using namespace 'aveva.pdms.nameseq'

18.3 NameSeq Object

Methods

Name Result Description

NameSeq(string) Bool If not existing, creates a sequence of given name,

otherwise brings back the name sequence available.

Next() String Get next composed name in sequence.

Remove() Bool Delete sequence.

SetStart(real) Bool Set first running number of sequence (default 0).

SetMax(real) Bool Set last running number of sequence.

SetStep(real) Bool Set increment (default 1).

© Copyright 1974 to current year. 18:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Sequence Number Generator

SetWraparound() Bool Allow wraparound when maximum value is reached.

SetNoWraparound() Bool Disallow wraparound (error returned when maximum is

reached).

GetMax() Real Get last running number of sequence (default

2147483647).

GetStep() Real Get increment.

GetCurrent() Real Get current running number.

GetName() String Get name of sequence.

IsWraparound() Bool Get wraparound status.

ReStart Bool Restarts a sequence from its first running number.

GetStart Real Get first running number

18.4 Typical Usage of Name Sequences

Following is an example showing how to define a sequence named TEST and let the
sequence start from 1000. The method Next increments the running number and returns a
name composed by the name of the sequence followed by the running number, i.e.
TEST1001, TEST1002. Whenever needed it is possible to make a break-in in the sequence
and change for example the increment to e.g. 20 instead of 1 as default. This will then
generate composed names as TEST1022, TEST1042.

18.5 Use of Name Sequences in Marine applications

The Sequence Number generator is used by certain functions in Marine to generate unique
names. Each such function uses a dedicated sequence, identified by a sequence name.
Examples:
• Automatic Assembly Drawings. For details on how to set up this Name Sequence, see
the Assembly Drawings Administrator Guide.

© Copyright 1974 to current year. 18:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Sequence Number Generator

• Curved Hull uses name sequences for seams and shell profiles. See Hull Model
Concept > About naming > Specific Name Rules for details.

18.6 Name Sequences in Global Projects

Name sequence databases are local for each site and are not replicated among the different
sites. However names generated by the name sequence mechanism can be used for
naming of items included in the Global synchronisation. To maintain unique naming of items
in a Global environment, the setup of name sequences must be considered. A proper
method is to let each site have different starting numbers of their name sequences, i.e.
SetStart() to a number different for each site.

© Copyright 1974 to current year. 18:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Sequence Number Generator

© Copyright 1974 to current year. 18:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

19 Distributed Attributes

New functionality feature called Distributed attributes has been introduced to the database
system. The fundamental concept of distributed attributes is about enabling objects to have
groups of attributes distributed across hierarchies and potentially databases. As a result, a
number of improvements can be used in the database system.

Improved Concurrency
• Users may work on different sets of data of an object in parallel.
• Support simultaneous multi-discipline update on same object.
• Claim granularity, only claim relevant portions of an object.
Possibility to Distribute an Objects Attributes across Hierarchies and Databases
• Easy distribution over Global dividing distributed attribute over different primary
locations.
Simplified Access Control
• Team owning databases provides both read/write and read-only levels of access within
the same object.
Data Inclusion/Exclusion
• Possible to hide select portions of an object.
User Extendibility on New and Existing Data
• In cases where it is hard to define UDETs this is an alternative way to extend existing
objects with distributed attribute data.
Automatic Attribute Management
• The management (create/delete/referencing) of the distributed attributes.
• While the concept itself is rather straightforward, it introduces new possibilities to
applications.
• An pictoral representation of how the concept might be used in an application, follows:

© Copyright 1974 to current year. 19:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

19.1 Terminology and Data

Distributed attributes are built on top of the well established functions and concepts of
PDMS technology. The functionality of distributed attributes UDAs and UDETs behave as an
integral part of the system.
A distributed attribute group is a UDET based on the XPITEM element type. The UDET itself
works like any other UDET and may carry any number of attributes, whereas UDAs, which
are defined by the user.
An pictoral representation of how the components relate to each other is displayed below:

© Copyright 1974 to current year. 19:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

Term Description
Binding element The owner of distributed attributes groups.
Distributed element / The container for distributed attributes these can be thought
attribute group of as attribute groups. The distributed element is always a
UDET based on the XPITEM element type.
Distributed attribute The attributes, UDAs that a defined for an attribute group.
Default home The location where the distributed elements are stored and
managed.

All definitions of Distributed Attributes are stored in dictionary databases and maintained by
the LEXICON module.

19.2 Configuration
Distributed attributes are made up of UDETs which are associated with the binding element
that they add attributes to. To configure distributed attributes:
• Create UDETs to be used as distributed attribute groups.
• Create the attributes to be included in the attribute groups.
• Create distributed attribute schema associating elements with the distributed attribute
group.
• Create the default home definition the location where distributed attributes are to be
created and managed.
• Create actual default home top level elements where distributed attribute groups are
created.

19.2.1 Create Distributed Attribute Group, the UDET

The task only differ from creating a regular UDET in one aspect, and that is that the UDET
intended for use as a distributed attribute group must be based on the XPITEM element
type.
The user must create the UDETs to be used as distributed attribute groups, these UDETs
needs to be defined with XPITEM as their basetype, then the attributes must be created.

19.2.2 Create the Attributes, as UDAs

The attributes can be defined as any regular UDA, no special considerations need to be
taken.
For example: the UDAs, to be included in the attribute groups.

19.2.3 Create Distributed Attributes Schema

The distributed attribute schema, associating elements with the distributed attribute group
must then be created.
There are two administrative levels, DSXWLD and DSXGRP that is left without any specific
explanation. They serve the same purpose of grouping things, that is schemas, UDAs

© Copyright 1974 to current year. 19:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

together. Distributed attributes schemas are configured using the DSXSCH, DSXOWN and
DSXMBR objects in the lexicon application.

Schema, DSXSCH
A distributed attribute schema is represented by the DSXSCH element, and consists of a
name and an optional default home reference. The default home reference may be
overridden at lower levels in the schema. At present, all schemas are treated as one unified
schema; this functionality is subject to change.

Binding Element Type Definition, DSXOWN

The user can define the element types that may be extended by distributed attributes. The
definition contains an element list (ELEL) which designates the element types. It also
contains a default home reference that, if set override default home defined on schema
level.

© Copyright 1974 to current year. 19:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

Distributed Attribute Definition, DSXMBR

The last part of the distributed attributes schema definition is to associate the UDETs that
form the distributed attributes for the owning elements specified in DSXOWN. The definition
specifies which XPITEM based UDETs that can be used as distributed attributes for the
specified owner. There is a cardinality definition available that defines the minimum and
maximum number of each of the distributed attributes that may be created. A -1 in the
maximum definition represents an infinite number. It also contains an allocation reference
that might override anything defined at schema or owner level.

19.2.4 Default Home Definition

The location where distributed attributes are created and managed must now be defined,
create the default and home definition.
Default home definition is a structure that is used by distributed attributes to figure out where
to create and store the distributed part of the attributes. The DEFHOM ("Allocate" in the
GUI) reference points to the allocation rule to use.

Note: That the tests on the logical expressions has not yet implemented.

Default Home
Each Default home definition is represented by a DSXHOM element the element must be
referenced from distributed attributes, for example: DSXSCH (where to store elements).

© Copyright 1974 to current year. 19:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

Default Home Destination

The user must then create the actual default home. For example: create the top-level
elements where the distributed attribute groups are created.
The default home destination contains a string or ID expression that evaluates the name or
ID of the default home to be used. When used together with distributed attributes, the name
must result in a XPIWLD element. The destination definition also evaluates a logical test
that must yield true in order for it to be used.

Default Home Test

Enables more elaborate tests, logical expressions can be defined and inserted between the
default home element (DSXHOM) and the final destination.

© Copyright 1974 to current year. 19:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

19.2.5 Create the XPIWLD Home Elements

For each unique destination DSXDST defined, the corresponding actual XPIWLD
home-element must be created. For example:
NEW XPIWLD /MyLineLists

19.3 Distributed Attributes, Configuration and Usage

Details
The information that defines the available distributed attributes is defined in two separate
hierarchies:
• the structure of the attributes
• where to physically create and store the data.

19.3.1 Distributed Attributes and Default Home Configuration

The distributed attributes definition is created in the LEXICON module and stored in a
DICTionary database. The detail information of each attribute relies on the existing
definitions of UDAs and UDETs. The definition of distributed attributes is to define what type
of attribute groups (for example: UDETs) are allowed as distributed attributes to which
element types, and their cardinality (further constrains definitions may follow).

19.3.2 DSX Hierarchy, Top Elements

The hierarchy where this information is stored is organised the following way:

© Copyright 1974 to current year. 19:7 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

The common DSX data structure that contains both distributed attributes and default home
definition.

DSXWLD Element
The DSXWLD is the top level element for storing distributed attribute schemas and default
home selectors. It does not contain any attributes of particular interest to distributed
attributes configuration. It can have DSXGRP as members.

Attribute Name Type Usage

NAME Text Standard
DESC Text Standard

The DSXGRP Element

The DSXGRP is a purely administrative level that aids in organizing distributed attribute
schemas and default home selectors. It does not contain any attributes of particular interest
to distributed attributes configuration. The DSXGRP element may have DSXSCH and
DSXHOM members.

Attribute Name Type Usage

NAME Text Standard
DESC Text Standard

19.3.3 Distributed Attributes Schema

A distributed attribute schema is headed with a DSXSCH element. Currently there is no
particular support or use of multiple schemas but to organize distributed attributes in groups
of definitions.

Distributed Attributes Schema Definition Element, DSXSCH

The DSXSCH defines a distributed attribute schema the vital attribute is the DEFHOM that
may contain a reference to a schema default DSXHOM element. The DSXSCH element can
have DSXOWN as members.

Attribute Name Type Usage

NAME Text Standard
DESC Text Standard
DEFHOM Ref to DSXHOM Identifies the default home
selector for this schema

Binder Definition Element, DSXOWN

The DSXOWN defines the element types that may have the defined set of distributed
attributes. One DSXOWN may define one or more element types as defined by the ELEL
attribute. It also contains an optional reference to a binder default DSXHOM element, that

© Copyright 1974 to current year. 19:8 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

DSXHOM overrides any DSXHOM definition on the DSXSCH level. The DSXOWN element
can have DSXMBR as members.

Attribute Name Type Usage

NAME Text Standard
DESC Text Standard
DEFHOM Reference to DSXHOM Identifies the default home
selector for the binder.
Overrides any definition on
schema level.
ELEL Element types list Defines the element types that
may have distributed attribute
types bound to them

Distributed Attribute Definition Element, DSXMBR

The DSXMBR defines the element types to be used as distributed attributes. One DSXMBR
may define one or more element types as defined by the ELEL attribute. The element types
must be UDETs based on the XPITEM element type. It also contains an optional reference
to a distributed attribute default home DSXHOM element, that DSXHOM overrides any
definition on the DSXOWN level.

Attribute Name Type Usage

NAME Text Standard
DESC Text Standard
DEFHOM Reference to DSXHOM Identifies the default home
selector for the distributed
element types defined in this
definition
AUTCRE Logical Auto-create. The distributed
element is automatically
created if it doesn't exist at a
modification operation.
ELEL Element types list Defines the element types that
represents the distributed
attribute types
CARD Integer array [2] Min and Max cardinality of the
distributed attributes. (Note,
only the Max Cardinality is
currently effective)

19.3.4 Default Home Selector

The default home is defined by a DSXHOM hierarchy, it is expected that a number of default
home definitions are in use for distributed attributes.

© Copyright 1974 to current year. 19:9 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

Default Home Element, DSXHOM

The DSXHOM defines a default home selector, it contains no information vital to the Default
home configuration and may have DSXTST and DSXDST members.

Attribute Name Type Usage

NAME Text Standard
DESC Text Standard

DSXTST Element
The DSXTST defines a test that needs to yield true upon evaluation for considering using
this default home, it contains a test expression defined in PML1. The expression operates
on the current binding element.

Attribute Name Type Usage

NAME Text Standard
DESC Text Standard
DHTEST PML1 expression The test to evaluate to
examine if this represents the
requested default home.

DSXDST Element
The DSXDST denotes the default home value as a text string. It also contains a test that
needs to yield true upon evaluation for considering this default home being valid.

Attribute Name Type Usage

NAME Text Standard
DESC Text Standard
DHTEST PML1 expression The test to evaluate to
examine if this represents the
requested default home.
DHTEXT PML1 expression An expression of string or ID
type that should evaluate to an
existing element at runtime.
(For distributed attributes, this
must resolve to a XPIWLD
element).

19.4 New Syntaxes

There are new syntaxes available to work with distributed attributes.
• The creation/deletion of the distributed attributes member(s)
• The manipulating of the individual values on the distributed attributes members.

© Copyright 1974 to current year. 19:10 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

19.4.1 New and Updated Syntax

There are also a small number of pseudo attributes available on elements that are
associated with distributed attributes.

DATT NEW
The NEW command creates a new distributed attribute and associates the CE/on element
with it.
Syntax:
DATT NEW <type> [on <element>]
The example creates a new distributed attribute of type :PRESSURE and associates it with
CE.
Example:
DATT NEW :PRESSURE

19.4.2 DATT DELete

The DELete command removes distributed attributes from CE/from element
Syntax:
DATT DELete ALL [<type>] [from < element>]
DATT DELete [FIRST | LAST | <int>] <type> [from <
element>]
The example deletes the last distributed attribute member of type :PROCESS from /
MyEquipment.
Example:
DATT DEL LAST :PROCESS FROM /MyEquipment

19.4.3 Q ATT
The existing Q ATT have been extended to allow for querying distributed attributes.
Syntax:
Q ATT [AS ANY | <type>]
The command displays all the values of the :PROCESS type associated with CE.
Example:
Q ATT AS :PROCESS

19.5 Distributed Attributes and Attribute Syntax

Since more than one instance of a distributed element is handled [n] is used to qualify which
instance the user is interested in.
The syntax is used on both queries and manipulations of attributes, as well as in PML1
expressions.
Syntax:

© Copyright 1974 to current year. 19:11 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

:UDANAME\:UDETNAME
Example:
-- Query the value of the :local\:process distributed attribute on CE
Q :LOCAL\:PROCESS
:local\process true
-- Set the value of distributed attribute :local\:process to false
:LOCAL\:PROCESS false
-- Query all LNLIST elements where distributed attribute :local\:process equals true
Q ALL LNLIST WITH (:LOCAL\PROCESS EQ true)
-- Query the value of the second instance of distributed attribute :local\:process
Q :LOCAL\:PROCESS[2]
:local\process[2] true
-- Set the value of the second instance of distributed attribute :local\:process to false
:LOCAL\:PROCESS[2] false
-- Query all LNLIST elements where second instance of distributed attribute :local\:process
equals true
Q ALL LNLIST WITH (:LOCAL\PROCESS[2] EQ true)

19.6 PML2 Support

There is full pml2 support for distributed attributes. Constructs such as; !!ce.:local\:process
= false works as could be expected. Also more complex things involving both arrays and
multiple instances of distributed attributes work with the syntax that would be expected.
Example:
-- Set the third array element in the second instance of distributed attribute
:myArray\:MyList to 12.345
!!ce.:myArray[3]\:myList[2] = 12.345

19.7 Pseudo Attributes Associated with Distributed

Attributes
There are a few number of pseudo attributes available to all elements that may have
distributed attributes associated with them.

19.7.1 DLIST - Eligible Distributed Attributes Members

The attribute returns a list of all eligible distributed attribute types that may be associated
with current element. The list does not consider any constraints defined in the schema.
Example:
Q DLIST
DLIST :PROCESS :PRESSURE

© Copyright 1974 to current year. 19:12 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

19.7.2 XRLSTT - List Distributed Attributes Member Types Associated

This attribute returns a list of all distributed attribute types associated with current element.
Example:
Q XRLSTT
XRLSTT :PROCESS :PRESSURE

19.7.3 XRLIST - List Distributed Attributes Member Associated

The attribute returns a list of all distributed attribute members (elements) associated with
current element. The attribute may take an optional qualifier on typename.
Example:
Q XRLIST
XRLIST
1 :PROCESS 1 of XPIFLD 2 of XPIFLD 1 of /THEPROCWLD
2 :PRESSURE 1 of XPIFLD 2 of XPIFLD 1 of /THEPROCWLD
Q XRLIST (TYPENAME :PROCESS )
1 :PROCESS 1 of XPIFLD 2 of XPIFLD 1 of /THEPROCWLD

19.7.4 XRQCNT - Count of Distributed Attributes Member Associated

The attribute returns the number of distributed attribute members (elements) associated
with current element. The attribute may take an optional qualifier on typename.
Example:
Q XRQCNT
XRQCNT 2
Q XRQCNT (TYPENAME :PROCESS )
XRQCNT 1

19.7.5 XRQELE - Return a Single Distributed Attribute Member

The attribute returns a selected distributed attributes member of distributed attribute
members (elements) associated with current element. The attribute may take an optional
qualifier of typename.and relative position.
Example:
Q XRQELE
XRQELE 1 :PROCESS 1 of XPIFLD 2 of XPIFLD 1 of /THEPROCWLD
Q XRQELE ( 1 )
XRQELE 1 :PRESSURE 1 of XPIFLD 2 of XPIFLD 1 of /THEPROCWLD

© Copyright 1974 to current year. 19:13 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

19.7.6 ATTDST - List of Attributes to Show

The attribute is available on the distributed attribute member and returns a list of attributes
that should be shown by default as attributes. The attribute fulfils the same purpose as
ATTLIS for normal attributes.
Example:
Q ATTDST
ATTDST :TEMP :VISCOCITY

19.7.7 DFHOME - The Evaluated Default Home

The attribute is available on the any element, in addition to be used for distributed attributes,
it may be used in a generic way.
When used specifically for distributed attributes evaluation: It takes the typename of a
bindable noun/udet as qualifier. It evaluates the actual home element using current element
as when evaluating the test expressions and returns a nulref or a ref to an XPIWLD element.

Note: The evaluation finds the associated DSXHOM from the typename qualifier, after that
processing is the same as for the generic case.

Using it for generic "find a default home" purposes: The DSXHOM reference passed as
a qualifier is used to evaluate the expressions defined in the DSXTST/DSXDST of that
DSXHOM. It returns a nulref of the ref of the ID value held in the DHTEXT attribute of the
resulting DSXDST. The CE is passed to the expression for evaluation.
Example:
-- distributed attributes, get the location to store distributed attributes of type process for CE.
Q DFHOME ( TYPENAME :PROCESS )
DFHOME /THEPROCESSWORLD
-- Generic example, get the reference that results of evaluation the DSXHOM /
MyHomeSelector for /TESTTHIS.
Q DFHOME ( /MyHomeSelector ) OF /TESTTHIS
DFHOME /STOREITHERE

19.8 Datal
As a complement to normal Datal processing of distributed attributes, there is a specialized
support that generates datals with the distributed attributes syntax.
Syntax:
OUTPUT INCLUDE Distributed/ATTRIBUTES ... <SELELE> and
other options
For example: getting everything under the ZONE /MyZone including any distributed
attributes would be done by executing the following output command:
OUTPUT INCLUDE DistributedA /MyZone
Part of the output would resemble the following, with the distributed attributes statements
included:

© Copyright 1974 to current year. 19:14 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

NEW EQUI
DATT NEW :Process
:Local\:Process false
END

19.9 Element Selection, Claim, Flush

The element selection syntax is extended so that the distributed attribute group, in previous
examples the :Process is addressable using the AS keyword. Allows the user to extract
operations such as claim, flush and Status Control operations on the distributed attribute
granularity level.

19.9.1 Status Control Example

-- Assign /MyStatus to distributed attribute group :Process of /MyEquip
STM ASS /MyStatus to /MyEquip as :Process
-- Query the list of assigned statuses of the distributed attribute group :Process of /MyEquip
Q STVLST OF /MyEquip AS :Process
StvLst\:Process /MyStatus
-- Query the status value for /MyStatus of the distributed attribute group :Process of /
MyEquip
Q STVVAL(/MyStatus) OF /MyEquip AS :Process
StvLst\:Process /NotStarted

© Copyright 1974 to current year. 19:15 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Distributed Attributes

© Copyright 1974 to current year. 19:16 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Copying Data between Projects

20 Copying Data between Projects

This chapter gives recommendations for copying hull data between projects in AVEVA (12
Series).

20.1 Design Reuse

Design Reuse is the recommended tool to copy and reuse model data and drawings
between projects.
Refer to User Guide Design Reuse.

20.2 Copy Assistant

The Copy Assistant is an administration utility with the purpose to support and simplify the
process of copying project data. The utility is delivered as a .NET Addin,
CopyAssistAddin.dll, which can be hosted by the following modules: Hull Design,
Outfitting Design and Marine Drafting. Refer to User Guide Customisation / .NET
Customisation / How to Write a CAF Addin / Configure a Module to Load an Addin.
Copy Assistant is using Datal for exporting and importing of data. The tool also provides
functionality to facilitate expanded selections based on database element relations. Beside
model data it is also possible to export and import drawings files in the SBD format.
A Copy Set designates a collection of Datal files (.dtl), the all_elements.lis and a
Copy Set Control file (.cxs) , all together normally stored in a separate folder. A Copy Set is
the result of an export operation and input to an import operation.

© Copyright 1974 to current year. 20:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Copying Data between Projects

20.2.1 Export
As a preparation for an export a set of elements have to be collected as source to the
operation. Drag & drop, with the list view of the tool as target, is the method to build a
collection of elements for export. Below, the functions related to an export operation are
described:

New Makes the tool ready to build a new collection of elements for export.

Clear Empties the list view by all elements currently collected.

Options The collection of elements explicitly selected through drag & drop can be
further extended to include also referred elements. Through a number of
predefined reference filters it is possible to optionally change the settings of
respective filter and view the result of the expansion. For further details
about reference filters, see Include Associated Data below.

© Copyright 1974 to current year. 20:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Copying Data between Projects

Show all Toggle between viewing only the elements explicitly selected, alternatively
viewing the complete extended collection made through the Options func-
tion.

Export Creates a Copy Set named and located in a folder specified by user. The
collection of elements in the list view will be the contents of the Copy Set.

20.2.2 Import
The functions related to an import operation are:

Open User is asked to specify the Copy Set to open and make ready for import.
The content of the opened Copy Set is shown in the list view. It is possible
to reduce the list view by items not of interest for the import.

Import Respective item of the list view is processed and imported into the current
project.

The list view responds to key commands and thereby it is possible e.g. to reduce the list by
help of the Delete key.

20.2.3 Include Associated Data

A set of Reference filters are defined to facilitate a further extended element collection than
the explicitly selected elements. The filters operate on the explicit selected elements only
and not on the result of former filter expansions. The first part of a filter name states the type
of element the filter operates on. The suffix of a filter name indicates the category of
references the filter is meant to resolve. E.g. the PlanarPanelPlate filter will operate on
explicit selected planar panels to find references to plates. The type of plates is further
specified in a drop down list for the filter. Filters with the suffix ‘Deps’, belong to a category
that resolves references to elements in logical superior position in the hierarchy.

Planar Panel Filters

Operates on HPANEL, HBLOCK.

Filter: Resolve references to:

PlanarPanelPlate ProductionPlate & NestPlate

PlanarPanelProfile ProductionProfile & NestProfile

PlanarPanelAssembly Assembly

Curved Plate Filters

Operates on CPLATE, CSURPX, HCMWLD.

Filter: Resolve references to:

CurvedPlate ProductionPlate & NestPlate

© Copyright 1974 to current year. 20:3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Copying Data between Projects

CurvedPlateAssembly Assembly

CurvedPlateDeps CurvedPanel

Curved Profile Filters

Operates on CPROF, CSURPX, HCMWLD.

Filter: Resolve references to:

CurvedProfile ProductionProfile & NestProfile

CurvedProfileAssembly Assembly

CurvedProfileDeps CurvedPanel

Production Plate Filters

Operates on MPLATE.

Filter: Resolve references to:

ProductionPlate NestPlate

NestPlate RawPlate

ProductionPlateDeps PlanarPanel/CurvedPlate & CurvedPanel

Nest Plate Filters

Operates on MPLNST.

Filter: Resolve references to:

NestPlateDeps ProductionPlate & PlanarPanel/CurvedPlate & CurvedPanel

Nest Profile Filters

Operates on MPRNST.

Filter: Resolve references to:

NestProfileDeps ProductionProfile & PlanarPanel/CurvedProfile & Curved-

Panel

© Copyright 1974 to current year. 20:4 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Copying Data between Projects

Production Profile Filters

Operates on MPROF.

Filter: Resolve references to:

ProductionProfile NestProfile

ProductionProfileDeps PlanarPanel/CurvedProfile & CurvedPanel

Assembly Filters
Operates on ASMBLY, ASWLD

Filter: Resolve references to:

AssemblyPlanarPanel PlanarPanel

AssemblyCurvedPlate CurvedPlate

20.2.4 Restoring Database References

Existing database references in the target project, pointing to an element which is being
replaced during import, are restored to point to the new element. This is achieved by
tracking all elements to be replaced, capturing all existing references to these elements, and
finally restoring these references to point to the new elements.

Note: This is not the same as the SAMEREF option.

20.2.5 Prerequisites
Note that the target project must be properly set up before copying hull data with
MarineCopyAssistant:
• Place holders for top level elements must be created in advance. This is done with the
dbprompt utility.
• Hull setup objects such as Hullref and Structref must exist.

20.2.6 Limitations
Exporting and importing drawings may cause loss of some data as it is only the SBD file that
is copied and not the part of data stored in the PADD database. The loss of data may affect
Dimensions, intelligent text expressions and labels.

20.3 Restoring Selected Hull Design Data

If there is a need to restore selected hull data by reverting to old data, the following steps
can be done:
• Bring in the wanted DESI database/session either from a backup or from reverting the
database.
• Export hull data using the method described above in Copy Assistant.

© Copyright 1974 to current year. 20:5 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Copying Data between Projects

• Bring back the ordinary DESI database/session.

• Import hull data as described above in Copy Assistant.

20.4 Replicate Project

REPLICATE project could be used to copy a complete project including hull data.

© Copyright 1974 to current year. 20:6 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Cleanup and the CLEANUp Command

21 Cleanup and the CLEANUp Command

21.1 Cleanup and the CLEANUp command

The command CLEANUp cleans up unwanted references in the database. It is possible to
remove null references and unresolved/invalid references.
The logical attributes NULLREf, INVREF and UNRESOlved is used to sort out whether a
reference attribute points to something valid or not. The syntax is the same for all three:
Q NULLRE (ATTNAME att )
Answers the question is the attribute att null (=0/0)?
Q UNRESO (ATTNAME att )
Is the attribute att pointing to an element whose existence we cannot find and verify? It
could be that the database is missing or that the reference is truly invalid.
Q INVREF (ATTNAME att )
Is the attribute pointing to an element that is non-existent? This differs from unresolved in
that the database that should accommodate the missing element is present in the active
mdb.

The Cleanup command, syntax:

CLEANU/P NULL/REF | INVALID | UNRES/OLVED attribute [ON noun] [FOR ele]
[SETNULL | DELETE]

© Copyright 1974 to current year. 21:1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual
Cleanup and the CLEANUp Command

Examples:
CLEANU NULL STLREF ON EQUI DELETE
Deletes all EQUI with STLREF equal null (=0/0)
CLEANU UNRES CATREF FOR /PIPES SETNULL
Sets all unresolved CATREF in the /PIPES hierarchy to null (=0/0)
CLEANU INVALID CATREF
Sets all unresolved CATREF in the hierarchy under CE to null

© Copyright 1974 to current year. 21:2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

Index

A in expressions . . . . . . . . . . . . . . . . 9:46
Configuration . . . . . . . . . . . . . . . . . . . . 19:3
ABS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:16 COSINE . . . . . . . . . . . . . . . . . . . . . . . . 9:19
ACOS . . . . . . . . . . . . . . . . . . . . . . . . . . 9:16 CREATED . . . . . . . . . . . . . . . . . . . . . . . 9:7
ADD . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:13
AFTER . . . . . . . . . . . . . . . . . . . . . . . . . 9:34
ALOG . . . . . . . . . . . . . . . . . . . . . 9:17, 9:20
D
AND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:4 Database changes
ARRAY . . . . . . . . . . . . . . . . . . . . . . . . . 9:17 querying history . . . . . . . . . . . . . . . 12:1
Array variables Datal . . . . . . . . . . . . . . . . . . . . . . . . . . 19:14
selecting ( only) . . . . . . . . . . . . . . . 11:1 DEFINED . . . . . . . . . . . . . . . . . . . . . . . . 9:7
ARRAYSIZE . . . . . . . . . . . . . . . . . . . . . 9:17 DELETED . . . . . . . . . . . . . . . . . . . . . . . . 9:7
ARRAYWIDTH . . . . . . . . . . . . . . . . . . . 9:18 Design Reuse . . . . . . . . . . . . . . . . . . . . 20:1
ASIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:16 DIFFERENCE command . . . . . . . . . . . 12:8
ATAN . . . . . . . . . . . . . . . . . . . . . . . . . . 9:16 DISTANCE . . . . . . . . . . . . . . . . . . . . . . 9:36
ATANT . . . . . . . . . . . . . . . . . . . . . . . . . 9:16 format . . . . . . . . . . . . . . . . . . . . . . . 9:36
Attributes US format . . . . . . . . . . . . . . . . . . . . 9:36
in expressions . . . . . . . . . . . . . . . . 9:45 DIVIDE . . . . . . . . . . . . . . . . . . . . . . . . . 9:14

B E
BADREF . . . . . . . . . . . . . . . . . . . . . . . . . 9:6 EMPTY . . . . . . . . . . . . . . . . . . . . . . . . . . 9:8
BEFORE . . . . . . . . . . . . . . . . . . . . . . . . 9:34 EQUAL . . . . . . . . . . . . . . . . . . . . . . . . . . 9:4
Boolean operators . . . . . . . . . . . . . . . . . . 9:3 Explicit mode
Bound Attributes multiwrite DBs . . . . . . . . . . . . . . . . . 6:1
and Attribute Syntax . . . . . . . . . . . 19:11 Expressions
Configuration and Usage Details . . 19:7 directions in . . . . . . . . . . . . . . 9:30, 9:31
format . . . . . . . . . . . . . . . . . . . . . . . . 9:1
C IDS in . . . . . . . . . . . . . . . . . . . . . . . 9:26
logical . . . . . . . . . . . . . . . . . . . . . . . . 9:2
COLLECT command . . . . . . . . . . . . . . . 11:1 logical array . . . . . . . . . . . . . . . . . . 9:12
Collections . . . . . . . . . . . . . . . . . . . . . . 11:1 nesting . . . . . . . . . . . . . . . . . . . . . . . 9:2
COMP . . . OF . . . . . . . . . . . . . . . . . . . . 9:18 numeric . . . . . . . . . . . . . . . . . . . . . 9:12
Comparator operators . . . . . . . . . . . . . . . 9:3 positions in . . . . . . . . . . . . . . . . . . . 9:26
Comparison precision precision of comparisons . . . . . . . . 9:46

© Copyright 1974 to current year. Index page 1 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

real . . . . . . . . . . . . . . . . . . . . . . . . . 9:12 New Syntaxes . . . . . . . . . . . . . . . . . . 19:10

real array . . . . . . . . . . . . . . . . . . . . 9:24 NINT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:22
text . . . . . . . . . . . . . . . . . . . . . . . . . 9:33 NOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:5
types . . . . . . . . . . . . . . . . . . . . . . . . . 9:1 NUMBER (REAL) . . . . . . . . . . . . . . . . . 9:22
Extracts . . . . . . . . . . . . . . . . . . . . . . . . . . 6:3 Numeric expressions . . . . . . . . . . . . . . 9:12
master . . . . . . . . . . . . . . . . . . . . . . . 6:3 Numeric operators . . . . . . . . . . . . . . . . 9:13

F O
Format distances . . . . . . . . . . . . . . . . . 9:37 OCCUR . . . . . . . . . . . . . . . . . . . . . . . . 9:22
FROM . . . . . . . . . . . . . . . . . . . . . . . . . . 9:28 Operators
Functions logical . . . . . . . . . . . . . . . . . . . . . . . . 9:3
logical . . . . . . . . . . . . . . . . . . . . . . . . 9:6 numeric . . . . . . . . . . . . . . . . . . . . . 9:13
numeric . . . . . . . . . . . . . . . . . . . . . . 9:15 precedence . . . . . . . . . . . . . . . . . . . 9:2
real . . . . . . . . . . . . . . . . . . . . . . . . . 9:15 text . . . . . . . . . . . . . . . . . . . . . . . . . 9:33
text . . . . . . . . . . . . . . . . . . . . . . . . . 9:34 OR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:6

G P
GE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:5 PART . . . . . . . . . . . . . . . . . . . . . . . . . . 9:39
Group element . . . . . . . . . . . . . . . . . . . . 8:6 PML2 Support . . . . . . . . . . . . . . . . . . 19:12
GT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:5 Positions
comparing . . . . . . . . . . . . . . . . . . . 9:29
I POWER . . . . . . . . . . . . . . . . . . . . . . . . 9:23
Pseudo Attributes
IDs in expressions . . . . . . . . . . . . . . . . . 9:26 Associated with Bound Attributes 19:12
Implicit mode
multiwrite DBs . . . . . . . . . . . . . . . . . 6:1 Q
INT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:20
Querying
L variables and expressions . . . . . . . 9:45

Late evaluation of expressions 9:11, 9:24, 9:45 R

LE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:5
LENGTH . . . . . . . . . . . . . . . . . . . . . . . . 9:20 REAL . . . . . . . . . . . . . . . . . . . . . . . . . . 9:22
Logical functions . . . . . . . . . . . . . . . . . . . 9:6 Real arrays in expressions . . . . . . . . . . 9:24
LOWCASE . . . . . . . . . . . . . . . . . . . . . . 9:38 Real expressions . . . . . . . . . . . . . . . . . 9:12
LT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:5 Relational operators . . . . . . . . . . . . . . . . 9:3
REPLACE . . . . . . . . . . . . . . . . . . . . . . 9:39
M
S
Master database
of extract . . . . . . . . . . . . . . . . . . . . . . 6:3 SINCE command . . . . . . . . . . . . . . . . . 12:8
MATCH . . . . . . . . . . . . . . . . . . . . 9:20, 9:42 SINE . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:19
MATCHWILD . . . . . . . . . . . . . . . . . . . . . 9:9 SQRT . . . . . . . . . . . . . . . . . . . . . . . . . . 9:23
MAX . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:21 STRING . . . . . . . . . . . . . . . . . . . . . . . . 9:41
MIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:21 SUBSTRING . . . . . . . . . . . . . . . . . . . . 9:42
MODIFIED . . . . . . . . . . . . . . . . . . . . . . 9:10 SUBTRACT . . . . . . . . . . . . . . . . . . . . . 9:13
MULTIPLY . . . . . . . . . . . . . . . . . . . . . . 9:14
T
N
TANGENT . . . . . . . . . . . . . . . . . . . . . . 9:19
NEGATE . . . . . . . . . . . . . . . . . . . . . . . . 9:21 Terminology and Data . . . . . . . . . . . . . 19:2
NEQUAL . . . . . . . . . . . . . . . . . . . . . . . . . 9:4 Text functions . . . . . . . . . . . . . . . . . . . . 9:34

© Copyright 1974 to current year. Index page 2 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.
 Database Management Reference Manual

Text operator . . . . . . . . . . . . . . . . . . . . . 9:33

TRIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:43

U
UNDEFINED . . . . . . . . . . . . . . . . . . . . . . 9:7
Undefined values
in expressions . . . . . . . . . . . . . . . . 9:46
Units
in expressions . . . . . . . . . . . . . . . . 9:25
UNSET . . . . . . . . . . . . . . . . . . . . . . . . . 9:11
Unset values
in expressions . . . . . . . . . . . . . . . . 9:46
US format distances . . . . . . . . . . . . . . . 9:37

V
VAR command . . . . . . . . . . . . . . . . . . . 11:1
VLOGICAL . . . . . . . . . . . . . . . . . . . . . . 9:11
VTEXT . . . . . . . . . . . . . . . . . . . . . . . . . 9:44
VVALUE . . . . . . . . . . . . . . . . . . . . . . . . 9:24

W
WRT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9:27

© Copyright 1974 to current year. Index page 3 12 Series

AVEVA Solutions Limited and its subsidiaries.
All rights reserved.