Archive for the 'Oracle' Category
Form中断问题新解
自从换笔记本后，上EBS就经常出现异常中断，一直查不出原因。每天断个十次八次的，几乎无法用form界面干活。
前日仔细看了看JInitiator的各项配置，心有灵犀，怀疑“实时编译”这个选项有鬼。
取消这个选项，过了两天，有过异常退出的情况，但只有一两次，而且不是先前的那种状态。估计原先的异常中断的问题解决了。
其他电脑都不会这种情况，这是为何？奇怪。
select count(1) from dual
如何以比较方便的方式来获取某查询条件下的记录条数？
1
SELECT count(1) FROM (SELECT a,b,c FROM table_name)
这个方式用的比较多，但是还有一种更方便的做法，似乎更好。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
SQL*Plus: RELEASE 8.0.6.0.0 - Production ON Wed Nov 21 16:56:55 2007
(c) Copyright 1999 Oracle Corporation. ALL rights reserved.
Connected TO:
Oracle9i Enterprise Edition RELEASE 9.2.0.6.0 - 64bit Production
WITH the Partitioning, OLAP AND Oracle Data Mining options
JServer RELEASE 9.2.0.6.0 - Production
SQL> CREATE TABLE zeeno(t NUMBER, tt VARCHAR2(10));
TABLE created.
SQL>
SQL> INSERT INTO zeeno […]
Trace Analyzer
对于非技术人员来讲，做Trace也是件麻烦事，很多人不知Trace为何物，更不懂tkprof这种简单但不经培训便毫无头绪的东西。
Oracle提供一种更方便的方式，可以直接用SQL达到tkprof才能实现的功能。对于EBS用户来讲，这个工具提供更具针对性的内容。它以HTML格式输出tkprof所能提供的所有信息，更具可读性，适合对单个事务性能进行分析。
下载见Metalink: 224270.1
分和聚的矛盾
通常在设计一套系统或者一个功能时，总是首先考虑如何集中代码管理和可能出现的扩展。设计好了核心功能和相应的包后，某一天，我发现因为业务的需要，必须修改某个核心包。这里就出现一个很大的问题。
1，如果数据库参数remote_dependencies_mode设置为timestamp，如果重新编译一个包，所有调用这个包的存储过程也必须重新编译。如果该参数值是signature，则不需要考虑这个问题。通常，存储在数据库中的包会被自动更新。
2，FORM或者挂载的库，如果它调用了那个核心包，而核心包重新编译过，则必须手工重新编译FORM或相应的库。
3，正常情况下，人们总是喜欢用成熟的统一的函数来运算，因而调用该核心包的场所会越来越多，直至开发人员可能无法清楚记得哪些表单需要使用到这个类。
以上情况造成了棘手的问题，如果核心包被人修改——一般是有计划的不得不进行的修改——则必须编译所有相关的表单，这里存在了影响业务数据的风险。
经验，总是在挫折中汲取：
1，对于少量特殊的包，不妨花点时间写文档，记录被哪些业务关键表单调用了。
2，尽可能的，每个表单对应某个特定的功能，同时创建一个该功能专用的包供表单调用，通过该专用包来间接调用核心包。
3，不必太多的引用其他表单，某些场合不妨尝试使用copy。
就像范式，有时候，一定的冗余反而提高效率，降低后期维护成本。
P.S: 我是不是该学一些软工的知识？
弹性域DEBUG
EBS提供了全局变量 GLOBAL.FND_FLEX_FNDSQF_DEBUG 用于对弹性域相关信息的纠错。设置方法很简单，只需要在 诊断->检查 中设置该变量的值即可。
具体有以下几个值：
1. OFF。默认为关闭状态，弹性域的初始化或者相关事件都不显示。
2. EXCEPTION。只有抛出异常时才显示信息，该信息从WHEN OTHERS THEN抛出。
3. FAILURE。失败或者异常时都显示信息，通常是在IF (NOT FORM_SUCCESS) THEN中的信息。
4. DEBUG。显示所有弹性域相关信息。
该变量可以随时设置。