Skip to Main Content

APEX

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Error installing application

John VaughanSep 5 2008 — edited Sep 5 2008
Dear all - our main application export file has now grown to over 15MB,
and we've started having problems installing it into other workspaces.
It's not actually the upload that fails (which some users have
experienced, and seems to be related to an HTTP server timeout), but
the next step; installing it. The browser timeout error happens after
you have loaded the application, but before the page loads that prompts
for the parsing schema and app ID. Clicking on Install from the Export
Repository leads to the same error.

Although we have not yet got
to the bottom of that problem, the received advice seems to be to
install the application using SQL*Plus. Although this seems to
introduce plenty of opportunities for getting it to go wrong, the basic
advice (taken from one of Scott Spadafore's posts on the subject) is:

+"This
is not a normal approach. You'd have to edit the primary application
export file for each new application you want to create. Look through
the file and change references to the "exported" application ID to the
desired application ID. They will be in lines like the following where
I show 9999 as the original ID:+

+wwv_flow.g_flow_id := 9999;+

+wwv_flow_api.remove_flow(9999);+

+wwv_flow_audit.remove_audit_trail(9999);+

+wwv_flow_api.create_flow(+

+ p_id =>9999,+

+ p_display_id=> 9999,+

+ p_alias => 'F9999',+

+ p_owner => 'FOO',+

+For
the "p_owner => 'F00' " case, change the parsing schema FOO to the
new parsing schema, making sure that the schema is actually mapped to
the target workspace.+

+Then you need to look for any text
containing "f?p=9999:..." and change the old application ID to the new
one. There may be none of these in your application but if you find
any, you should also change all of those occurrences in the original
application to use &APP_ID. instead of 9999.+

+Finally, locate
the line: "wwv_flow_api.g_id_offset := 0;" near the top of the file and
change 0 to 1 for the first "new" application, change it to 2 for the
second "new" application, etc. If during import you get any kind of
unique key constraint errors, go back and change the offset to a larger
integer and try again.+

+N.B., this approach cannot be used if your application has been translated."+

However, doing this lead (in our case) to the error:

Illegal security group id value for this schema

and, later in the SQL*Plus prompts:

ORA-20001: Package variable g_security_group_id must be set

Near the beginning of the installation script file, there is the statement:

wwv_flow_api.set_security_group_id(p_security_group_id=>NNNNNNNNNNNNNNNNN);

(where NNNNNNNNNNNNNNNNN
is a large number). Because we are installing from one workspace to
another, and because of the nature of the error message, I tried
replacing this number with the value for the target workspace, obtained
using:

select wwv_flow_api.get_security_group_id() from dual

Having done this, the script ran without error.

Thought I'd post this in case it helps anyone.

Regards,

John.

Comments

unknown-7404
I'm facing an issue when I upgrade my ojdbc14.jar to ojdbc6.jar

Issue :

          data_type value for Date and Timestamp is same  ie., 93 if we use ojdbc6.jar.

          data_type value for Date and Timestamp is different as 91 and 93, if we use ojdbc14.jar.

          My Batch job fetches the data_type of the Oracle 11g TABLE and inserts value according to the data_type value it fetches.

          I have tried using ResultSetMetaData and DatabaseMetaData to get data_type value using getMetadata() method.

          Is there anyway to differentiate the Date and Timestamp data_type value using ojdbc6.jar?.

The Oracle JDBC FAQ explains the issue that existed in the older JDBC driver and how Oracle fixed the problem.

Oracle JDBC Frequently Asked Questions

What is going on with  DATE and  TIMESTAMP

This section is on  simple data types. :-) 

Prior to 9.2, the Oracle JDBC drivers mapped the  DATE SQL type to  java.sql.Timestamp. This made a certain amount of sense because the Oracle  DATE SQL type contains both date and time information as does  java.sql.Timestamp. The more obvious mapping to  java.sql.Date was somewhat problematic as  java.sql.Date does not include time information. It was also the case that the RDBMS did not support the  TIMESTAMP SQL type, so there was no problem with mapping  DATE to  Timestamp

In 9.2  TIMESTAMP support was added to the RDBMS. The difference between  DATE and  TIMESTAMP is that  TIMESTAMP includes nanoseconds and  DATE does not. So, beginning in 9.2,  DATE is mapped to  Date and  TIMESTAMP is mapped to  Timestamp. Unfortunately if you were relying on  DATE values to contain time information, there is a problem. 

There are several ways to address this problem in the 9.2 through 10.2 drivers:

. . .

Oracle JDBC 11.1 fixes this problem. Beginning with this release the driver maps SQL DATE columns to  java.sql.Timestamp by default.

Read the entire FAQ.

What 'differentiation' are you talking about? For Oracle the ONLY difference between date and timestamp is, as the quote says, that timestamp includes nanoseconds.

If you need more help than the above then you need to SHOW US (not just tell us):

1. WHAT you do - post the actual code that supports the statements you made in your post

2. HOW you do it

3. WHAT results you get - show us the results

1 - 1
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Oct 3 2008
Added on Sep 5 2008
1 comment
422 views