ADELIA |
VADELIA |
|
WADELIA |
|
(I) |
(I) (S) |
(I) (S) |
Section for use
All
Syntax
STORE ViewName SeriesTransactionNum Parameter
STORE ViewName SeriesWindowNames Parameter
SeriesTransactionNum |
→ |
SeriesTransactionNum TransactionNum |
| None |
||
SeriesWindowNames |
→ |
SeriesWindowNames WindowName |
| None |
||
Parameter |
→ |
*NO_MR | *MR | None |
Description
This instruction is used for either the creation or update of a file, only for the fields associated with a view ViewName by the data flow, on a screen transaction.
With VADELIA programs, this instruction stores window names instead of transaction numbers.
It performs the same operations as the PLACE and CLASSIFY instructions combined.
This instruction reads the file record linked to the view ViewName by the data flow, and:
If the record exists:
First, screen data is transferred to the corresponding file fields (linked by the data flow).
Then, the record is updated.If the record does not exist:
First, the file fields are reset to blank, zero or *LOVAL and the screen data is transferred to the corresponding file fields (linked by the data flow).
Then, the record is created.
Note: in the case of ADELIA programs, records will only be created if the attribute "Create record" has been activated in the view.
The transaction numbers are optional. The system takes all the screen fields found in the transactions specified in the instruction or, by default, the transaction corresponding to the validation block where the instruction is, and generates the file field loading instructions.
Important note: If the file associated with the view is defined with a non-unique key, the record reading is performed by direct access (the system saves the sequence number when reaching PRESENT (Adelia or Visual Adelia and Adelia Web context)).
See the message "System Error CPF4101".
The *MR parameter allows you to generate read, update and creation implicit management rules that are linked to the entity corresponding to the view, even if the program is generated without the option to generate implicit management rules.
The *NO_MR parameter allows you not to generate read, update and creation implicit management rules that are linked to the entity corresponding to the view, even if the program is generated with the option to generate implicit management rules.
Example
******************
VALIDATION 02
******************
STORE CUSTOMERS
* This has the same effect as the following lines:
******************
VALIDATION 02
******************
PLACE CUSTOMERS
CLASSIFY CUSTOMERS
* as well as the instructions:
CHAIN CUSTOMERS
IF CUSTOMERS DOES_NOT_EXIST
INIT_FIELDS CUSTOMERS
END
BRING_BACK CUSTOMERS
IF CUSTOMERS EXISTS
UPDATE CUSTOMERS
ELSE
CREATE CUSTOMERS
END
*