开发篇之 Oracle触发器心得体会

核心提示： Trigger顺序4：post-changed在when-validate-item之前，所有的when-validate事件是当forms自己验证通过之后才促发的，开发篇之 Oracle触发器心得体会(3)，禁用Clear功能可以通过在Form的key-clrblk里面调用app_exc

Trigger顺序4：

post-changed在when-validate-item之前。所有的when-validate事件是当forms自己验证通过之后才促发的。

禁用Clear功能可以通过在Form的key-clrblk里面调用app_exception.disabled，其实只是用Bell覆盖默认的执行。

直接放在TAB Page上的Item，和放在堆叠画布上的Item在设计时是无法“所见即所得”，所以建议把所有的Item根据需要放在不同的堆叠画布上再堆到TAB Page上伪列Rownum在排序之前就已经决定，如果想得到排序后的Rownum，应当在嵌套一个Select语句；另外Where语句中的rownum只能用<或者<=，不能有>或者>=。

在SQL中用Over的时候，如果整个语句没有Order by语句，最后的结果还是会排序的，规则是先按Over里面的Partition排序，在按Over里面的Order by排序。原因可能和分析函数的处理顺序有关（8ifunctions.pdf有详细介绍）：先查询到数据（Join/Where/Group By/Having），再运算分析函数（先分区，然后排序，再算Slide Windows，最后计算），最后是Order By。另外，一个疑问：我测试到的一个结果Group By好像无法影响Partition，可是按照8ifunctions.pdf的说法，应该先执行Group By的，是不是因为Group By只是在第一阶段的处理时作用在集合函数上，之后进入第二阶段的处理就没用了。

同事在装8i的时候，连安装界面都没出来，而我机器可以装，后来才知道原来他的机器是P4，无法正常安装。

实际执行的Where条件，是我们设置DEFAULT_WHERE，再加上通过赋过值的Item。

注意：APP_FIND.query_range已经重载过，我们调用的时候可以不区分query_number_range或者query_date_range；观察其代码，发现也是通过给Item赋值来影响查询的，只不过是赋值的时候，可能是加上 # between，# >=或# <=；这样导致的一个结果是：Date类型的Item长度默认是11，被query_range这样一搞，长度根本不够，于是就导致诸如where REQUEST_DATE >= to_dat的错误，所以记得把字段长度加长，比如1000；总的来说，碰到From to的要小心长度。