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

还是其他类型的应用 Trigger顺序3： pre-form/when-create-record/pre-block/when-new-forms-instance/when-validate-record/on-insert/post-forms

当定位到主块的一个记录，会促发子块的when-clear-record事件和when-create-record事件，问题是如果主块的是新记录（未保存），在子块的when-create-record里面取主块的任何东西，居然是主块的上一次获得焦点的记录的东西；连用取块的当前记录也是上一次获得焦点的记录。 Trigger顺序4： post-changed在when-validate-item之前。所有的when-validate事件是当forms自己验证通过之后才促发的。 禁用Clear功能可以通过在Form的key-clrblk里面调用app_sabled，其实只是用Bell覆盖默认的执行。 直接放在TAB Page上的Item，和放在堆叠画布上的Item在设计时是无法“所见即所得”，所以建议把所有的Item根据需要放在不同的堆叠画布上再堆到TAB Page上伪列Rownum在排序之前就已经决定，如果想得到排序后的Rownum，应当在嵌套一个Select语句；另外Where语句中的rownum只能用或者=，不能有或者=。 在SQL中用Over的时候，如果整个语句没有Order by语句，最后的结果还是会排序的，规则是先按Over里面的Partition排序，在按Over里面的Order by排序。原因可能和分析函数的处理顺序有关（f有详细介绍）：先查询到数据（Join/Where/Group By/Having），再运算分析函数（先分区，然后排序，再算Slide Windows，最后计算），最后是Order By。另外，一个疑问：我测试到的一个结果Group By好像无法影响Partition，可是按照f的说法，应该先执行Group By的，是不是因为Group By只是在第一阶段的处理时作用在集合函数上，之后进入第二阶段的处理就没用了。 同事在装8i的时候，连安装界面都没出来，而我机器可以装，后来才知道原来他的机器是P4，无法正常安装。 实际执行的Where条件，是我们设置DEFAULT_WHERE，再加上通过赋过值的Item。 注意：APP_ery_range已经重载过，我们调用的时候可以不区分query_number_range或者query_date_range；观察其代码，发现也是通过给Item赋值来影响查询的，只不过是赋值的时候，可能是加上 # between，# =或# =；这样导致的一个结果是：Date类型的Item长度默认是11，被query_range这样一搞，长度根本不够，于是就导致诸如where REQUEST_DATE = to_dat的错误，所以记得把字段长度加长，比如1000；总的来说，碰到From to的要小心长度。 当修改子类的时候，会自动更改很多属性，特别是Required，一定要注意。