Claiming

When a user working on an extract database creates or modifies an element, it is claimed out to the extract. This is known as an extract claim. Once an element is claimed to an extract, user claims are made in the same way as in any other multi-write database.

An element must be claimed to an extract before a user claim can be made (in implicit mode, this happens automatically).

Only primary elements can be claimed.

• If an element is claimed to an extract, only users with write access to the extract will be able to make a user claim and start work on the element.

• Once a user has made a user claim, no other users will be able to work on the elements until they are released, as in a normal multi-write database.

• If a user releases an element, it will remain claimed to the extract until the extract claim is released.

  Note:
  Changes made in the extract are written back to the parent database, without the normal AVEVA base products requirement for the parent database to be in the current Multiple Database (MDB).

The EXTRACT CLAIM command works up through the extract levels, claiming as necessary: the user does not need to claim each level of extract separately. For example, consider the following three-level extract:

If the current claim is on the AsBuilt extract, an element claim is propagated down through the Approved extract to the Design extract; that is, the element is claimed from the AsBuilt to the Approved, and then from the Approved to the Design extract. The sequence is:

Is element already claimed to Design?

• If Yes: Do nothing.

• If No: Is element claimed to Approved extract?

  • If No: claim from AsBuilt to Approved, then claim from Approved to Design.

  • If Yes: claim from Approved to Design.

The extract claim may fail for similar reasons to a user claim failure; that is:

1. Another user/extract has the item claimed.

2. The element is modified in a later version, so that a refresh is needed first.

The implicit/explicit claim modes, as determined by the Database (DB) setting, apply to both user and extract claims. For extract claims, the claim mode is tested for each extract level in the hierarchy from which the claim is made. If the claim mode on an extract is explicit, then implicit claims which require a claim from that extract will fail. Thus if, in the preceding example, the Design and Approved DBs are set to implicit claim mode, an implicit claim will be attempted as soon as a user modifies any unclaimed element. The following sequence applies:

3. A user claim is attempted from the Design DB.

4. If the user claim fails because the element has not been claimed in the Design DB, then an extract claim is attempted from the Approved DB to the Design DB. Since the Approved DB is also in implicit mode, this is attempted automatically.

5. If the extract claim fails because the element has not been claimed in the Approved DB, then an extract claim is attempted from the AsBuilt (Primary) DB to the Approved DB. Since the AsBuilt DB is not set to implicit claim mode, the operation will fail.

In the standard case, there are always two parts to a claim or release; for example, a claim 'from' the parent extract 'to' its child extract.

Every time a claim (or release) is made, the underlying DB is accessed. To minimize such access, and thus speed up the process, it is best to claim as many elements as possible in a single operation. A convenient way of doing this is to build an AVEVA base product 'collection' and then claim the elements from there; for example:

EXTRACT CLAIM ALL FROM !COLLECT