|
The Get Next Extended operation (B_GET_NEXT_EXTENDED) examines one or more records, starting at the logical next position and proceeding toward the end of the file, based on the specified key. It checks to see if the examined record or records satisfy a filtering condition, and it retrieves the ones that do. The filtering condition is a logic expression and is not limited to key fields only.
Get Next Extended can also extract specified portions from records and return only those portions to an application.
The following table shows the structure of the input data buffer.
|
Element
|
Length (in Bytes)
|
Description
|
|---|---|---|
|
Header
|
2
|
Total length of the Data Buffer.
|
|
2
|
One of two string constant values (fixed length, do not null-terminate):
"EG"-Begin with the record after the one at which you are positioned. "UC"-Begin with the record at which you are positioned.
For Step Next Extended operations, always set this value to "EG".
|
|
|
Filter (Fixed Portion)
|
2
|
Maximum Reject Count, which is the number of records that the transactional interface can skip while searching for records that satisfy the filter condition. You can set the value from 0 to 65,535. (0 means the transactional interface uses the system-defined maximum reject count, which is 4,095.)
|
|
2
|
Number of Terms in the logic expression of the filter condition. (0 means the transactional interface performs no filtering.) The only limit to the number of terms is the size of the data buffer. In Pervasive.SQL 2000i SP3 only, the limit for the number of terms is 119.
|
|
|
Filter (Repeat this segment once for each term in the logic expression)
|
1
|
Data Type of the field. Use one of the codes shown in Table 2-4.
|
|
2
|
Field Length.
|
|
|
2
|
Field Offset (zero relative).
|
|
|
1
|
Specifies a Comparison Code:
1-Equal 2-Greater than 3-Less than 4-Not equal 5-Greater than or equal 6-Less than or equal
Add a +8 bias to compare strings using one of the file's existing ACSs.
Add a +32 bias to compare strings using the file's default ACS, which is the first ACS defined in the file. If you use both a +8 bias and a +32 bias, the +32 bias is ignored.
|
|
|
Add a +64 bias if the second operand is another field of the record, rather than a constant.
Add a +128 bias to compare strings without case sensitivity.
|
||
|
1
|
Indicates an AND/OR logic expression:
0-Identifies the last term 1-Next term is connected with AND 2-Next term is connected with OR |
|
|
2 or n
|
When comparing two fields: a 2-byte, zero-relative offset to the second field. (The second field must be the same type and length.)
or When comparing a field to a constant: the actual value of the constant. The length of the constant (n) must equal the length of the field. |
|
|
0, 5, 9, or 17
|
When specifying an ACS by name (bias +8), the ACS identifier using one of the name formats shown in Table 2-5.
|
|
|
Descriptor (Fixed Portion)
|
2
|
Number of Records to retrieve. To retrieve only one record instead of a set of records, specify 1.
|
|
2
|
Number of Fields to extract from each record.
|
|
|
Descriptor (Repeat this segment for each extracted field)
|
2
|
Field Length to extract.
|
|
2
|
Field Offset (zero relative).
|
The transactional interface interprets the AND and OR operators used in a filter with the extended Get and Step operations in strict left-to-right order. The transactional interface evaluates an expression in the filter and proceeds as follows:
The search for records stops if any one of the following conditions is met:
To get the next entire record that satisfies the filtering condition, set the filter portion as desired and set the descriptor fields as follows:
To retrieve the next 12 records without using a filtering condition and extract 4 fields from each record, set the filter Number of Terms to 0 and set the descriptor fields as follows:
When retrieving one or more fields (portions) of records with an extended operation, you must ensure that the Data Buffer can accommodate the information that the operation returns.
Table 2-15 illustrates the structure of the Data Buffer that the transactional interface returns.
If all returned records (or fields of records) are fixed length, your application can easily calculate the location of data within the returned Data Buffer. However, your application may need to perform extra steps to extract the variable-length portion of records from the Data Buffer that an extended operation returns.
The transactional interface does not pad any record image in the returned Data Buffer when returning the variable-length portion of a record. Consequently, if you allow room in the returned Data Buffer for the maximum number of bytes that the variable-length portion of a record could occupy, but the actual data returned is less than that maximum, the transactional interface starts the field description for the next returned field immediately following the data for the current field.
For example, suppose your fixed-record length is 100 bytes, your variable-length portion is up to 300 bytes, and you want to return just the variable-length portion of 5 records. You would use the descriptor element of the input buffer to set a Field Length of 300 and a Field Offset of 100. For the returned buffer, you need 2 bytes for the Number of Records plus 306 bytes for each record (that is, 2 bytes for the length, 4 bytes for the address, and 300 bytes for the data), as shown in the following calculation:
However, suppose that the variable-length portion of the first record returned contains only 50 bytes of data. This means the 2-byte length for the second record returned is stored at offset 58 in the Data Buffer, immediately following the image of the first record's field. In such a situation, your application must parse the length, position, and data from the Data Buffer that the transactional interface returns.
If the Get Next Extended operation is successful, the transactional interface returns the following:
If the Get Next Extended operation is unsuccessful, the transactional interface returns one of the following status codes:
It is possible for the transactional interface to return a nonzero status code and also return valid data in the Data Buffer. In this case, the last record returned may be incomplete. If the Data Buffer Length parameter returned is greater than 0, check the Data Buffer for extracted data.
If a field can only be partially filled because the data buffer is too short, then the transactional interface returns what it can of the record to and including the partial field. If the partial field is the last field to be extracted, then the transactional interface continues the operation. Otherwise, the transactional interface aborts the operation and returns a Status Code 22.
For example, consider a Get Next Extended operation that retrieves 3 fields from 2 variable-length records. The first record is 55 bytes long and the second is 50 bytes long. The Data Buffer allows 50 bytes for return data. The 3 fields to be retrieved are defined as follows:
When the transactional interface performs the Get Next Extended operation, it returns the first record without any problem. However, when attempting to extract field 2's 10 bytes from the second record, the transactional interface finds that only 5 bytes are available (between offset 45 and the end of the record, at offset 49). At this point, the transactional interface does not pad the missing 5 bytes of field 2, and thus cannot extract field 3. Instead, the transactional interface returns Status Code 22 and places all of field 1 and the first 5 bytes of field 2 in the return Data Buffer.
Depending on the fields and the operators used in the filtering condition, the transactional interface may be able to optimize your request. After reaching a certain rejected record, it returns Status Code 64, indicating that no records can satisfy the filtering conditions in the rest of the file.
The Get Next Extended operation establishes the complete logical and physical currencies. The last record examined becomes the current record. This record can be either a record that satisfies the filtering condition and is retrieved, or a record that does not satisfy the filtering condition and is rejected, but is still not past the optimization limit. For example, if the extended operation returns status 9, the current record is that last record in the file. If status 60 (reject count reached) is retuned, then the current record is the last record rejected. If status 64 (Filter Limit Reached) is returned, then the current record is the last record that satisfies the optimization criteria. Even thought the transactional interface had to look at the next record after this to determine that the optimization limit was exceeded, it sets the current record back to the previous record that did satisfy that criteria.
Note
The transactional interface does not allow Delete or Update operations after a Get Next Extended operation. Because the current record is the last record examined, there is no way to ensure that your application would delete or update the intended record.
|
Chapter contents
Prev topic: Get Next (6)
|