ABAP OPEN SQL 里 OPEN CURSOR 和 SELECT 的比较
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 验证:
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 的原创技术文章,请关注公众号"汪子熙":
版权声明: 本文为 InfoQ 作者【Jerry Wang】的原创文章。
原文链接:【http://xie.infoq.cn/article/c66470c52ee7145ca637854ae】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论