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的要小心长度。

　　当修改子类的时候，会自动更改很多属性，特别是Required，一定要注意。

　　当对块进行刷新时，会修改很多Item的属性，别以为你设置过了，Oracle就会记住。我碰到的情况是Insert Allowed等被自动改掉了！即使我的子类设置为Text_Item_Display_Only。

　　两个变量，如果都为Null，判断还是不相等，所以必须用 a1 is null and a2 is null。所以在On-lock里面的if条件，我们可以把所以不可以为空的字段都写成允许为空的形式。
　　一般来说，系统变量是很好用的。然而有时候并非如此，比如Current_Record，get_block_property('blockname',Current_Record)的结果并非总是一样的，后者更加保险！特别是刚打开Form的时候，在WHEN-NEW-RECORD-INSTANCE里面，前者是0，后者是1。

　　''''表示一个单引号，''''''表示两个单引号。应该是这样理解，一个单引号表示转义字符，首尾两个单引号里面的内容表示字符串。

　　重启Application：

　　cd ?$APPLCSF
　　cd scripts
　　cd PROD
　　./adstpall.sh apps/apps
　　./adstrtal.sh apps/apps

　　Trigger顺序5：

　　post-query，只有在界面可见的记录才会促发，记录从不可见变为可见时促发，促发过的记录不再促发；

　　保存的时候会引发Post Item/Record/Block事件，因为要Navigate到Form。

　　数据库org_id初始值to_number(decode(substrb(userenv('CLIENT_INFO'),1,1),' ',null,substrb(userenv('CLIENT_INFO'),1,10)))。

　　给非数据库Item赋值；new记录会变成insert（所以就不能按F11了）；query/changed记录不变；new块会变成query；query/changed块不变。

　　对On-lock的理解，由于先入为主的缘故，开始一直很苦恼，为什么If里面只用了一个Return，Form怎么知道要锁否？后来才知道On类型的数据库触发器是替换型的，On-lock也不例外，所以只要On-lock不Raise什么东西出来，Form就认为是锁成功了，至于实际的锁，我们有Select……For Update来完成，至于If判断只是进行更加严格的判定。

　　对Find的理解，开始也很纳闷，为什么在Pre-query里面直接给Item赋值就可，不用自己拼语句，现在也逐渐发现里面大有文章。回想F11，这个时候的block其实是处于Enter-query状态，输入的东西Form会自动拼成Where语句（当然还要加上原来的default where，如果有Copy from item，也要加上），对于每个Item上输入的值，一般是用 = ，如果有，就解析为like，如果有#，则把后边的表达式（比如between，甚至是子查询）直接作为条件；而当form内部执行堆栈Navigate到Pre-query时，block也是处于Enter-query状态，道理和F11一样，我们只管按业务查询要求对Item赋值，剩下的就交给Form去处理了；需要注意的是当处于enter-query状态的block，是使用query length属性来限制输入的数据长度，而不是通常的maximum lengh，只不过query length默认是0，即等于maximum lengh，所以会出现当用app_find.query_range时长度不够的情况。