Executing a Query in Forms 10g Fails With Frm-41838 Unable To Open Temporary Record File

A query executed in a Forms application fails giving the following error:

FRM-41838 Unable to open temporary record file

Cause

Oracle Forms tries to create a temporary file if a query is issued and the number of records returned exceeds the block property 'Records Buffered' value. When using OracleAS Forms Services, the temporary file will be written by default to the directory specified for the TMP variable in:

$ORACLE_HOME/opmn/conf/opmn.xml.

If this directory does not exist, has insufficient space or has restricted read / write privileges the FRM-41838 error can occur.
Solution

Solution A:

1. Edit the Forms Listener Servlet env file. This will be the file referenced by the formsweb.cfg applet parameter envFile. By default, envFile = default.env, default.env is located in $ORACLE_HOME/forms90/server or in $ORACLE_HOME/forms/server

2. Add the line e.g.

TMP=/tmp

(assuming that the directory specified e.g. /tmp has sufficient space and read/write privileges)

3. Stop and restart the OC4J_BI_Forms component for the change to take effect

Solution B:

Change the value for the TMP variable setting in opmn.xml by following all the steps below:

1. Edit $ORACLE_HOME/opmn/conf/opmn.xml where $ORACLE_HOME corresponds to the Oracle Application Server middle tier home (BI & Forms)

2. Look for the line e.g. on Unix

3. Check that the directory specified exists, has sufficient space and read/write privileges. If necessary, change the TMP value e.g.

4. If the directory has been changed in opmn.xml, stop and restart all the middle tier components for the change to take effect.

Source : Oracle Metalink Doc ID: 304004.1

How to Automate Splitting OC4J log Files for Web Sites (default-web-access.log)

How to Automate Splitting OC4J log Files for Web Sites (default-web-access.log) [ID 764085.1]

Applies to:
Oracle Containers for J2EE - Version: 10.1.3.0.0 to 10.1.3.4.0
Oracle Containers for J2EE - Version: 10.1.2.0.0 to 10.1.2.3.0

Goal
How to automate log file splitting on text-based OC4J log file default-web-access.log located in $ORACLE_HOME/j2ee//log/_default_group_1 in Oracle Application Server based on period of time?

Solution
To automate log file splitting on default-web-access.log, add the "split" attribute to element in $ORACLE_HOME/j2ee//config/default-web-site.xml

This "split" attribute specifies how often to begin a new access log, supported values are "none" (equivalent to "never", which is the default), "hour", "day", "week", and "month".

To implement this solution:

1. Change the following line in default-web-site.xml
<access-log path="../log/default-web-access.log"/> 

to:
<access-log path="../log/default-web-access.log" split="week"/>

2. OC4J instance restart is required for these changes to take effect.
$ORACLE_HOME/opmn/bin/opmnctl stopproc process-type=home
$ORACLE_HOME/opmn/bin/opmnctl startproc process-type=home

Source : Oracle Metalink Doc Id: 764085.1

Limit the Size of the default-web-access.log

Applies to: Oracle Application Server 10g Enterprise Edition - Version: 10.1.2.0.0

Out of the box, the default-web-access.log will continue to grow until it is removed.

The default-web-site.xml file can be modified to allow for the logs to be cycled automatically and prevent default-web-access.log from growing too large and exhausting the disk storage.

Solution

To allow for the default-web-access.log file to be automatically cycled add the "split" variable to the default-web-site.xml logging parameter.

split: Specifies how often to begin a new access log. Supported values are "none" (never, which is the default), "hour", "day", "week", or "month". For a value other than "none", logs are named according to the suffix attribute. NOTE: the values are case sensitive and must be contained within double quotes. The suffix attribute is not needed if default naming is acceptable.

To make the change, change the final line in your default-web-site.xml

From:
access-log path="../log/default-web-access.log" /

to
access-log path="../log/default-web-access.log" split ="week"/

Note: all greater than and less than symbols have been removed in the example. Please be sure to leave them intact in the file mentioned.

This change will cause a new file to be created each week for the default-web-access.log. Old files can be removed from the directory and archived. Feel free to use the "month" parameter instead, if this meets your needs.

Source : Oracle Metalink Doc ID 572213.1

Opmnctl Startall fails with Failed To Start a Process Because A Dependency Check Failed

OID is not running or unavailable

Subject: opmnctl Startall fails with Failed To Start a Process Because A Dependency Check Failed

Cause

A midtier attached to an infrastructure has by default the dependency of OID declared in opmn.xml, but it can be removed without any risk if OID is not used by these OC4J instances.

The OID dependency is just needed if JAZN-LDAP or SSO authentication methods have been setup.

Solution
-- To implement the solution, please execute the following steps::

1) Backup the file $ORACLE_HOME/opmn/conf/opmn.xml
2) Edit $ORACLE_HOME/opmn/conf/opmn.xml and locate the lines:


<ias-component id="OC4J">
<dependencies>
<OID infrastructure="true"/>
</dependencies>
<process-type id="home" module-id="OC4J" status="disabled">
<module-data>
<category id="start-parameters">


3) Remove the lines:


<dependencies>
<OID infrastructure="true"/>
</dependencies&gt


i.e. the section will become:

<ias-component id="OC4J">

<process-type id="home" module-id="OC4J" status="disabled">
<module-data>
<category id="start-parameters">;


4) Save the file
5) Run the commands:

$ORACLE_HOME/opmn/bin/opmnctl stopall
$ORACLE_HOME/opmn/bin/opmnctl startall

Source : Oracle Metalink Doc ID: Note:401882.1

ORA 4021 - time-out occurred while waiting to lock object

Problem Description

-------------------

Trying to recreate a package, procedure or function (CREATE OR REPLACE ...) or dropping a the same (DROP PACKAGE ...) causes the application to hang (ie: SQL*Plus hangs after submitting the statement). Eventually ORA-4021 errors occur after the timeout (usually 5 minutes).

Solution Description

Verify that the package is not locked by another user by selecting from V$ACCESS view.  To do this, run:

SELECT * FROM v$access WHERE object = '';

Where is the package name (usually in all uppercase).  If there is a row returned, then the package is already locked and cannot be dropped until the lock is released.  Returned from  he query above will be the SID that has this locked. You can then use this to find out which session has obtained the lock.

In some cases, that session might have been killed and will not show up.  If this happens, the lock will not be release immediately.  Waiting for PMON to clean up the lock might take some time. The fastest way to clean up the lock is to recycle the database instance.

If an ORA-4021 error is not returned and the command continues to hang after issuing the CREATE OR REPLACE or DROP statment, you will need to do further analysis see where the hang is occuring. A starting point is to have a look in v$session_wait, see the referenced Note 61552.1 for how to analyze hang situations in general

Solution Explanation

Consider the following example:

Session 1:

create or replace procedure lockit(secs in number) as

shuttime date;

begin

shuttime := sysdate + secs/(24*60*60);

while sysdate <= shuttime loop

null;

end loop;

end;

/

show err

begin

-- wait 10 minutes

lockit(600);

end;

/

Session 2:

SQL> create or replace procedure ops$hnapel.lockit as

2  begin

3     null;

4  end;

5  /

Result: hang and eventually (the timeout is 5 minutes):

create or replace procedure ops$hnapel.lockit as

*

ERROR at line 1:

ORA-04021: timeout occurred while waiting to lock object OPS$HNAPEL.LOCKIT

Session 3:

SQL> connect  / as sysdba

Connected.

SQL> col owner for a10

SQL> col object for a15

SQL> select * from v$access where object = 'LOCKIT';

SID OWNER      OBJECT          TYPE

---------- ---------- --------------- ------------------------

9 OPS$HNAPEL LOCKIT          PROCEDURE

SQL> select sid, event from v$session_wait;

SID EVENT

---------- ----------------------------------------------------------------

9 null event

...

12 library cache pin

As you can see, the blocking sid 9 waits for nothing while session 2, the hanging session, is waiting for event library cache pin.

Source : Oracle Metalink

Database Links: Troubleshooting ORA-2085 "database link %s connects to %s"

  

To explain database link naming rules in an effort to avoid the error ORA-2085 "database link %s connects to %s"

When the source database initialization parameter GLOBAL_NAMES is set to true, the database link name must match the target database global name as it exists in the GLOBAL_NAME view in the data dictionary.

The GLOBAL_NAME can be determined by logging in to the database with system privileges and issuing the following command:

SQL>Select * from global_name;

Additionally, if you do not specify the domain portion of the dblink name in the create statement, Oracle automatically qualifies the link name with the domain of the SOURCE database global name view.

Check the contents of ALL_DB_LINKS for the fully qualified link name.

For example, if you defined a database link in PROD.ORACLE.COM to connect to target instance TEST.WORLD.COM in the following manner:

SQL>Create public database link TEST connect to userid identified by password using test;

SQL>select * from tablename@TEST;

This select would yield the following error:

ORA-2085 "database link TEST.ORACLE.COM connects to TEST.WORLD.COM"

The correct syntax for defining the link would be:

SQL>Create public database link TEST.WORLD.COM connect to userid identified by password using test;

SQL>select * from tablename@TEST.WORLD.COM;

Would yield desired result.

It is possible to alter the GLOBAL_NAME table so that the domain portion of both SOURCE and TARGET global names are identical. This would eliminate the need to include the domain in the create database link statement.

In the above example, we could alter the GLOBAL_NAME of TEST.WORLD.COM in the following manner:

Login to TEST with system privileges and issue:

SQL>alter database rename global_name to TEST.ORACLE.COM;

Now, the create database link statement could also be changed.

Login to PROD.

SQL>create public database link TEST connect to userid identified by password using test;

A database link would be defined in ALL_DB_LINKS as TEST.ORACLE.COM.

SQL>select * from tablename@TEST;

This would yield the desired result.

PDF Printing slovenian characters problem

PDF Printing slovenian characters problem :

http://www.dba-village.com/village/dvp_forum.OpenThread?ThreadIdA=11031

As I understand the limitation of reports 6i is due to the fact that Reports 6i has builtin support for an older PDF standard V1.1.

It's a documented limitation, see Metalink Note 222663.1.

"PDF output is only supported for latin 1 code pages (US7ASCII, WE8ISO8859P1 and WE8MSWIN1252). "