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:

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里观察到表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查询条件:

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.

结论

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.

用下面的代码测试:

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是可以控制数据库表里到底有多少条记录被处理的。

但SELECT UP TO XX ROWS不能像OPEN CURSOR那样能够在WHILE循环里面反复执行,它不具备像OPEN CURSOR那样的机制,使得其能够记住当前正在操作的记录在结果集里的位置。

要获取更多Jerry的原创技术文章,请关注公众号"汪子熙"或者扫描下面二维码:

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏安恒网络空间安全讲武堂

Sqli_labs65关通关详解(上)

Less-1 这个题目是基于错误,单引号,字符型注入, http://127.0.0.1/sqli/Less-1/?id=1' //报错 http://...

6056
来自专栏杨建荣的学习笔记

关于dual表的破坏性测试(r3笔记第60天)

关于dual表的破坏性测试,既然是破坏性测试,就需要确定这个测试仅限于测试或者个人学习所用,可能有些sql看似极为简单,但是一旦运行就会导致整个业务系统崩溃。 ...

38313
来自专栏杨建荣的学习笔记

impdp异常中断导致的问题(r2第8天)

今天查看数据库的负载,发现cpu消耗异常的高。里面有不少dw的进程.但是查看impdp的进程却不存在。 查看datapump的进程情况,发现大量的job,但是状...

38111
来自专栏杨建荣的学习笔记

简单实用的sql小技巧(第一篇) (r3笔记第36天)

今天和大家简单分享几个实用的sql小技巧。还有一些还在整理中,会不断的分享出来。 有些其实也不算是sql的技巧,可能大家在写sql语句的时候没有意识到我们可以通...

2943
来自专栏颇忒脱的技术博客

数据库时区那些事儿 - Oracle的时区处理

当JVM时区和数据库时区不一致的时候,会发生什么?这个问题也许你从来没有注意过,但是当把Java程序容器化的时候,问题就浮现出来了,因为目前几乎所有的Docke...

8394
来自专栏杨建荣的学习笔记

执行计划变化导致CPU负载高的问题分析 (r8笔记第20天)

前几天碰到一个CPU负载较高的问题。从系统层面来看,情况不是很严重,但是从应用的角度来说,已经感觉到很慢了。因为前端的调用频率还是比较高。所以会把这个问题放大。...

2567
来自专栏杨建荣的学习笔记

ORA-01427问题的分析和解决(r6笔记第51天)

前几天开发的同事反馈一个问题,说前台系统报出了ORA错误,希望我们能看看是什么原因。 java.sql.SQLException: ORA-01427: sin...

2704
来自专栏乐沙弥的世界

使用datapump 导出导入同义词(export and import synonym using datapump)

      对于同义词的备份我们有多种方式来实现,如直接通过脚本生成同义词的创建脚本,或者使用dbms_metadata.get_ddl来提取同义词的定义脚本。...

933
来自专栏乐沙弥的世界

Oracle 回滚(ROLLBACK)和撤销(UNDO)

Oracle使用数据库中的回滚段来实现未提交数据或因系统故障导致实例崩溃时进行回滚操作

1121
来自专栏Java技术栈

mysql语句性能开销检测profiling详解

之前我介绍过msyql查询优化explain检查命令的使用,explain主要是检查sql语句的基本性能,sql是否优秀,但不能查看具体的涉及硬件资源的开销,今...

3346

扫码关注云+社区