加密：使用oracle提供的wrap工具：
举例：
D:\mytest> c:\devsuitehome_1\bin\wrap iname=mypackage.pck
输出:在当前目录下生成一个同名的.plb文件 mypackage.plb
编译加密文件：
登录plsqldeveloper ,打开commond窗口 ，编译加密文件：
SQL>@d:\mytest\mypackage.plb;
编译成功；
解密：使用“好事者”提供的解密工具：
base (来源：http://www.itpub.net/thread-1175718-8-1.html)
用法：base <加密文件名> <解密文件名>
可把加密的plsql 进行解密：
举例：把dbms_output的加密的部分另存为dbms_output.plb文件
d:\mytest>base dbms_output.plb dbms_output.txt
即可成功解密；
Folder查询结果不对的问题：
问题：在一次项目UAT时，一个用户测试时发现她总是查询不出结果，这个FORM是我们客户化一个标准的FORM。
解决过程：因为是标准FORM，而且我们之前自己测试时也没有遇到这个问题，所以以为系统对用户权限有什么控制，我们查看FORM源代码，但是找了很久还是没有找到问题的所在，打印DEFAULT_WHERE发现每一次查询后，DEFAULT_WHERE会增加一段相同的我们很费解的条件，就是这个条件导致查询不出结果。
问题原因：最后多亏吴前进提醒，最终我们找到问题所在。原来该用户在操作时，保存了FOLDER，在保存时勾选了”包括查询”，结果就把当时的查询条件给保存了下来，所以该用户在每一次查询是都会带上该条件，导致查询不出结果。对于保存的FOLDER，点击 文件夹-》查看查询，查看保存的查询。
总结：在用户培训时，对于FOLDER的FORM，要提醒用户此类问题，如果保存FORM时，要慎重勾选“包括查询”，除非确实需要保存的条件。对于FOLDER FORM，如果碰到某种情况加查询结果不准确，要首先考虑是不是FOLDER保存查询的原因。
FOLDER修改多堆叠画布问题
问题：在做一个Tab FOLDER FORM时，由于需要变化每一个Tab页上的ITEM，重新分配，将原来在第一个画布上的ITEM放到第三个画布上面，我直接修改的画布属性。结果导致第一个画布的ITEM布局乱了，出现了一部分ITEM堆到了另一部分ITEM上面。
解决过程：因为修改ITEM比较多，我以为是ITEM没有对应上或者Promt与内容字段顺序没有对应上的问题，结果比对了好久，发现没有问题。
问题原因：多谢徐晓晓同学提醒，原来是我直接修改ITEM属性，而没有去调整ITEM的顺序。对于这种多堆叠画布的FOLDER，需要把属于同一个画布的ITEM都放在一起，如果交叉放的话会导致一个画布上的ITEM堆起来。
思考：FOLDER将ITEM放到画布上时，应该是按照ITEM的顺序去填到画布上去的，而从一个画布到另一个画布上时，都会把ITEM从画布的最左边开始摆放，所以导致了ITEM堆起来的结果。
FORM 中LOV使用别名问题
问题：在一个LOV的记录组中SELECT nvl(p.full_name, fu.user_name) FULL_NAME
,fu.user_name
,fu.user_id
FROM fnd_user fu
,per_all_people_f p
WHERE fu.employee_id = p.person_id(+)
ORDER BY 1
LOV选择在显示之前过滤
发现查询的结果中，总是没有取到user_name的情况。
解决&总结：通过做TRACE发现，在显示之前过滤时，会自动在后面拼上一段条件FULL_NAME like :1 …..实际上执行的时候，FULL_NAME指向的是per_all_people_f里面的 FULL_NAME，所以没有出现user_name的值（其实这样使用别名是会报错，这是一个巧合）；而当把别名修改成为其他（非数据库字段名）NAME时，会报NAME标识符无效错误。这是肯定的，应为SQL就是不能用别名来作为查询条件的。解决方法有两个：1，将显示之前过滤设为否，这样就会把所有记录先查出来，然后在查询出来的记录组里再筛选。不会在之前拼SQL了。
2，如果一定要在显示之前过滤的话，使用嵌套查询。
帮助》历史记录灰掉问题
问题：在一个FORM中发现历史记录菜单灰掉
解决：这个跟块查询灰掉一样，块查询是把块级触发器WHEN-NEW-RECORD-INSTANCE触发器层级修改为BEFORE，
这个问题需要将WHEN-NEW-BLOCK-INSTANCE触发器层级修改为BEFORE，因为这两个的可用与否，是FORM级触发器判断的，如果覆盖，就不可用了。
PS：使用历史记录时 报“历史记录不可用”，是由于在该块中没有5个数据库WHO字段的原因，添加上就行了。
1、图表刷新问题：
现象：使用BI publisher在Word中插入图表以后，右键单击图表没有“BI Publisher 图表…”菜单项，且预览时，不会因为xml数据变化而使得图表跟着变化，感觉是一幅静态图片。
分析：在把文档另存为97-2003的兼容格式后，再另存为RTF格式文档后，发现在图片上右键菜单有“BI Publisher 图表…”菜单项了，预览时图形也确实会跟着xml数据变化而变化。
解决方法：按照分析中的方法创建RTF文档 ，这可能是一个兼容性问题。
2、模板文档属性问题：
现象：在RTF模版的Advanced例子中有一个需要通过设置文档属性来控制的例子 Properties， 但很难找到自定义文档属性的地方。
分析与解决：word2010设置自定义属性的地方确实够隐蔽，但也很容易找到，看下图：
在文件->信息->属性->高级属性
FROM批量处理界面效果
当遇到对ＦＯＲＭ上记录进行批量处理时，一般情况下都会选择在记录前面加上复选框，然后勾选上需要处理的数据，最后获取勾选的记录数据进行业务处理：
如果只是添加复选框，显得界面效果太单调，勾选结果显示也不够明显，将勾选的行进行特殊显示，会使得勾选效果更好。
通过在标准界面查找类似业务，找到对应ＡＰＩ：
app_record.highlight(‘SELECTED_DATA’);高亮显示当前行所有ITEM
app_record.highlight(”);取消高亮显示当前行所有ITEM
效果如下图：
这样看起来用户会更明确的看到选择的行。
效果已经做出来，但是在操作上，用户会有一些不便，选择几行或者全选还好。但是如果一次连续选择50条，100条用户需要点击100次？用户会疯掉。
解决方法：
在我们用电脑选择多个对象时，习惯性使用CTRL或者SHIFT键来多选记录，可以考虑使用这个方法来处理。
通过查找标准FORM的库代码，找到了解决方法。
核心在一个SYSTEM属性
name_in(‘SYSTEM.MOUSE_BUTTON_MODIFIERS’);
返回varchar2。
在WHEN-MOUSE-CLICK触发器时，这个属性会返回在你点击鼠标时，同时按住的那些按键名称用’+’拼接起来，如：同时按住Ctrl和Shift时返回Shift+Control+。有了这个后面问题就好解决了，只需要判断返回值是否包含Control或者Shift即可。
处理逻辑:
1. 按住Ctrl点击左键，如果原来勾选高亮显示，则变成取消勾选高亮显示，反之，则变成勾选高亮。
2. 按住Shift时需要增加一个变量记录上一次点击行Last_record
然后再根据当前点击行，循环中间所有行，勾选高亮显示，按住Shift的优先级应该高于Ctrl。
注意：因为勾选复选框时会触发WHEN-CHECKBOX-CHANGED，然后也触发WHEN-MOUSE-CLICK事件，这样按住CTRL会导致做两次事件，此时需要判断去跳过其中一个事件。
这样，就有多种操作方式选择记录了，使用户操作更加个性化，同时节省操作时间。
附：批量处理界面数据获取的心得：
对于这种勾选批量处理界面数据获取，首先想到的就是去循环界面所有记录去检查是否勾选，从而获取数据。这种方法简单，代码也很好写。但是当在界面操作时，问题就会出现：只勾选一条记录，却要去循环整个界面所有数据，还包含没有fetch到界面的数据。使得处理速度大大增加。“想尽办法去避免循环界面“这是我在做这个功能一个的体会（全选是不可避免的要循环界面了）。所以这种勾选模式要提前去获取数据。首先定义一个全局Table类型的变量，当勾选某一条记录时，将值存在Table(:SYSTEM.CURSOR_RECORD)里，取消勾选时Table.delete(:SYSTEM.CURSOR_RECORD)。这样在最后处理逻辑是只需要循环Table就行了。避免去Fetch不需要的数据（处理过程中，Table中间delete掉的记录在获取时会报No_data_found异常，只需要抛出异常跳过就行了）。即使勾选第一条和最后一条，虽然循环Table和循环界面次数一样，但是速度却有很大差别。
Oracle EBS 用户配置文件使用举例：
用户配置文件相当于系统参数，可以在不同层级（Site层、应用模块层、责任层、用户层）设置不同的值； 作用范围小的覆盖范围大的层，系统已经预设了很多user profile; 开发人员也可以定义User profile;
对开发人员如果要新定义user profile 并使用之，步骤一般包括三步
第一步：定义user profile （Nav:应用开发员责任->配置文件）
上例中定义了一个User profile : ORG_ID， SQL验证用于提供用户在设置该Profile值的时候提供LOV数据来源； 开发者只需要依葫芦画瓢即可。
如果LOV来源不是系统原有表中的数据，而是需要自己定义的，那么可使用值集定义好数据源，然后在这里的SQL中使用，下面的例子就是这样的：
上述例子中，lov数据来源于fnd_flex_values_vl视图，该视图中的内容是用户可以在界面上定义增加的，一般步骤是：
a) 先定义一个值集（Nav: 系统管理员责任->应用产品->验证->请求集：
值集名将用在上面的sql中，验证类型为独立。
b) 为新定义的值集添加值(NAV: 系统管理员责任->应用产品->验证->值）
在名称处输入刚才定义的值集名作为查询条件，然后点查找
在该界面可以为上面定义的值集添加值。
第二步：设置User Profile的值（Nav：系统管理员责任-> 配置文件-> 系统）
如果需要同时设置责任层和用户层的值，则把两者都勾选上。
上例中，责任 order Management user,… 和 用户Operations 层都设置了值； 且值是不一样的。 由于用户层的值可以覆盖责任层的值，当operations 用户以 order Management user,..责任登录系统是，Form中取到的值是： Vision ADB;
三、 程序中获取User profile 值：
在程序中可以使用fnd_profile.value(‘ORG_ID’) 来获取 ORG_ID这个user profile的值； 有关用户配置文件的详细概念和API，请参考120devg.pdf 第249页。
各位请把自己Form练习过程中遇到的各种问题上报到这里。
回帖格式：
问题现象描述：
问题分析：
解决方法：
本文的上一篇文章是：从 R12.1.1 升级到 R12.1.2 中文语言 Patch问题
1、访问主组织物料提示：你必须至少允许访问一组物料属性。
原因：INV模块没有被授权
解决方法：system administration ->License Manager ->Product 把INV 产品授权，即可。
2、打开order 界面 报ORA-04062错误 of state changed,且中文语言进入的Form上还都是英文的。
解决方法：adadmin 重新编译数据库对象、重新编译菜单（这个还算快，不太费时）。 没用！
adadmin 重新编译Form（比较耗时间，准备1晚上吧，9000多个Form，Pll任务要编译 US 和 ZHS） ，ORA-04062 在新建订单时不出现了，中文Form进入也是显示中文label了。
3、中文模式进入OM模块 编辑订单时还提示CCID未找到，订单行上的Item显示为空。但英文模式进入没有上述问题。
查 ： select distinct language from mtl_system_items_tl 只有 US ,没有中文。
select * from fnd_lookup_values where language =’ZHS’ 有中文。
说明只是部分表的多语言没有被初始化。
解决方法：停应用；
想使用adadmin 中的 Maintain multi-lingual tables 功能来把item的中文给初始化一下，但又担心把其他好的表中的中文内容给“冲”掉。于是查Maintain multi-lingual tables究竟干了什么？ 查metalink [ID 981868.1] 发现在执行Maintain multi-lingual tables 时，实际就是执行inv模块下面的 sql/INVNLINS.sql ;打开这个sql看，其实针对item执行的是INV_ITEM_PVT.add_language; 查看INV_ITEM_PVT.add_language的代码，发现其逻辑是：不会重复“覆盖”原来已经有其他语言的记录。所以多次执行也没有问题，但为什么为什么Item的中文信息会丢失呢？难道是以前没有运行Maintain multi-lingual tables，不可能啊，ORG_FREIGHT_TL中是有中文的记录的，ORG_FREIGHT_TL的中文信息也是在sql/INVNLINS.sql执行的。
不管它，先在plsqldeveloper中直接运行 INV_ITEM_PVT.add_language，把中文item给生成了。
再起应用，中文环境，进入OM,打开一张订单 item已经有了，但是新建一行时，计量单位还是没有，在英文环境是好的。
停应用，使用adadmin Maintain multi-lingual tables, 再启应用,在中文下问题依旧，查MTL_UNITS_OF_MEASURE_TL 确实缺少中文记录，查adadmin的log INVNLINS.sql已执行。在plsqldeveloper中单独执行 INVNLINS.sql ，发现例外：
LANGUAGE = AMERICAN
PACKAGE= MTL_UNITS_OF_MEASURE_TL_PKG
SQLERRM= ORA-00001: unique constraint (INV.MTL_UNITS_OF_MEASURE_TL_U2) violated
是这个原因导致 INVNLINS.sql执行中断的。
这些记录比较怪，Source_lang =’ZHS’,这是不对的，source_lang 应该都是’US’才对。
| Period | N | 2010/8/13 22:38 | 0 | 2005/5/5 | 120 | 0 | 每半年 | 每半年 | ZHS | ZHS | |
| Period | N | 2010/8/13 22:38 | 0 | 2005/5/5 | 120 | 0 | 每周 | 每周 | ZHS | ZHS | |
| Period | N | 2010/8/13 22:38 | 0 | 2005/5/5 | 120 | 0 | 每月 | 每月 | ZHS | ZHS | |
| Period | N | 2010/8/13 22:38 | 0 | 2005/5/5 | 120 | 0 | 每季 | 每季 | ZHS | ZHS | |
| Period | Y | 2010/8/13 22:38 | 0 | 2005/5/5 | 120 | 0 | 每两周 | 每两周 | ZHS | ZHS | |
经查是 patch/6678700_ZHS/inv/patch/115/import/ZHS/invuomcl.ldt 给导入进来的。想不通为啥中文语言包要单独insert这几条数据。
删除这5条记录 delete from mtl_units_of_measure_tl where source_lang=’ZHS’
再次单独执行 INVNLINS.sql 返回：
ORA-0000: normal, successful completion 成功完成。 再次以中文环境登录，Ok了。
一、背景：
1) Demo环境
2）从 R12.1.1 升级到 R12.1.2 Patch顺利完成
3）从 R12.1.1 升级到 R12.1.2 中文语言 Patch 过程中有部分ldt 任务failue , adctrl retry多次未果，就Skip 过去了。
二、现象
IE打开R12的时候报错(http://syfdemo.ml.com:8000)：
Oracle error 6519: java.sql.SQLException: ORA-06519: 检测到活动的独立的事务处理, 已经回退 ORA-06512: 在 "APPS.FND_FUNCTION", line 2155 ORA-06512: 在 "APPS.FND_FUNCTION", line 1090 ORA-06512: 在 "APPS.FND_FUNCTION", line 1018 ORA-06512: 在 "APPS.FND_FUNCTION", line 1304 ORA-06512: 在 "APPS.FND_FUNCTION", line 1592 ORA-06512: 在 "APPS.FND_FUNCTION", line 1674 ORA-06512: 在 "APPS.FND_SESSION_MANAGEMENT", line 1321 ORA-06512: 在 "APPS.FND_AOLJ_UTIL", line 421 ORA-06512: 在 line 1 has been detected in FND_AOLJ_UTIL.is_Valid_ICX.
Servlet error: An exception occurred. The current application deployment descriptors do not allow for including it in this response. Please consult the application log for details.
解决过程：
1）使用“Oracle error 6519: java.sql.SQLException: ORA-06519: 检测到活动的独立的事务处理, 已经回退”
“ ORA-06512 在 “APPS.FND_FUNCTION”, line 2155”
“ ORA-06512: 在 line 1 has been detected in FND_AOLJ_UTIL.is_Valid_ICX”
等关键短语在google, metalink检索 能查到少量信息，也即别人也遇到这样类似的问题，但未有答案。
这一步耗时10分钟，但未有成果。
2）查看程序 FND_FUNCTION, line 2155，发现对应程序为：FND_FUNCTION.FAST_COMPILE 过程。意思是这个过程用于重新编译那些需要被编译的菜单，该过程使用了自治事务。在注释中提到，管理员可以直接在sqlplus中运行FND_FUNCTION.FAST_COMPILE;
于是在plsqldeveloper 的 command 窗口中直接运行
SQL> execute FND_FUNCTION.FAST_COMPILE;
begin FND_FUNCTION.FAST_COMPILE; end;
ORA-06519: active autonomous transaction detected and rolled back
ORA-06512: at “APPS.FND_FUNCTION”, line 2155
ORA-06512: at line 2
SQL>
结果报上述错误。
Metalink 搜索 ORA-06519: active autonomous transaction detected and rolled back
20条结果发现 有一条比较接近，因为它同时含有“get_icx_ticket” 与我IE中报出的“FND_AOLJ_UTIL.is_Valid_ICX”相关。于是没有看其他19条结果，直接看这条结果：
这条结果的标题是：APP-FND-01564: ORACLE error 6519 in get_icx_ticket [ID 1088834.1]
查看具体内容，说因为表空间不足。
3）根据 数据库初始化参数 diagnostic_dest 找到 alert.log 的位置，打开看 :
ORA-1691: unable to extend lobsegment APPLSYS.SYS_LOB0001935853C00024$$ by 16 in tablespace APPS_TS_SEED
client_id=” type=’UNKNOWN’ level=’16’
host_id=’syfdemo.ml.com’ host_addr=’192.168.1.23′ module=’FNDIRLPP’
pid=’19142′>
ORA-1653: unable to extend table APPLSYS.FND_OBJECTS by 16 in tablespace APPS_TS_SEED
client_id=” type=’UNKNOWN’ level=’16’
host_id=’syfdemo.ml.com’ host_addr=’192.168.1.23′ module=’FNDIRLPP’
pid=’19142′>
ORA-1653: unable to extend table APPLSYS.FND_OBJECTS by 16 in tablespace APPS_TS_SEED
确实是APPS_TS_SEED用完了，至少metalink指出的原因在我这里也发生了，也许不仅仅是这个原因，也许仅仅是这个原因，不管怎样，先把这个问题解决试试看:
4) 扩展APPS_TS_SEED表空间：
找到它的数据问题文件
select * from dba_data_files t where t.tablespace_name = ‘APPS_TS_SEED’
扩大其中一个数据文件，由原来的400多M 扩展到2个G:
alter database datafile ‘/d01/oracle/VIS/db/apps_st/data/reference1.dbf’ resize 2000M
5) 再次测试：
在PLSQL DEVELOPER Command窗口中运行
SQL> execute FND_FUNCTION.FAST_COMPILE;
PL/SQL procedure successfully completed
SQL>
成功。
再次在IE中打开R12, 错误消失，可正常登录。
讨论：
若把这个问题解决当作是猜题游戏（根据现象 猜测真实原因），那么本次猜题游戏能得多少分呢(满分100分制）?
自评：
a) 解决过程中第一步，完全是浪费，扣20分；
b) 解决过程中第二步，直接从20多条Metalink结果中，找到一条吻合的，运气成分太高了，虽然不错，但逻辑性不强，扣10分；
得分：100-30 = 70分
思考，这个问题，基于怎样的思维方式，可以在更准，更快的定位问题原因呢？
后续：因为前面的R12.1.2 中文语言 Patch 遇到表空间不足，有2252个ldt任务被我用adctrl skip过去了，所以虽然adpatch complete ,但打得不成功，在扩展表空间以后再打了一次R12.1.2 中文语言 Patch，发现这次的ldt任务就是针对剩下的2252个的，它自动接着上次skip的那些ldt任务开始的（之所以这么说是因为我查上一次的R12.1.2 中文语言 Patch的log发现ldt任务有3600多个，在剩余2252多个的时候因为表空间不足被skip）；这次没有报什么错误，顺利把剩余部分的ldt给打上去了。