After the OPEN CURSOR statement, the database cursor is positioned in front of the first line of the result set.
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 驗證：
Source code:
Size = 1: 此時從ST05裡觀察到表COMM_PRODUCT裡總共被掃描的記錄數量是1447.
第二次以size = 100執行，PREPARE和OPEN直接變成REOPEN，但是recs仍然是1447.
對ST05裡的字段Recs按F1，檢視說明：
這個1447是怎麼來的呢？因為我OPEN CURSOR時候沒有指定任何條件，是以在OPEN CURSOR時，DB把整個product表的所有記錄視為一個結果集，然後隻傳回指定package size的條數。
是以ST05裡面看到的這個Recs是指滿足OPEN CURSOR 指定條件的記錄的個數，并不是最後傳回給ABAP層的記錄的個數。
而在我的測試系統裡，表COMM_PRODUCT總共就包含1447條記錄。
然後我再生成3個新的product，COMM_PRODUCT裡面就有1450條entry。
重複執行測試report。ST05發現被掃描的記錄數變成了1450，證明我們的結論是正确的。
再做一個驗證：表COMM_PRODUCT裡面有prefix為JERRY06152012開頭的3條記錄：
修改上述的測試report，添加一個WHERE查詢條件：
第一次執行size = 1
Recs變成3了，因為比對OPEN CURSOR條件的确實隻有3條記錄
Size = 100, ST05結果和size = 1完全一緻，都是3.
WebClient UI上的Maximum Number of Results(簡稱Max hit)不能控制每次OPEN CURSOR去DB查找記錄的條數，這個條數是由OPEN CURSOR後面跟的WHERE CONDITION決定的。Max hit隻能控制OPEN CURSOR的WHERE CONDITION 所決定出的結果集裡，到底有多少條傳回給ABAP。
Through the verification above, this understanding is wrong.
OPEN SQL的select還有一個功能是UP TO XX ROWS.
用下面的代碼測試：
Num = 1
Num = 143
說明SELECT UP TO XX ROWS是可以控制資料庫表裡到底有多少條記錄被處理的。
但SELECT UP TO XX ROWS不能像OPEN CURSOR那樣能夠在WHILE循環裡面反複執行，它不具備像OPEN CURSOR那樣的機制，使得其能夠記住目前正在操作的記錄在結果集裡的位置。
要擷取更多Jerry的原創技術文章，請關注公衆号"汪子熙"或者掃描下面二維碼: