Update rule

The Update rule allows editing/updating attributes that are not stored in any of the base tables of a Transaction object.

Given a Transaction level, the only attributes that can be edited are the ones stored in the Base Table of the level. For example, in an Invoice Transaction, you can have the CustomerName in the form, but it isn't editable; the only Customer attribute that can be edited in the Invoice form is CustomerId because it is stored in the Invoice table.

The Update() rule is introduced in case the developer needs to edit CustomerName anyway in the Invoice form. 

Syntax

Update(att1, ..., attn);

where:
att1, ..., attn: attributes belonging to the Extended Table.

This rule is unconditional. Therefore, to conditionally allow editing of a particular attribute you should combine it with the NoAccept rule.

Example

This example explains the canonical use of the Update rule. We have a Customer transaction, and inside it, an attribute called CustomerAddressLastShipment. And we have an Invoice Transaction too, as shown below.

Invoice
{
    InvoiceNumber*
    InvoiceDate
    CustomerId
    CustomerName
    CustomerRUT
    CustomerAddressLastShipment
    InvoiceLastNumber
    }
         ProductId*
         ProductDescription
         ProductPrice
         InvoiceLineQtty
         InvoiceLineTotal
    }
}

Customer
{
    CustomerId*
    CustomerName
    CustomerRUT
    CustomerAddress
    CustomerAddressLastShipment
    CustomerMail
    CustomerBalance
    CustomerPhone
}

The CustomerAddressLastShipment attribute is inferred from the Customer table and it is displayed on the screen in a read-only mode. However, the shipping address could change; in this case, the rule can solve it.

Update(CustomerAddressLastShipment);

The operator may change the address, and this new information will be stored in the Customer table.

Considerations

• Transactions may have either one or more Update rules. There is no preferred method for writing them.

• No errors or warnings are raised for this rule (i.e. reference to attributes that can already be accepted).

• Some considerations about the rule's behavior in Update mode:

If the foreign key determining the inferred attribute can be changed (i.e. it does not belong to the primary key of the base table) and it is changed in different transactions (work units), the value of the inferred attribute for the "original" foreign key value is not restored. An example may clarify the concept:

Suppose we have two Transactions: Customer and Invoice, which are related. CustomerCod is a FK in the Invoice and it has this rule:

Update(CustomerName);

It has an Invoice #1 with CustomerCod = 1 whose CustomerName = "Customer_x". The CustomerName value is changed (in fact, CustomerName is updated in the Customer's table) in Invoice #1 to "Customer_new" and the Invoice is confirmed.

After that (in a new LUW) the CustomerCod for invoice #1 is changed to another value, for example, CustomerCod = 2. This change doesn't means the Customer #1 Name is restored to its original value.

Scope