OPEN CURSOR
After the OPEN CURSOR statement, the database cursor is positioned in front of the first line of the result set.
FETCH
This statement extracts the requested rows (using the addition INTO or APPENDING) from the results set of the database cursor from the current cursor position and assigns these rows to the data objects specified in the results set. If an internal table is specified after INTO or APPENDING, then either all rows are extracted, or as many as specified in the addition PACKAGE SIZE. The statement FETCH moves the position of the database cursor by the amount of extracted lines to the next line to be extracted.
I wrote a very simple report validation:
Source code:
OPEN CURSOR lv_cursor FOR SELECT product_guid FROM comm_product.
FETCH NEXT CURSOR lv_cursor INTO TABLE lt_selection PACKAGE SIZE size.
Size = 1: At this time, it is observed from ST05 that the total number of scanned records in the table COMM_PRODUCT is 1447.
The second execution with size = 100, PREPARE and OPEN directly become REOPEN, but recs is still 1447.
Press F1 for the field Recs in ST05 to view the description:
How did this 1447 come about? Because I did not specify any conditions when I OPEN CURSOR, when I OPEN CURSOR, the DB regards all the records of the entire product table as a result set, and then only returns the number of the specified package size.
So the Recs seen in ST05 refers to the number of records that meet the conditions specified by OPEN CURSOR, not the number of records that are finally returned to the ABAP layer.
In my test system, the table COMM_PRODUCT contains a total of 1447 records.
Then I generate 3 new products, and there are 1450 entries in COMM_PRODUCT.
Repeatedly execute the test report. ST05 found that the number of scanned records has become 1450, proving our conclusion is correct.
Do another verification: the table COMM_PRODUCT contains 3 records whose prefix is JERRY06152012:
Modify the above test report and add a WHERE query condition:
OPEN CURSOR lv_cursor FOR SELECT product_guid FROM comm_product
WHERE product_id LIKE 'JERRY06152012%'.
The first execution size = 1
Recs becomes 3, because there are only 3 records matching the OPEN CURSOR condition
Size = 100, ST05 results are exactly the same as size = 1, both are 3.
in conclusion
The Maximum Number of Results (referred to as Max hit) on the WebClient UI cannot control the number of records that the OPEN CURSOR searches in the DB each time. This number is determined by the WHERE CONDITION that follows the OPEN CURSOR. Max hit can only control how many items are returned to ABAP in the result set determined by WHERE CONDITION of OPEN CURSOR.
Through the verification above, this understanding is wrong.
OPEN SQL's select also has a function of UP TO XX ROWS.
Test with the following code:
SELECT product_guid INTO CORRESPONDING FIELDS OF TABLE lt_line FROM comm_product UP TO num ROWS.
Num = 1
Num = 143
Explain that SELECT UP TO XX ROWS can control how many records are processed in the database table.
However, SELECT UP TO XX ROWS cannot be executed repeatedly in the WHILE loop like OPEN CURSOR. It does not have a mechanism like OPEN CURSOR, which enables it to remember the position of the currently operating record in the result set.
To get more original technical articles from Jerry, please follow the public account "Wang Zixi" or scan the QR code below:
