oracle触发器好处,开发篇之—Oracle触发器心得体会

开发篇之—Oracle触发器心得体会以下文字资料是由(历史新知网www.lishixinzhi.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

实在对象如表格 Sequence 索引等建在本应用对应的用户表空间中 其他对象如视图 别名创建在Apps下 常见错误是新手把表建在APPS下 以后又来建别名 这个时候删除别名时会报对象不存在 而建别名的时候又报对象已存在

如果把脚本保存在文件里面 注意一个块比如一个创建视图的语句不要有空行 否则会出现如下情况 把语句拷贝到SQL Window能正常运行 用@执行文件却报错

如果要执行execute_query 注意要go_block到适当的Block 但是go_block是个受限过程 并不一定都能成功

Master detail关系

block both are database blockeach block has one item based on database displayed

在PL/SQL Develop中没有环境变量 所以如果要查询多组织的View 需要先执行设置环境变量函数:

BEGINfnd_client_info set__context( );END;

GLOBAL变量对于所有form有效(可能是同一个应用 这个尚未验证) 而不仅仅是你所开发的form变量比如Global和Parameter的初始化应该在pre form里面 在when new form instance里面初始化不行 因为when new form instance是在进入第一个导航块的第一个item之后才促发的没有属性指名Block的记录数 不过可以通过GET_BLOCK_PROPERTY(QUERY_HITS) 取得查询到的记录数hide_view并没有真正hide一个画布 只是放到最下层 所以如果上层的画布没有完全覆蓋下层画布 下层的画布很可能用户还看得到 show_view则是把画布放在最上层

lov验证的时候是验证第一个可见的列 并且会把其他的返回值返回给各个Item 而不是仅仅验证而已lov的查询一般是针对第一列 但是如果我们把%放在最前面 则可以查询所有列

用Execute_query执行查询的时候 会把Copy Value From Item里面的那个Item的值自动作为查询条件 当创建记录的时候也会直接用该值初始化 而且不改变记录的状态 在更新记录的时候不知道会不会Copy过来尚未验证 Get_Item_property的时候用ENFORCE_KEY属性 但不能Set 该属性在Master detail设置的时候自动创建 删除的时候自动删除 如果不希望Copy Value From Item影响查询结果 可以在Pre Query里面把Item的值设为null

app_query reset( block_name );如果第一次调用 会把当前的DEFAULT_WHERE 然后什么都不做 以后再来调用的时候则会把第一次设置的DEFAULT_WHERE用set_block_property( SAA_HEADERS DEFAULT_WHERE )设置回来 具体请参考app_core库

When create record的时候给Item赋值不改变记录状态 Sequence 如果我们在Item的Initial Value里面赋值 那么假如用户Focus To新记录 又回到老记录 如此反复 Sequence会不断变大的

SQL Order BY的时候null值排在最后 这个一般不符合实际要求 可以这样解决ORDER BY nvl(Geography_Code chr( ))解决

Trigger顺序

pre mit块 的pre insert on insert post insert块 的pre insert on insert post insert post forms mit

Trigger顺序

when list changed在前 Validation item在后 因为Validation item是在要离开这个item的时候才促发的 Trigger顺序

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顺序

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排序 原因可能和分析函数的处理顺序有关( ifunctions pdf有详细介绍) 先查询到数据(Join/Where/Group By/Having) 再运算分析函数(先分区 然后排序 再算Slide Windows 最后计算) 最后是Order By 另外 一个疑问 我测试到的一个结果Group By好像无法影响Partition 可是按照 ifunctions pdf的说法 应该先执行Group By的 是不是因为Group By只是在第一阶段的处理时作用在集合函数上 之后进入第二阶段的处理就没用了

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

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

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

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

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

两个变量 如果都为Null 判断还是不相等 所以必须用 a is null and a is null 所以在On lock里面的if条件 我们可以把所以不可以为空的字段都写成允许为空的形式

一般来说 系统变量是很好用的 然而有时候并非如此 比如Current_Record get_block_property( blockname Current_Record)的结果并非总是一样的 后者更加保险！特别是刚打开Form的时候 在WHEN NEW RECORD INSTANCE里面 前者是 后者是

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

重启Application

cd ?$APPLCSFcd scriptscd PROD /adstpall sh apps/apps /adstrtal sh apps/apps

Trigger顺序

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

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

数据库_id初始值to_number(decode(substrb(userenv( CLIENT_INFO ) ) null substrb(userenv( CLIENT_INFO ) )))

给非数据库Item赋值 new记录会变成insert(所以就不能按F 了) query/changed记录不变 new块会变成query query/changed块不变

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

分页：123