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條記錄：
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的問題：
我寫了一個很簡單的report 驗證：
Size = 1:
Recs F1的說明是：