GeneXus 9.0 Upgrade Course
Given a transaction level, the only attributes that can be editable are the ones stored in the BaseTable of the level. For example in an Invoice transaction, you can have the CustomerName in the form, but it isn't editable, the only attribute of the Customer that can be edited in the Invoice form is the CustomerId because its stored in the Invoice table.
The new rule Update() is introduced for the case the developer needs to edit the CustomerName anyway in the Invoice form. This example seems to be a not very common one, but there is one case where this rule is more applicable: in the form of a subtype of another transaction. For example if you have Party and Client, where Client is a subtype of Party, and ClientName is a subtype of PartyName , you want to change the ClientName directly in the Client form. In this case the rule Update(ClientName); will do the trick.
The Update rule allows editing/updating attributes that are not stored in any of the base tables of a transaction.
The syntax is as follows:
Update( att1, ..., atti );
where:
att1, ..., atti: 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.
Party Transaction
Party*
PartyName
Customer Transaction
Customer* subtype of Customer.Party
CustomerName subtype of Customer.PartyName
Rules: Update( CustomerName);
The above example shows how to make the CustomerName editable in the Customer transaction even this attribute isn't stored in the Customer table (in fact it's an inferred one, and its supertype PartyName is store in the Party table). The expected behavior is that CustomerName attribute is editable in the Customer transaction.
The Navigation report shows tables that are updated through this rule.
- 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 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 (units of work) then, 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 related. CustomerCod is a FK in the Invoice and it has the rule: Update(CustomerName)
It has an Invoice #1 with CustomerCod = 1 whose CustomerName = "Customer_x".
The CustomerName value is changed (in fact the CustomerName is updated in Customers Table) in the Invoice #1 to "Customer_new" and the Invoice is confirmed.
After that (in a new LWU) 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.
Objects: Transactions
Languages: All
Interfaces: Web, Win