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.
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.)
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.
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.

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.)
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.
>- RULE SET - attribute_name -+- STAtic --.
                              |           |
                              |- DYNamic -|
                              |           |
                              ‘-----------+- <expre> -+- ON -.
                                                      |      |
                                                      ‘------+-.
                                                               |
                                                        .------’
                                                        |
                                                        ‘-+- <selatt> -.
                                                          |            |
                                                          ‘------------+->

RULE SET ZLEN (XLEN + YLEN)
RULE SET XLEN DYNAM (YLEN + 2)
RULE SET POS (N300 E400 U500) ON ALL BOX FOR /PUMP1
RULE SET POS DYNAM (N100 FROM /BOX2 )
Q ATT
Q RULES
Q RUL OF XLEN


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.
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.
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.
>-- RULE VERify --+-- attribute_name --.
                  |                    |
                  ‘-- ALL -------------+-- ON --.
                                       |        |
                                       ‘--------+-- <selatt> --.
                                                |              |
                                                ‘--------------+-->

RULE VERIFY ALL
RULE VER HEIG ON CYLI 1 FOR /PUMP1


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.
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.
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.
>-- RULE EXEcute --+-- attribute_name --.
                   |                    |
                   ‘-- ALL -------------+-- ON --.
                                        |        |
                                        ‘--------+-- <selatt> --.
                                                 |              |
                                                 ‘--------------+->

RULE EXECUTE :TEMP1
RULE EXE ALL ON ALL BOX FOR /PUMP1


Lets you delete one or more rules for the current element or for specified elements.
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.
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.
>-- RULE DELete --+-- attribute_name --.
                  |                    |
                  ‘-- ALL -------------+-- ON --.
                                       |        |
                                       ‘--------+-- <selatt> --.
                                                |              |
                                                ‘--------------+-->

RULE DELETE ALL
RULE DEL ALL ON ALL FOR /PUMP1


Rules can be set for array attributes by using the NUM syntax, for example, 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 )


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:
!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:
It is possible to limit the number of items collected using the MAX number option. Starting for example: MAX 50, will collect only the first 50 items that matches the criteria given.
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:
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:
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:
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:
collects all elements in the defined volume into the array !VOLUME.
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 Plant there are structural design data, termed MODEL, 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.
Q VOLUMEOPTION HULL DESIGN
Returns DESIGN data
Q VOLUMEOPTION HULL PRODUCTION
Returns PRODUCTION data
Q VOLUMEOPTION HULL DESIGN
Returns DESIGN data
Q VOLUMEOPTION HULL PRODUCTION
Returns PRODUCTION data
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:
You can append the results of such a collection to an existing array using the APPEND keyword. For example:
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:
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.
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.
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.
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:
Since only BOXes (and NBOXes) meet this criterion it would be sensible to limit the search by specifying an appropriate class:
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:
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.
will set up the array IPIPECOMPS to contain the reference numbers of every piping component in the MDB, e.g.
Every flange could then be extracted as follows:
and then enhanced (highlighted):
This could alternatively be performed in one step:
Collections may be joined or concatenated by preceding the COLLECT keyword by APPEND:
Alternatively, the following:
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:
Then !TUBING would contain something like the following:
!TUBING[1]
'IL TUB OF =20/302'
!TUBING[2]
'IL TUB OF =20/303'
!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:
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.
The name of a given prefix may be collected using the 'FROM TABLE NAME PREFIX' option.
For example:
This will find all names starting with 'B'.
The syntax may be used in conjunction with the standard options. E.g.
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.
For example:
This will return all elements with SPRE set to /RF300/100G.
The syntax may be used in conjunction with the standard options. For example:
Searching using indexes directly will be considerably faster than the standard searches.for example:
The referenced attributes that are indexed are:
CATR
Catalog 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
DOCREF
Cross reference DOCU elements
CATR
Catalog 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
To benefit from indexing you must use the 'FROM TABLE' syntax in collections. This syntax is similar the same as for system attributes.
For Text Userd Defined Attributes (UDAS):
will find all elements in current Database (DB) with :MYTEXTATT set to 'fred'
will find all elements in current DB with :MYTEXTATT starting with 'fred'
For Integer UDAS:
This will find all elements with a :MYATT of 100
This will find all elements where :MYATT is between 100 and 110.
For Ref Attributes:
will find all elements in current DB with :MYREFATT set to /PIPE1
The new syntax may be combined with existing collection syntax. E.g.
Currently a collection can be restricted to a specific DB by navigating to a specific DB and setting the scope of /*. For example:
At 12.1 the DB name may be specified as part of the collection.
For example:
Or
Or
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.
Q VOLUMEOPTION HULL DESIGN
Returns DESIGN data
Q VOLUMEOPTION HULL PRODUCTION
Returns PRODUCTION data
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.
!TUBING[1]
'IL TUB OF =20/302'
!TUBING[2]
'IL TUB OF =20/303'
Catalog DB
CATR
Catalog 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
CATR
Catalog 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
VAR !Array COLLECT selection criteria MAX number

VAR !PIPECOMPS COLLECT ALL BRANCH MEMBERS
VAR !LENGTHS COLLECT ALL WITH ( XLEN * YLEN 8 ZLEN GT 1000 )
VAR !VOLUME COLLECT ALL WITHIN W800N17000U0 TO W1400N13500U1200
VAR !P COLLECT ALL PIPE EXCLUSIVE WITHIN VOLUME /PUMP1 1500
>--- VOLUMEOPTION ---+--- HULL DESIGN ---.
                     |                   |
                     |                   |
                     ‘- HULL PRODUCTION -+--- ON  ---.
                                         |           |
                                         |           |
                                         ‘--- OFF ---+--->
VAR !BRANCH COLLECT ALL BRANCH MEMBERS FOR /PIPE1 /PIPE2
EXCLUDE BRAN 1 OF /PIPE2
VAR !BENDS APPEND COLLECT ALL ELBOWS
VAR !BENDS[99] COLLECT ALL ELBOWS
ENHANCE ALL WITH ( XLEN * YLEN * ZLEN GT 100 0 )
ENHANCE ALL BOX WITH ( XLEN * YLEN * ZLEN GT 100 0 )
ENHANCE ALL BOX WITH ( XLEN * YLEN * ZLEN GT 1000 ) FOR /*
VAR IPIPECOMPS COLLECT ALL BRANCH MEMBERS
IPIPECOMPS [1]  = '=20/302'
IPIPECOMPS [2]  = '=20/303'
IPIPECOMPS [3]  = '=20/304'
       .
       .
       .
IPIPECOMPS [354] = '=25/510'
VAR !FLANGES COLLECT (ALL FLANGES) FROM IPIPECOMPS
ENHANCE ALL FROM !FLANGES
ENHANCE ALL FLANGES FROM IPIPECOMPS
VAR !BENDS APPEND COLLECT ALL ELBOWS
VAR !LIST[99] COLLECT ALL SLCY
VAR !TUBING COLLECT (ALL TUBI) FOR /*
var !cln collect all EQUI
var !name evaluate (description) for all from !cln
var !name evaluate (description) for all EQUI
COLLECT ALL FROM TABLE NAME PREFIX '/B'
COLLECT ALL NOZZ WHERE (HEIGHT GT 100) FROM TABLE NAME PREFIX '/B'
VAR !COLL COLLECT ALL FROM TABLE SPRE VALUE /RF300/100G
VAR !COLL COLLECT ALL FLAN FROM TABLE SPRE VALUE /RF300/100G
VAR !COLL COLLECT ALL WHERE (SPRE EQ /RF300/100G)
VAR !COLL COLLECT ALL for /* FROM TABLE :MYTEXTATT VALUE  'fred'
VAR !COLL COLLECT ALL for /* FROM TABLE :MYTEXTATT PREFIX  'fred'
VAR !COLL COLLECT ALL FROM TABLE :MYATT VALUE 100
VAR !COLL COLLECT ALL FROM TABLE :MYATT VALUE 100 TO 110
VAR !COLL COLLECT ALL for /* FROM TABLE :MYREFATT VALUE /PIPE1
VAR !COLL COLLECT ALL for /* FROM TABLE :MYREFATT VALUE /PIPE1
Q ALL … for /*
VAR !COLL COLLECT ALL BOX FOR DB CTBATEST/DESI
VAR !COLL COLLECT ALL WHERE (SITE EQ /ATEST) FOR DB CTBATEST/DESI FROM TABLE SPRE
      VALUE /RF300/100G

VAR !COLL COLLECT ALL FOR DB CTBATEST/DESI FROM TABLE NAME PREFIX '/B'
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.
A class of elements or element types.
A class of elements or element types.
A logical expression to be satisfied at all selected elements.
A logical expression to be satisfied at all selected elements.
A physical volume in which all selected elements must lie.
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.
A point in the hierarchy below which all selected elements must lie.
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. Plant tries to apply the above criteria so that the fastest condition is applied first and the most expensive is left to last.

!Array
Class
ALL
ALL FRMW
ALL BRANCH MEMBERS
ITEMS OF EQUI /VESS1
/VESS1
( /PIPE1 /PIPE2 )
/PIPE1
/PIPE2
!PIPECOMPS
MDB
TRUE
FALSE
WITH
WHERE
VAR !LENGTHS COLLECT ALL WITH ( XLEN * YLEN 8 ZLEN GT 1000 )
XLEN
YLEN
ZLEN
!LENGTHS
volume
WITHIN
VAR !VOLUME COLLECT ALL WITHIN W800N17000U0 TO W1400N13500U1200
!VOLUME
VAR !P COLLECT ALL PIPE EXCLUSIVE WITHIN VOLUME /PUMP1 1500
/PUMP1
!P
EXCLUSIVE
Q VOLUMEOPTION HULL DESIGN
Q VOLUMEOPTION HULL PRODUCTION
Command Syntax
>--- VOLUMEOPTION ---+--- HULL DESIGN ---.
                     |                   |
                     |                   |
                     ‘- HULL PRODUCTION -+--- ON  ---.
                                         |           |
                                         |           |
                                         ‘--- OFF ---+--->
Hierarchy
FOR
append
APPEND
!BENDS
overwrite
ELBOW
!BENDS
ALL
ALL FRMW
ALL BRANCH MEMBERS
ITEMS OF EQUI /VESS1
( /PIPE1 /PIPE2 )
ALL WITH (XLEN GT 1000 )
ALL WITHIN W8000N17000U1000 TO W1400N13500U1200
ALL PIPE WITHIN VOLUME /PIPE1 1500
Note
:
!TUBING[1]
'IL TUB OF =20/302'
!TUBING[2]
'IL TUB OF =20/303'
CATR
Catalog 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
DOCREF
Cross reference DOCU elements
CATR
Catalog 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


Information is provided on changing the management, defining the comparison data, comparing the database changes and reverting elements.


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.
When and by whom an element or attribute was last modified.
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.
A complete history of the sessions in which an element or attribute has been modified.
Details of a given session.
Details of a given session.
The session number for a given date.
The session number for a given date.


Query the Last Modification to an Element or Attribute

Lets you query details of the most recent change to a given element or attribute.
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.
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.
Q --+-- LASTMod --.
    |             |
    |-- SESSMod --|
    |             |
    ‘-- USERMod --+--+-- <selatt> --.
                  |  |              |
                  |  ‘--------------+-- HIERarchy --.
                  |                 |               |
                  |                 ‘---------------+-->
                  |
                  ‘-- attribute_name -->

Q LASTMOD
Q SESSMOD
Q USERMOD
Q LASTMOD HIER
Q LASTMOD XLEN


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.
Q HISTORY DIAM
Gives all sessions in which DIAM attribute was modified.
Examples
Q HISTORY DIAM
Gives all sessions in which DIAM attribute was modified.
Q HISTORY attribute_name
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.

Q HISTORY DIAM
Note
:
Q HISTORY[2] DIAM
Note
:
attribute_name


Lets you query details of any specific session. This is particularly useful to get details of sessions listed by a HISTORY command.
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.
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.
Q --+-- SESSComment --.
    |                 |
    |-- SESSUser -----|
    |                 |
    ‘-- SESSDate -----+-- integer -->
Note:
All session queries are for the current DB.

Q SESSCOMM 58
Q SESSUSER 58
Q SESSDATE 58
Note
:


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.)
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.
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.
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.
Q SESSION ON <date>

Query Details of a Specific Session
Query Details of a Specific Session


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.


You can enter a comparison date, either for the entire Multiple Database (MDB) or an individual Database (DB). For individual DBs, you can also enter a specific session number and extract number.
SETCOMPDATE 31 March 2002
SETCOMPDATE STAMP /STAMP1
SETCOMPDATE NOW

Compares against the start values
SETCOMPDATE FOR CTBATEST/DESI to session 99
SETCOMPDATE FOR CTBATEST/DESI to EXTRACT

Compares against the parent.
SETCOMPDATE FOR CTBATEST/DESI to CTBATEST/MASTER

CTBATEST/MASTER must be up the extract hierarchy.
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.
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.
Examples
SETCOMPDATE 31 March 2002
SETCOMPDATE STAMP /STAMP1
SETCOMPDATE NOW
Compares against the start values
SETCOMPDATE FOR CTBATEST/DESI to session 99
SETCOMPDATE FOR CTBATEST/DESI to EXTRACT
Compares against the parent.
SETCOMPDATE FOR CTBATEST/DESI to CTBATEST/MASTER
CTBATEST/MASTER must be up the extract hierarchy.
-SETCOMPDATE--|---date->
              | --STAMP------name->
              ‘-FOR--DB--dbname--TO--|--date-->
                                     |--Session -int-|--|-EXTRACT--|—- int---->
                                     ‘---------------‘  ‘-->       |-- Dbname->
                                                                   ‘---------->

SETCOMPDATE 31 March 2002
SETCOMPDATE STAMP /STAMP1
SETCOMPDATE NOW
SETCOMPDATE FOR CTBATEST/DESI
SETCOMPDATE FOR CTBATEST/DESI to EXTRACT
SETCOMPDATE FOR CTBATEST/DESI to CTBATEST/MASTER


The query will return the comparison session number or extract number for a Database (DB).
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
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.
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
Q ----------|-COMPDATE-|--SESSION--|--FOR---dbname--->
VAR ‑vname--‘          |—EXTRACT---´
                       |----DATE--------->
                       ‘----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.

Q COMPDATE  EXTRACT FOR DB CTBATEST/DESI
Q COMPDATE COMPDATE SESSION FOR DB CTBATEST/DESI
Q COMPDATE DATE
Q COMPDATE STAMP
Note
:


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.
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)

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. For example, 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. for example, 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 AVEVA E3D Design PML1 expression. that means. after Q/Var and within collections. For example,

Q (BUIL OR MODIFIED() OR ELECREC OF NEXT )
                                              ‘-->
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)
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. For example, 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. for example, 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 AVEVA E3D Design PML1 expression. that means. after Q/Var and within collections. For example,
Q (BUIL OR MODIFIED() OR ELECREC OF NEXT )

Q MODIFIED()
Q MODIFIED(POS,ORI)
Q MODIFIED(P1 POS)
OFFSPRING
SIGNIF
PRIMARY
DESCENDANTS
Q MODIFIED(GEOM DESCENDANTS)
Q MODIFIED(PRIMARY)
Q MODIFIED() OF /PIPE1
Q (BUIL OR MODIFIED() OR ELECREC OF NEXT )
                                   .------------------------------------.
                                  /                                      |
>-MODIFIED-(-+--attname-------|--*--DESCENDANTS--+--+-comma--+--attname--´
             |                   |               |  |
             |--DESCENDANTS--.   |-- SIGNIFICANT-|  |
             |               |   |               |  |
             |--SIGNIFICANT--|   |--PRIMARY----- |  |
             |               |   |               |  |
             |--PRIMARY------|   |--MEMBERS------|  |
             |               |   |               |  |
             |--MEMBERS------|   ‘---------------‘  |
             |               |                      |
             |               |                      |
             |               |                      |
             ‘---------------+----------------------+--+--) ---OF --id-->
                                                    |
                                              ‘-->


Determine if an element has changed since the Comparison Date. The functionality of CREATED() is identical to using the pseudo attribute ELECREC.
Q ( CREATED() )


Determine if an element has been deleted since the Comparison Date. The functionality of DELETED() is identical to using the pseudo attribute ELEDELC.
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, for example:
Q (DELETED() of =15752/234 )
Or use it as part of the 'old' syntax. e.g.:
Q OLD (DELETED() of /VESS2)

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, for example:
Q (DELETED() of =15752/234 )
Or use it as part of the 'old' syntax. e.g.:
Q OLD (DELETED() of /VESS2)

Q ( DELETED() )-
Q (DELETED() of =15752/234 )
Q OLD (DELETED() of /VESS2)


GEOM, CATTEXT, and CATMOD Special Attributes

There are three new special attributes ‘GEOM’, ‘CATTEXT’, and CATMOD (previously called ‘CATA’).
The GEOM attribute returns true if any aspect of the evaluated geometry has changed.
The definition of evaluated geometry change includes:
This will return true if any part of the evaluated detail or material text has changed.
Special attribute CATMOD will return true if any value in the catalog has changed, for example,
Thus it is possible that the geometry element has changed but the GEOM keyword returns false, for example, a User Defined Attributes (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 catalog 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 catalog element pointed at, or any catalog 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.
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.
Any dimension of a primitive has changed
Any dimension of a primitive has changed
Any ppoint changes
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.
Pos/ori change
Specification Reference (SPREF)
Changes to a Specific Component (SPCO) element
Changes to a Piping Component (COMP) element
Changes to any Pointset Element (PTSE), 3D Geomset Element (GMSE)
Changes to any dataset elements
Changes in DTEXT, Material Text elements (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.
Specification Reference (SPREF)
Specification Reference (SPREF)
Changes to a Specific Component (SPCO) element
Changes to a Specific Component (SPCO) element
Changes to a Piping Component (COMP) element
Changes to a Piping Component (COMP) element
Changes to any Pointset Element (PTSE), 3D Geomset Element (GMSE)
Changes to any Pointset Element (PTSE), 3D Geomset Element (GMSE)
Changes to any dataset elements
Changes to any dataset elements
Changes in DTEXT, Material Text elements (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.
Changes in DTEXT, Material Text elements (MTEXT) elements

pointed at


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. For example:
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. For example:
Where /OLDPIPE no longer exists.
The ‘OLD’ syntax may also be used after ‘VAR’. This includes collections. For example:
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. For example:
There is also a pseudo attribute, DSESS. that returns the session number when an element was deleted.That means having got the deleted PIPES from the previous query, we can now find out when they were deleted.
Q OLD XLEN
Q OLD REF OF /OLDPIPE
VAR !PIPES OLD COLLECT ALL PIPES
VAR !PIPES OLD COLLECT ALL PIPES WITH ( DELETED() )


Information is provided on comparing database stats at different times and on model changes.


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:
DIFFERENCE SINCE
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.
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.
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.
>- DIFFerence <selele> SINCE -+- <date/time> -+-----------------------.
                              |               |                       |
                              |- LATEST ------|                       |
                              |               |                       |
                              |--SESSION nn --|                       |
                              |               |                       |
                              ‘---------------+- EXTRACT -+- extname -|
                                                          |           |
                                                          ‘- extno ---+->

Creation and deletion of elements.
Changes to the attribute settings of elements.
Changes in the list order for BRANCH, POGON, DRAWI and BOUND elements.
Creation and deletion of elements.
Creation and deletion of elements.
Changes to the attribute settings of elements.
Changes to the attribute settings of elements.
Changes in the list order for BRANCH, POGON, DRAWI and BOUND elements.
Changes in the list order for BRANCH, POGON, DRAWI and BOUND elements.
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.

Note
:
DIFFERENCE ALL BRANCH FOR /ATEST SINCE 21 JANUARY
DIFF CE SINCE 10:00
DIFF /ZONE
DIFF SITE SINCE SESSION 66


Model Changes provides a mechanism for exploring change and highlighting changed elements in the 3D Graphical View. On the Manage tab, in the History group, click Model Changes to display the Model Changes window.

The Model Changes window has two vertically split panes. The top pane contains a Model Explorer while the lower split contains the following tabs.
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 Multiple Database (MDB).

Element History
Clicking Element History lists the details of every database session in which the selected Current Element (CE) 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.

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.
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 representation and are in the drawlist for any active view are highlighted in colour. This uses the same customizable colour used by the Highlight element function available via right-click menu in the standard Model Explorer. Unchecking Highlight returns the graphical display to normal coloring.
All panes of the Model Changes are updated and explorer annotations and 3D graphical highlighting are reset in the following circumstances:
Following any of these operations Refresh must be clicked again in order to update the change highlighting.
.

.
.
further element changes
savework, getwork, and refresh
user or MDB switch
further element changes
further element changes
savework, getwork, and refresh
savework, getwork, and refresh
user or MDB switch
user or MDB switch
Note: T
he previous DB Changes appware is now available on the Manage tab, in the History group, clicking DB Listing.
Note:
For large models this change analysis can take some time.

Model Changes
Manage
History
Model Changes
Model Changes
Note
:
DB Changes
Manage
History
DB Listing
Model Changes

Element History
Key
Model Timeline
Stamps
Refresh
Model Timeline
Model Timeline
Stamps
Stamps
Element History
Element History
Key
Key
All Changes Since
Note
:
Only Changes At
Refresh
Highlight
Highlight element
Highlight
Model Changes
Refresh


Revert allows you to directly Revert an element or hierarchy of elements to a previous state.
Where the <comparison> syntax is similar to that following the SINCE keyword in both of the existing DIFFERENCE and OUTPUT CHANGES commands.
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:
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 Data Access Controls (DACs), then the entire revert operation is cancelled and the following error is generated.
In this case a series of warning messages is written to the console indicating the causes of the error, for example:
Element locks do not prevent a revert operation if those elements were unlocked in the previous state.
>- REVert -+- ELEment ---.
           |             |
           `- HIERarchy -+- <selele> -+- AT -----.
                                      |          |
                                      `- BEFore -+- <comparison> ->
-->-+- <date/time> -+-----------------------.
    |               |                       |
    |- LATEST ------|                       |
    |               |                       |
    |---------------+- EXTRACT -+-----------|
    |                           |           |
    |                           |- extno ---+
    |                           |           |
    |                           '- extname -+
    |                                       |
     `- STAMP - <name> ---------------------+->
REVERT HIER /EQUIP AT LATEST
REVERT HIER /EQUIP BEFORE LATEST
REVERT ELE /E1301 AT 20:16 26 / 3 / 2010
REVERT HIER /PIPES AT STAMP /StampMilestone7
REVERT HIER CE AT EXTRACT
(43,615) Cannot Revert elements. No changes have been made.
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
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.

>- REVert -+- ELEment ---.
           |             |
           `- HIERarchy -+- <selele> -+- AT -----.
                                      |          |
                                      `- BEFore -+- <comparison> ->
<comparison>
SINCE
DIFFERENCE
OUTPUT CHANGES
-->-+- <date/time> -+-----------------------.
    |               |                       |
    |- LATEST ------|                       |
    |               |                       |
    |---------------+- EXTRACT -+-----------|
    |                           |           |
    |                           |- extno ---+
    |                           |           |
    |                           '- extname -+
    |                                       |
     `- STAMP - <name> ---------------------+->
BEFORE
/EQUIP
/EQUIP
/E1301
/PIPES
(43,615) Cannot Revert elements. No changes have been made.
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
Note
:
REVERT <database name>


Information is provided on the multiple database mode, on how to check current user status and system status and on how to list project information and how query multiple database.


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 Multiple Database (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 for further information.
MDB UPDATE
Save design changes and enter MDB Mode.
MDB NOUPDATE
Enter MDB Mode without saving design changes.
EXCHANGE
DEFER
CURRENT
Alter the databases in the current list of the current MDB
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 MODEL Mode.
Examples
MDB UPDATE
Save design changes and enter MDB Mode.
MDB NOUPDATE
Enter MDB Mode without saving design changes.
EXCHANGE
DEFER
CURRENT
Alter the databases in the current list of the current MDB
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 MODEL Mode.
>-- MDB --+-- UPdate ----.
          |              |
          ‘-- NOUPdate --+-->

MDB Mode

MDB UPDATE
MDB NOUPDATE
EXCHANGE
DEFER
CURRENT
PROTECT
USER username
PROJECT code
LIST
/PIPING
/PIPING READONLY
EXIT


Gives you information about your current status as a user and about the Databases (DBs) to which you have access.
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 AVEVA E3D Design 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 Multiple Database (MDB) called /MODEL.
If INFO is specified then a line of text explains the reason for the database access mode differing from expectation. For example:
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
>-- STATus -+---------------->
            |
            ‘- INFOrmation -->

not integrated
current product has limited access
database not allocated to this location
not integrated
not integrated
current product has limited access
current product has limited access
database not allocated to this location
database not allocated to this location

Project: XYZ
User:    CSI (758)
Teams:   B
MDB:     /DESIGN
Current DBS:
  1  PIPING/SITE                       RW
  2  MASTER/CATLOG                     R
Deferred DBS:
  3  STRUCT/STEEL


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.
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 AVEVA E3D Design for work on Project XYZ. The Project Coordinator is using Admin but is not accessing any databases. User 752 is using Model. He is accessing the Multiple Database (MDB) named /STEEL, whose constituent Databases (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.
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
>-- SYStat -->

SY
STAT
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


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 AVEVA E3D Design Admin.
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
 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.
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
 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
             .----<----.
            /          |
>-- LIst --*-- USers --|
           |           |
           |-- MDBs ---|
           |           |
           |-- DBs ----|
           |           |
           |-- TEams --’
           |
           ‘-------------->

 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
 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**
 List of USERS for project ZZZ
===============================
SYSTEM   (FREE)
TEAMS :MASTER   STAB

Z        (FREE)
TEAMS :***NONE**

GEN      (GENERAL)
TEAMS :TEST


Lets you query details of the current Multiple Database (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.
>-- Query --+-- USer      ---.
            |                |
            |-- USer word ---|
            |                |
            |-- TEam word ---|
            |                |
            |-- DB dbname ---|
            |                |
            ‘-- MDB name ----+-->

List Project Information
List Project Information


Lets you query details of the current DB for a given element.
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
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
>-- Query --+-- DBNAme -----.
            |               |
            |-- DBTYpe -----|
            |               |
            |-- DBFNumber --|
            |               |
            ‘-- DBFIle -----+-->

Q DBNAME
Q DBTYPE
Q DBFNUMBER
Q DBFILE


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.


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.


There are several element types used for organizing links and storing link information. All kinds of elements may be created using standard AVEVA E3D Design command syntax.


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 MODEL database of its own to which all relevant teams have read and write access.


Under Link Worlds it is possible to organize 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.


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:
The following pseudo attributes may be queried:
NAME - user-defined name of the LNDESC element.
DESC - description of the element.
LNKURL - a string storing raw Uniform Resource Locator of the linked document.
NAME - user-defined name of the LNDESC element.
NAME - user-defined name of the LNDESC element.
DESC - description of the element.
DESC - description of the element.
LNKURL - a string storing raw Uniform Resource Locator of the linked document.
LNKURL - a string storing raw Uniform Resource Locator of the linked document.
LNKREF - if the Link Descriptor holds a reference to an internal database element,that means,. 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.
LNKREF - if the Link Descriptor holds a reference to an internal database element,that means,. 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.
LNKREF - if the Link Descriptor holds a reference to an internal database element,that means,. 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.
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.
LNKCLS - list of Link Class elements that classify this Link Descriptor.
LNKELE - list of elements that have this Link Descriptor assigned.
LNKELE - list of elements that have this Link Descriptor assigned.


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:
There is also a pseudo attribute available named LNKDOC that returns a list of LNDESC elements that are classified by this LNCLAS.
NAME - user-defined name of the LNCLAS element.
DESC - description of the element.
NAME - user-defined name of the LNCLAS element.
NAME - user-defined name of the LNCLAS element.
DESC - description of the element.
DESC - description of the element.


Link Documents functionality is available through the command line. Standard AVEVA E3D Design 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.


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.


To add a link between an element and a document (or an external resource):
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:
The DLADD command can be used to add links from a document to one or more other elements. The command syntax is:
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:
If current element is a Link Descriptor (LNDESC) named /MYDOC1 the following command assigns this Link Descriptor to /PANEL1 and /PUMP1:
The whole process of linking a document to /PUMP1 might look like this:
>--- DLADD -------*-- <selatt> -----+------>
> DLADD /MYDOC1 /MYDOC2
> DLADD /PANEL1 /PUMP1
> NEW LNDESC /MYDOC
> URL 'http://aveva.com/all_about_vm12_link_documents.pdf'
> DLADD /PUMP1


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:
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:
If current element is a Link Descriptor (LNDESC) named /MYDOC1 the following command removes link to document described by this Link Descriptor to /PUMP1:
The following command removes all Link Descriptor associations from the current element:
The following command removes the first five Link Descriptor associations from the current element:
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:
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:
You can use the LNKREF to set link to an internal database reference for example, a drawing:
                    ----------------+
                   /                |
>--- DLREMove ----*-- <selatt> -----+------>
> DLREM /MYDOC1
> DLREM /PUMP1
> DLREM LINks
> DLREM LIN 1 TO 5
> URL 'file:///Docsys/MyDocument.doc'
> QUERY LNKREF
> LNKREF /DRAWING1
> QUERY LNKREF
Url DBRef / DRAWING1


Each Link Descriptor can have a number of Link Classes assigned. To classify a link:
If current element is a Link Descriptor (LNDESC) named /MYDOC1 the following command classifies this Link Descriptor as a /MYCLASS1 and /MYCLASS2 document:
If current element is a Link Class (LNCLAS) named /MYCLASS1 the following command classifies a Link Descriptor named /MYDOC1 as a /MYCLASS1 document:
> DLADD /MYCLASS1 /MYCLASS2
> DLADD /MYDOC1


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:
If current element is a Link Class (LNCLAS) named /MYCLASS1 the following command removes /MYCLASS1 classification from the /MYDOC1 Link Descriptor:
The following command removes all Link Descriptor associations from the current Link Class:
The following command removes all classification information from the current Link Descriptor:
> DLREM /MYCLASS1
> DLREM /MYDOC1
> DLREM LINks
> DLREM CLAsses


A number of pseudo attributes allow retrieval of information on the relation between Link Descriptors (LNDESC), Link Classes (LNCLAS) and model elements:


The Link Addin is a customizable 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 you are 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.

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.

The Link Addin can be customized through a set of API’s, refer to for further information.

OK
OK


Access to a DB is usually controlled in such a way that only one user can modify the content of that Database (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 Tail Reference (TREF) of their Branch (which they can not do), thus:

$M /%ABCMAC%/abc001.mac
DELETE MACRO 1
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).
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 MODEL 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 Model, Monitor and Admin.
User P sets the TREF of their Branch to point to the CREF of the Nozzle in the Equipment DB.
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).
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).
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.
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 MODEL 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 MODEL and runs the inter-DB connection macro by giving the command
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 Model, Monitor and Admin.
User E enters MONITOR (or ADMIN if they have sufficient access rights) and deletes the redundant macro by giving the command
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 finalize 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.

one
Write
Read
inter-DB connection macro
Project ABC
User P
User E
not
abc001.mac
ABCMAC
Note
:
Note
:


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, for example, TEST123, where TEST is the name of the sequence and 123 is the running number.


A name sequence database, of the type NSEQ, is created by the Admin utility and selected to an Multiple Database (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.


import 'aveva.model.nameseq'
using namespace 'aveva.model.nameseq'

aveva.model.nameseq
aveva.model.nameseq


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).
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

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).
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


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, for example,. 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.

Next


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, for example,. SetStart() to a number different for each site.


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
Possibility to Distribute an Objects Attributes across Hierarchies and Databases
Simplified Access Control
Data Inclusion/Exclusion
User Extendibility on New and Existing Data
Automatic Attribute Management

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.
Users may work on different sets of data of an object in parallel.
Users may work on different sets of data of an object in parallel.
Support simultaneous multi-discipline update on same object.
Support simultaneous multi-discipline update on same object.
Claim granularity, only claim relevant portions of an object.
Claim granularity, only claim relevant portions of an object.
Easy distribution over Global dividing distributed attribute over different primary locations.
Easy distribution over Global dividing distributed attribute over different primary locations.
Easy distribution over Global dividing distributed attribute over different primary locations.
Team owning databases provides both read/write and read-only levels of access within the same object.
Team owning databases provides both read/write and read-only levels of access within the same object.
Team owning databases provides both read/write and read-only levels of access within the same object.
Possible to hide select portions of an object.
Possible to hide select portions of an object.
Possible to hide select portions of an object.
In cases where it is hard to define User Defined Element Types (UDETs) this is an alternative way to extend existing objects with distributed attribute data.
In cases where it is hard to define User Defined Element Types (UDETs) this is an alternative way to extend existing objects with distributed attribute data.
In cases where it is hard to define User Defined Element Types (UDETs) this is an alternative way to extend existing objects with distributed attribute data.
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:
The management (create/delete/referencing) of the distributed attributes.
The management (create/delete/referencing) of the distributed attributes.
While the concept itself is rather straightforward, it introduces new possibilities to applications.
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:
An pictoral representation of how the concept might be used in an application, follows:

Improved Concurrency
Possibility to Distribute an Objects Attributes across Hierarchies and Databases
Simplified Access Control
Data Inclusion/Exclusion
User Extendibility on New and Existing Data
Automatic Attribute Management


Distributed attributes are built on top of the well established functions and concepts of AVEVA E3D Design technology. The functionality of distributed attributes User Defined Attributes (UDAs) and User Defined Element Type (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 you.
An pictoral representation of how the components relate to each other is displayed below:

Term
Description
Binding element
The owner of distributed attributes groups.
Distributed element / attribute group
The container for distributed attributes these can be thought 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.
Binding element
The owner of distributed attributes groups.
Distributed element / attribute group
The container for distributed attributes these can be thought 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.
Term
Description
Binding element
The owner of distributed attributes groups.
Distributed element / attribute group
The container for distributed attributes these can be thought 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.

UDA
UDET
UDET
XPITEM
UDET
UDET
UDA
Binding element
Distributed element / attribute group
Distributed attribute
Default home


Distributed attributes are made up of User Defined Element Type (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.
Create UDETs to be used as distributed attribute groups.
Create UDETs to be used as distributed attribute groups.
Create the attributes to be included in the attribute groups.
Create the attributes to be included in the attribute groups.
Create distributed attribute schema associating elements with the distributed attribute group.
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 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.
Create actual default home top level elements where distributed attribute groups are created.


Create Distributed Attribute Group, the UDET

The task only differ from creating a regular User Defined Element Type (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.
You 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.


The attributes can be defined as any regular User Defined Attribute (UDA), no special considerations need to be taken.
For example: the UDAs, to be included in the attribute groups.


The distributed attribute schema, associating elements with the distributed attribute group must then be created.
There are two administrative levels, Distributed Attribute Definition World (DSXWLD) and Distributed Attribute Group (DSXGRP) that is left without any specific explanation. They serve the same purpose of grouping things, that is schemas, UDAs together. Distributed attributes schemas are configured using the Distributed Attribute Schema (DSXSCH), Distributed Attribute Owner (DSXOWN) and Distributed Attribute Member (DSXMBR) objects in the lexicon application.

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.

You 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.

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.


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.
Each Default home definition is represented by a Distributed Attribute Default Home (DSXHOM) element the element must be referenced from distributed attributes, for example: Distributed Attribute Schema (DSXSCH) (where to store elements).

You 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.

Enables more elaborate tests, logical expressions can be defined and inserted between the Distributed Attribute Default Home (DSXHOM) and the final destination.

Note:
That the tests on the logical expressions has not yet implemented.

Note
:
Default Home


For each unique destination Distributed Attribute Destination (DSXDST) defined, the corresponding actual XPIWLD home‑element must be created. For example:
NEW XPIWLD /MyLineLists

XPIWLD


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.
the structure of the attributes
the structure of the attributes
where to physically create and store the data.
where to physically create and store the data.


Distributed Attributes and Default Home Configuration

The distributed attributes definition is created in the Lexicon module and stored in a Dictionary (DICT) database. The detail information of each attribute relies on the existing definitions of User Defined Attributes (UDAs) and User Defined Element Type (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).


The hierarchy where this information is stored is organized the following way:

The common DSX data structure that contains both distributed attributes and default home definition.
The Distributed Attribute Definition World (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 Distributed Attribute Group (DSXGRP) as members.
NAME
Text
Standard
DESC
Text
Standard
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.
NAME
Text
Standard
DESC
Text
Standard

Attribute Name
Type
Usage
NAME
Text
Standard
DESC
Text
Standard
Attribute Name
Type
Usage
NAME
Text
Standard
DESC
Text
Standard

DSXWLD
DSXGRP
DSXGRP
DSXGRP
DSXSCH
DSXHOM


A distributed attribute schema is headed with a Distributed Attribute Schema (DSXSCH) element. Currently there is no particular support or use of multiple schemas but to organize distributed attributes in groups of definitions.
The DSXSCH defines a distributed attribute schema the vital attribute is the Default Home (DEFHOM) that may contain a reference to a schema default Distributed Attribute Default Home (DSXHOM) element. The DSXSCH element can have DSXOWN as members.
NAME
Text
Standard
DESC
Text
Standard
DEFHOM
Ref to DSXHOM
Identifies the default home selector for this schema
The Distributed Attribute Owner (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 Element List (ELEL) attribute. It also contains an optional reference to a binder default DSXHOM element, that DSXHOM overrides any DSXHOM definition on the DSXSCH level. The DSXOWN element can have Distributed Attribute Member (DSXMBR) as members.
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
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 User Defined Element Types (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.
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)

Attribute Name
Type
Usage
NAME
Text
Standard
DESC
Text
Standard
DEFHOM
Ref to DSXHOM
Identifies the default home selector for this schema
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
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)

DSXSCH
DSXSCH
DEFHOM
DSXHOM
DSXSCH
DSXOWN
DSXOWN
DSXOWN
ELEL)
DSXHOM
DSXHOM
DSXHOM
DSXSCH
DSXOWN
DSXMBR
DSXMBR
DSXMBR
ELEL
XPITEM
DSXHOM
DSXHOM
DSXOWN