Created by Jerry Wang, last modified on Mar 10, 2014
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.
使用如下的ABAP语句进行验证:
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时，使用ST05 trace上述ABAP语句得到的结果如下:
Size = 100:
第二次执行，PREPARE和OPEN直接变成REOPEN，但是recs仍然是1447.
Recs 在ST05里按F1的说明是：
这个1447是怎么来的呢？因为我OPEN CURSOR时候没有指定任何条件，所以在OPEN CURSOR时，DB把整个product table的所有entry视为一个result set，然后只返回指定package size的条数。
所以ST05里面看到的这个Recs是指满足OPEN CURSOR 指定条件的record的个数，并不是最后返回给ABAP的record的个数。
然后我再生成3个新的product，COMM_PRODUCT里面就有1450条entry。重复执行测试report。ST05证明我们的结论是正确的。
再做一个验证：table里面有prefix为JERRY06152012开头的3条记录：
OPEN CURSOR lv_cursor FOR
SELECT product_guid
FROM comm_product
WHERE
product_id LIKE 'JERRY06152012%'.
第一次执行size = 1
Recs变成3了，因为匹配OPEN CURSOR条件的确实只有3条记录
Size = 100, ST05结果和size = 1完全一致，都是3.
所以max hit不能控制每次OPEN CURSOR去DB 查找record的条数，这个条数是由OPEN CURSOR后面跟的WHERE CONDITION决定的。Max hit只能控制OPEN CURSOR的WHERE CONDITION 所
决定出的result set里，到底有多少条返回给ABAP。
SELECT：
使用如下ABAP语句进行ST05的trace:
SELECT product_guid INTO CORRESPONDING FIELDS OF TABLE lt_line FROM comm_product UP TO num ROWS.
Num = 1
Num = 143
说明SELECT UP TO xx ROWS是可以控制Processed record number的。
但SELECT UP TO xx ROWS不能像CURSOR那样能够在WHILE循环里面反复执行，没有一个cursor的机制记住当前正在操作的record在result set里的position。
From: Wang, Jerry
Sent: Friday, June 15, 2012 7:07 PM
Subject: OPEN CURSOR vs SELECT
Hi all,
我研究了我们昨天遇到的OPEN CURSOR的问题：
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.
我写了一个很简单的report 验证：
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:
Size = 100:
第二次执行，PREPARE和OPEN直接变成REOPEN，但是recs仍然是1447.
Recs F1的说明是：
这个1447是怎么来的呢？因为我OPEN CURSOR时候没有指定任何条件，所以在OPEN CURSOR时，DB把整个product table的所有entry视为一个result set，然后只返回指定package size的条数。
所以ST05里面看到的这个Recs是指满足OPEN CURSOR 指定条件的record的个数，并不是最后返回给ABAP的record的个数。
然后我再生成3个新的product，COMM_PRODUCT里面就有1450条entry。重复执行测试report。ST05证明我们的结论是正确的。
再做一个验证：table里面有prefix为JERRY06152012开头的3条记录：
OPEN CURSOR lv_cursor FOR
SELECT product_guid
FROM comm_product
WHERE
product_id LIKE 'JERRY06152012%'.
第一次执行size = 1
Recs变成3了，因为匹配OPEN CURSOR条件的确实只有3条记录
Size = 100, ST05结果和size = 1完全一致，都是3.
所以max hit不能控制每次OPEN CURSOR去DB 查找record的条数，这个条数是由OPEN CURSOR后面跟的WHERE CONDITION决定的。Max hit只能控制OPEN CURSOR的WHERE CONDITION 所
决定出的result set里，到底有多少条返回给ABAP。
SELECT：
SELECT product_guid INTO CORRESPONDING FIELDS OF TABLE lt_line FROM comm_product UP TO num ROWS.
Num = 1
Num = 143
说明SELECT UP TO xx ROWS是可以控制Processed record number的。
但SELECT UP TO xx ROWS不能像CURSOR那样能够在WHILE循环里面反复执行，没有一个cursor的机制记住当前正在操作的record在result set里的position。