E@DBUPDATE
Name
The E@DBUPDATE call has the following format:
DN@<Logical>(E@DBUPDATE)
where <Logical> identifies the database file to use to perform the E@DBUPDATE call.
Description
E@DBUPDATE directly updates a single existing record in a file. It combines the actions of the E@DBLOCKEQ and E@DBSTORE routines into a single call. Use this routine when you already know that a record exists, such as when you have already inquired on or modified a record in a previous call.
Using the API in a Program
The performance advantage derived from this reduction in the number of calls brings with it a pair of requirements.
You must enter a value in all D@ fields before performing the routine, because this routine can update the key fields in the index, just as the E@DBLOCKEQ routine does.
You must populate all record fields, unlike the E@DBLOCKEQ routine. This requirement must be enforced because the E@DBUPDATE routine replaces the entire existing record with the contents of all the record fields, even if one or more of them are empty.
Input Values
Field | Description |
---|---|
<Logical> | You must specify the database index name that you want to create a record in. |
Record retrieval variables (also known as D@ fields) | You must populate the index key fields used to locate the record before using this call. |
Return Values
Field | Description |
---|---|
D<prefix>@NOTFOUND - or - E@KEY@FOUND |
The Modify routines set D<prefix>@NOTFOUND to FALSE if a record is found, TRUE if a record is not found, or E@KEY@FOUND if the keys are found. |
Programming Example
The following example shows the same process as the previous example for the E@DBLOCKEQ routine, but using the E@DBUPDATE call to alter a record. The record has already been retrieved using a Find call.
|
This example shows the same change being made as in the previous example for the E@DBLOCKEQ call. The major differences are that you only use a single call, and you populate the D@ fields and record fields before calling the E@DBUPDATE routine.
In this case, you must be certain that the S1@MVDT fills all of the record fields. If it does not, any unfilled record fields cause the E@DBUPDATE call to overwrite the corresponding file fields with the initialization values.