HTMLDB 1.6 load_de.sql bug ?

I installed HTMLDB 1.6 as an upgrade to the one on the companion CD.
Since my native language is german, I like to have HTMLDB speaking german language with me. So I opened sqlplus as sys with sysdba privs, altered the session schema to FLOWS_010600 and started the Language update via @load_de.
after some working statements I got the following error message and the installation stops:
Error page=4316.4003 item="F4000_P4316_VALIDATION_TYPE" id="22211144053.4003"
declare
ERROR at line 1:
ORA-06502: PL/SQL: numeric or value error
ORA-06512: at "SYS.OWA_UTIL", line 325
ORA-06512: at "SYS.HTP", line 1322
ORA-06512: at "SYS.HTP", line 1397
ORA-06512: at "SYS.HTP", line 1689
ORA-06512: at "FLOWS_010600.WWV_FLOW_API", line 3191
ORA-01461: can bind a LONG value only for insert into a LONG column
ORA-06512: at line 69
Any hints ?
cu Pete

Peter,
I believe there's a bug lurking in HTML DB somewhere. Your situation is identical to the one described in:
Re: Installation Error 1.6
The odd thing is, we have been unable to reproduce it (loading with NLS_LANG german_germany.al32utf8 works just fine). I also asked a couple colleagues in Germany if they've had any difficulty, and they have never encountered this.
If you would be so kind, could you please let me know the following information:
1) The database version you are using
2) The operating system (name and version)
3) Your database character set
4) The version and operating system of SQL*Plus you're using (in the event you're doing this installation remotely)
If you feel uncomfortable posting this on OTN, could you please just e-mail this info to [email protected]?
Thanks in advance for any assistance you can provide.
viele GrÃ¼Ãe,
Joel

Similar Messages

Error after load_de.sql in 2.2.1.0.0.4

I experienced this error message:
ERR-1016 Anwendung "4550" Seite "11" nicht gefunden (angeforderte Sprache="de")
after having loaded the german language (running load_de.sql - I did set nls_lang=AMERICAN_AMERICA.AL32UTF8) and had logged in as user FLOWS_0202000;
whenever I switch to English (US) everything seem to work fine, whereas with Browser-Language= German I get above error.
BTW: I did apply for new the latest 2.2.1 patch as stipulated in the post installation tasks.
How to get around that one ?
Thanks for ur assistance.
Bernhard
Message re: BTW: was edited by:
BernhardFW

Joel,
the answer to your last question: Can you then use APEX in Geman? NO. -
I originally came from 1.6 (from the companian CD or download), than upgraged to 2.0 - then to 2.2 then applied the generic patch).
I can login with Browser set to Engl.(US) - when I then switch the browser from Engl./US to Geman in the App.Builder (Engl.page 1500) - I get:
"ERR-1016 Anwendung "4000" Seite "1500" nicht gefunden (angeforderte Sprache="de")
Zurück zur Anwendung."
I switch to Engl. and to SQL Workshop - page 3002 - then switch to DE and refresh and get:
"ERR-1016 Anwendung "4500" Seite "3002" nicht gefunden (angeforderte Sprache="de")"
Hope that assists.
Bernhard
BTW: users who download the HTMLDB/APEX sources via the Companian CD do receive the 1.6 sources and then have to upgrade to 2.0 or 2,2, etc.
Why don't they receive the 2.2 sources straight away ?

SQL Bug in "Minus" in correlated subquery presence of index (11.2.0.1.0)

SQL Bug in "Minus" in correlated subquery presence of index
(Oracle Database 11g Release 11.2.0.1.0)
Below, there is a small example that shows the bug. Further below,
there are some more comments.
drop table Country;
create table Country
(code VARCHAR2(4) constraint countrykey PRIMARY KEY,
name VARCHAR2(35));
-- if the key constraint is not given, the bug does not occur
drop table City;
create table City
(name VARCHAR2(35),
country VARCHAR2(4),
population number);
drop table Locatedon;
create table Locatedon
(city VARCHAR2(35),
country VARCHAR2(4),
island VARCHAR2(35));
insert into country values('E','Spain');
insert into country values('F','France');
insert into country values('S','Sweden');
insert into country values('GB','Sweden');
insert into city values('Ajaccio','F',53500);
insert into city values('Paris','F',2152423);
insert into city values('Palma','E',322008);
insert into city values('Madrid','E',3041101);
insert into city values('Stockholm','S',711119);
insert into city values('London','GB',6967500);
insert into locatedon values('Ajaccio','F','Corse');
insert into locatedon values('Palma','E','Mallorca');
insert into locatedon values('London','GB','Great Britain');
-- all countries that have a city that is not located on
-- some island: should be E, F, S.
Select c.name
From country c
Where exists
((Select name
From city
Where city.country=c.code)
minus
(Select city
From locatedon
Where locatedon.country=c.code)
-- wrong answer: only Sweden; Spain and France not in the answer!
select distinct country from
((Select name, country
From city)
minus
(Select city, country
From locatedon)
-- correct answer: E, F, S
Comments:
The bug has been found by students in our SQL course.
Using a larger database from that course, the bug can be reproduced
(same queries as above) at
http://www.semwebtech.org/sqlfrontend/
(wrong: 142 answers, correct: 154 answers)
During reducing it to a simple sample, there were some interesting
observations: trying with smaller and simpler tables (without the keys)
and synthetic data, the bug did not occur immediately. When
restating the query after about one day, the bug occurred. Obviously,
Oracle creates some index on its own in course of its internal
optimization that (or more exactly, its usage) exhibits the bug. The
query plan (showed in SQL Developer) was the same before and after.
Wolfgang

There's a typo in the test data - GB should presumably not be in Sweden. However....
the bug did not occur immediatelyIt's possible. But what would have almost certainly happened is that the execution plan DID change at some point. There are various reasons why it might not be immediate.
Obviously, Oracle creates some index on its own in course of its internal optimizationFar from obvious, what are you on about?
The query plan was the same before and afterBet you it wasn't.
A clear illustration of the issue and indication that it must be a bug is below.
Simply by hinting a different access method, we can change the result. Therefore, bug.
See [url http://support.oracle.com]Oracle Support and search for "wrong results".
Please raise with Oracle Support to get confirmation of bug.
There have been so many wrong results bugs recently, it's getting ridiculous.
It's a real issue, IMHO.
If you can't trust the DB to get your data right....
Note that the query plan is very much NOT the same and it is the difference in query plan which s that is the root cause of the bug.
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE    11.2.0.2.0      Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
SQL> SELECT c.name
2 FROM   country1 c
3 WHERE exists ((SELECT name
4                  FROM   city1
5                  WHERE city1.country=c.code)
6                  MINUS
7                 (SELECT city
8                  FROM   locatedon1
9                  WHERE locatedon1.country=c.code));
NAME
Sweden
SQL> SELECT /*+ full(c) */
2         c.name
3 FROM   country1 c
4 WHERE exists ((SELECT name
5                  FROM   city1
6                  WHERE city1.country=c.code)
7                  MINUS
8                 (SELECT city
9                  FROM   locatedon1
10                  WHERE locatedon1.country=c.code));
NAME
Spain
France
Sweden
SQL> explain plan for
2 SELECT c.name
3 FROM   country1 c
4 WHERE exists ((SELECT name
5                  FROM   city1
6                  WHERE city1.country=c.code)
7                  MINUS
8                 (SELECT city
9                  FROM   locatedon1
10                  WHERE locatedon1.country=c.code));
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 156929629
| Id | Operation                    | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |            |     1 |    27 |    12 (25)| 00:00:01 |
|   1 | NESTED LOOPS                |            |       |       |            |          |
|   2 |   NESTED LOOPS               |            |     1 |    27 |    12 (25)| 00:00:01 |
|   3 |    VIEW                      | VW_SQ_1    |     6 |    24 |    10 (20)| 00:00:01 |
|   4 |     MINUS                    |            |       |       |            |          |
|   5 |      SORT UNIQUE             |            |     6 |   138 |            |          |
|   6 |       TABLE ACCESS FULL      | CITY1      |     6 |   138 |     4   (0)| 00:00:01 |
|   7 |      SORT UNIQUE             |            |     3 |    69 |            |          |
|   8 |       TABLE ACCESS FULL      | LOCATEDON1 |     3 |    69 |     4   (0)| 00:00:01 |
|* 9 |    INDEX UNIQUE SCAN         | COUNTRYKEY |     1 |       |     0   (0)| 00:00:01 |
| 10 |   TABLE ACCESS BY INDEX ROWID| COUNTRY1   |     1 |    23 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   9 - access("VW_COL_1"="C"."CODE")
Note
   - dynamic sampling used for this statement (level=4)
26 rows selected.
SQL> explain plan for
2 SELECT /*+ full(c) */
3         c.name
4 FROM   country1 c
5 WHERE exists ((SELECT name
6                  FROM   city1
7                  WHERE city1.country=c.code)
8                  MINUS
9                 (SELECT city
10                  FROM   locatedon1
11                  WHERE locatedon1.country=c.code));
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1378726376
| Id | Operation            | Name       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT     |            |     1 |    23 |    14 (15)| 00:00:01 |
|* 1 | FILTER              |            |       |       |            |          |
|   2 |   TABLE ACCESS FULL | COUNTRY1   |     4 |    92 |     4   (0)| 00:00:01 |
|   3 |   MINUS              |            |       |       |            |          |
|   4 |    SORT UNIQUE       |            |     1 |    23 |     5 (20)| 00:00:01 |
|* 5 |     TABLE ACCESS FULL| CITY1      |     1 |    23 |     4   (0)| 00:00:01 |
|   6 |    SORT UNIQUE       |            |     1 |    23 |     5 (20)| 00:00:01 |
|* 7 |     TABLE ACCESS FULL| LOCATEDON1 |     1 |    23 |     4   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter( EXISTS ( (SELECT "NAME" FROM "CITY1" "CITY1" WHERE
              "CITY1"."COUNTRY"=:B1)MINUS (SELECT "CITY" FROM "LOCATEDON1" "LOCATEDON1"
              WHERE "LOCATEDON1"."COUNTRY"=:B2)))
   5 - filter("CITY1"."COUNTRY"=:B1)
   7 - filter("LOCATEDON1"."COUNTRY"=:B1)
Note
   - dynamic sampling used for this statement (level=4)
27 rows selected.Just to show that it's related to query transformation:
SQL> SELECT /*+
2             no_query_transformation
3         */
4         c.name
5 FROM   country1 c
6 WHERE exists ((SELECT name
7                  FROM   city1
8                  WHERE city1.country=c.code)
9                  MINUS
10                 (SELECT city
11                  FROM   locatedon1
12                  WHERE locatedon1.country=c.code));
NAME
Spain
France
Sweden
SQL> Edited by: Dom Brooks on Jun 30, 2011 2:50 PM

PL/SQL Bug in SQL Developer?

SQL Developer v 1.1.1.25 running on Windows XP.
I have a PL/SQL procedure that does not compile with debug in SQL Developer. Compiling it with debug produces the following error:
an Error(1): PLS-00801: internal error [79110].The only way I was able to get the procedure to compile in SQL Developer was to add the 4th line. If I uncomment the 4th line it compiles with debug. Why??
Here is the procedure:
CREATE OR REPLACE
PROCEDURE BOGUS AS
CURSOR c1 IS
SELECT dummy FROM DUAL;
-- x c1%ROWTYPE;
PROCEDURE test ( rec IN OUT c1%ROWTYPE) IS
begin
null;
end;
BEGIN
NULL;
END BOGUS;Message was edited by:
marife
I played around some more with the procedure and discovered the problem. The key is the compiling with debug. I believe that compile with debug cannot build the debug information for a %ROWTYPE as a parameter. But if I define a local variable of that %ROWTYPE, then the compile with debug knows what debug information to track for the %ROWTYPE.
I discovered that in SQL*Plus it compiles, but when you issue the ALTER PROCEDURE bogus COMPILE DEBUG, it does not compile. This is a problem with the debug option for compiling and not a problem with SQL Developer.
Sorry for the posting. Hopefully this information will save other times and fustration.
Mike

Just for anyone else searching on this bug - I get the same error with certain procedures in TOAD when compiling with DEBUG.
Fortunately nobody here has the first clue how to use TOAD debug so it's only ever switched on by accident or after a reinstall (it's the default) - so turning debug off fixes the problem.

HTML DB authorisation via PL/SQL bug?

I tried to implement a simple authorisation package and failed. This seems to be a bug in HTML DB.
See below for package body. I have a function check_user and a procedure check_user2.
When I enter a call to the procedure in my Authorization Scheme (PL/SQL Function Returning Boolean) I get what I deserve:
auth2.check_user2(:APP_USER)
results in: ORA-06503: PL/SQL: Function returned without value
When I use the function instead however the error I get seems less justified:
auth2.check_user(:APP_USER)
ORA-06550: line 1, column 44: PLS-00221: 'CHECK_USER' is not a procedure or is undefined ORA-06550: line 1, column 44: PL/SQL: Statement ignored
It seems HTML DB is checking to make sure it finds a 'procedure' - but it really needs a 'function'...
Just for completeness the package body:
create or replace package body auth2
is
function check_user( P_USER IN VARCHAR2) return boolean
as
begin
insert into hr_log (log_txt) values (p_user);
return True;
end check_user;
procedure check_user2( P_USER IN VARCHAR2)
as
begin
insert into hr_log (log_txt) values (p_user);
commit;
end check_user2;
end auth2;
/

Peter - When HTML DB calls for a Function Returning Boolean it's looking for you to have specified a call to a function whether you put the code within a begin-end or you let HTML DB do it. What you entered was (when framed in begin-end) syntactically a procedure call within an anonymous block. Try entering "return auth2.check_user(:APP_USER);" (without quotes).
Scott

TopLink EJBQL- SQL bug?

Hi
I have this EJB QL query:
delete from Przejazd p where p.id in (
    select p2.id from Przejazd p2 join p2.lista l
    where l.id = :listaId
)And it's producing this SQL:
DELETE FROM PRZEJAZD
WHERE EXISTS(
SELECT t0.ID FROM PRZEJAZD t0
WHERE t0.ID IN (
    (SELECT t1.ID FROM PRZEJAZD t3, LISTA t2, PRZEJAZD t1
        WHERE (t2.ID = CAST (? AS INTEGER )
        AND   (t2.ID = t3.LISTA_ID)))
AND t0.ID = PRZEJAZD.ID
)I think the SQL should look like this:
DELETE FROM PRZEJAZD
WHERE EXISTS(
SELECT t0.ID FROM PRZEJAZD t0
WHERE t0.ID IN (
    (SELECT t3.ID FROM PRZEJAZD t3, LISTA t2
        WHERE (t2.ID = CAST (? AS INTEGER )
        AND   (t2.ID = t3.LISTA_ID)))
AND t0.ID = PRZEJAZD.ID
)It's a TopLink bug, or am I missing something?

Hi
I have this EJB QL query:
delete from Przejazd p where p.id in (
    select p2.id from Przejazd p2 join p2.lista l
    where l.id = :listaId
)And it's producing this SQL:
DELETE FROM PRZEJAZD
WHERE EXISTS(
SELECT t0.ID FROM PRZEJAZD t0
WHERE t0.ID IN (
    (SELECT t1.ID FROM PRZEJAZD t3, LISTA t2, PRZEJAZD t1
        WHERE (t2.ID = CAST (? AS INTEGER )
        AND   (t2.ID = t3.LISTA_ID)))
AND t0.ID = PRZEJAZD.ID
)I think the SQL should look like this:
DELETE FROM PRZEJAZD
WHERE EXISTS(
SELECT t0.ID FROM PRZEJAZD t0
WHERE t0.ID IN (
    (SELECT t3.ID FROM PRZEJAZD t3, LISTA t2
        WHERE (t2.ID = CAST (? AS INTEGER )
        AND   (t2.ID = t3.LISTA_ID)))
AND t0.ID = PRZEJAZD.ID
)It's a TopLink bug, or am I missing something?

Oracle SQL - Bug

Hi All,
I am writing this so that someone someday can take this to Oracle Corp as this is a simple bug which ought to be rectified by Oracle.
Eg: select * from emp a where a.empno in ( select empno from empl b)
Here i am using an Isolation Level 1 by using a Sub-Query to only return rows that matches with empno in table Empl but Empl table used in Sub Query does not have a Column by name empno . This should have returned an Oracle error instead it is taking the Column alias of table emp in Main Query.
Many of us here will think or presume that this is correct as when using Isolation levels but this is not happening that way . There is an Oracle Bug which ought to be rectified in their next release.

Definitively not a bug, at least bad query writing.
Use prefix should solve your problem, something like this :
select * from emp a where a.empno in ( select[b] b.empno from empl b)Furthermore, I wouldn't understand why you want, in the subquery, get the empno from the emp table instead of empl.
Here was some threads about that, please read one of them here below :
Re: Bug in Oracle 9.2.0.1.0.
Moreover, this is not because you said "many of us here" want a correction that Oracle will correct it, because that's not a bug !
Nicolas.

SQL Bug on 11.2

We recently upgraded to 11.2, but had to downgrade back to 10.2 due to an error with part of our application. This error does not occur in version 10 or 11.1. We are running Oracle on Windows 2003 Server (happens on my laptop also, Windows 7). We have asked a customer to run the query who run Oracle on Linux, same problem.
To replicate this, I have simplified the table, view and query below, but the error still occurs. Note that it is four queries unioned. My developers insist that this is best practice to get the data they want so who am I to argue - fact that there are full table scans going on is irrelevant. Run each query on its own is fine. Take the last unioned query out and it works fine. Have all four queries and it fails.
Table required:
Create table GT_CONTACT_LVL1_DATA (
LOCATIONID NUMBER(8) ,
CALL_LOCATIONID NUMBER(8) ,
LOC_SEQ NUMBER(3) ,
CONTACTID NUMBER(8) ,
CALL_CONTACTID NUMBER(8) ,
CALL_SEQ NUMBER(3) ,
LOC_REFNO VARCHAR2(60) ,
PHONE VARCHAR2(40) ,
PHONE_TYPE VARCHAR2(8) ,
CASENO VARCHAR2(12) ,
VERSION NUMBER(3) ,
REP_SEQ NUMBER(3));
View required:
CREATE OR REPLACE VIEW VW_GT_CONTACT_TEL
AS
SELECT LOCATIONID, CONTACTID, CASENO, REP_SEQ, PHONE, LOC_REFNO
FROM GT_CONTACT_LVL1_DATA
WHERE PHONE_TYPE = 'TEL';
The query:
SELECT DISTINCT DR.LOCATIONID, DR.CALL_LOCATIONID, DR.LOC_SEQ, DR.CONTACTID, DR.CALL_CONTACTID, DR.CALL_SEQ,DR.CASENO, DR.VERSION, DR.REP_SEQ,
DR.LOC_REFNO, DR1.PHONE
FROM GT_CONTACT_LVL1_DATA DR LEFT OUTER JOIN VW_GT_CONTACT_TEL DR1 ON DR1.LOCATIONID = DR.LOCATIONID AND DR1.CONTACTID = DR.CONTACTID
AND DR.CASENO = DR1.CASENO
WHERE DR.CASENO IS NOT NULL AND
(DR.LOCATIONID,DR.CONTACTID) IN (SELECT LOCATIONID,CONTACTID FROM GT_CONTACT_LVL1_DATA D
WHERE CASENO IS NULL AND D.CONTACTID = DR.CONTACTID
AND D.LOCATIONID = DR.LOCATIONID)
UNION
SELECT DISTINCT DD.LOCATIONID, DD.CALL_LOCATIONID, DD.LOC_SEQ, DD.CONTACTID, DD.CALL_CONTACTID, DD.CALL_SEQ,DD.CASENO, DD.VERSION, DD.REP_SEQ,
DD.LOC_REFNO, DD1.PHONE
FROM GT_CONTACT_LVL1_DATA DD LEFT OUTER JOIN VW_GT_CONTACT_TEL DD1 ON DD1.LOCATIONID = DD.LOCATIONID AND DD1.CONTACTID = DD.CONTACTID
AND DD.CASENO = DD1.CASENO
WHERE DD.CASENO IS NULL AND
(DD.LOCATIONID,DD.CONTACTID) IN (SELECT LOCATIONID,CONTACTID FROM GT_CONTACT_LVL1_DATA D
WHERE CASENO IS NOT NULL AND D.CONTACTID = DD.CONTACTID
AND D.LOCATIONID = DD.LOCATIONID)
union
SELECT DISTINCT DR.LOCATIONID, DR.CALL_LOCATIONID, DR.LOC_SEQ, DR.CONTACTID, DR.CALL_CONTACTID, DR.CALL_SEQ,DR.CASENO, DR.VERSION, DR.REP_SEQ,
DR.LOC_REFNO, DD.PHONE
FROM GT_CONTACT_LVL1_DATA DR LEFT OUTER JOIN VW_GT_CONTACT_TEL DD ON DD.CASENO = DR.CASENO AND DD.REP_SEQ = DR.REP_SEQ
AND DR.CASENO = DD.CASENO
WHERE DR.CASENO IS NOT NULL
AND (DR.LOCATIONID,DR.CONTACTID) NOT IN (SELECT LOCATIONID,CONTACTID FROM GT_CONTACT_LVL1_DATA WHERE CASENO IS NULL)
UNION
SELECT DISTINCT DD.LOCATIONID, DD.CALL_LOCATIONID, DD.LOC_SEQ, DD.CONTACTID, DD.CALL_CONTACTID, DD.CALL_SEQ,DD.CASENO, DD.VERSION, DD.REP_SEQ,
DD.LOC_REFNO, DD1.PHONE
FROM GT_CONTACT_LVL1_DATA DD LEFT OUTER JOIN VW_GT_CONTACT_TEL DD1 ON DD1.LOCATIONID = DD.LOCATIONID AND DD1.CONTACTID = DD.CONTACTID
AND DD.CASENO = DD1.CASENO
WHERE DD.CASENO IS NULL
AND (DD.LOCATIONID,DD.CONTACTID) NOT IN (SELECT LOCATIONID,CONTACTID FROM GT_CONTACT_LVL1_DATA WHERE CASENO IS NOT NULL);
Error:
Error at Command Line:43 Column:90
Error report:
SQL Error: ORA-01790: expression must have same datatype as corresponding expression
01790. 00000 - "expression must have same datatype as corresponding expression"
*Cause:
*Action:
Anyone have any idea what could be causing this and what we can do (apart from the obvious splitting the query) to fix this.
Many thanks.
James

I Can reproduce the issue without problem.
The query however needs to be revised, as all DISTINCTs are redundant: UNION will filter out duplicates as UNION is a set operation and by definition sets don't contain duplicates.
I have formatted the query to make it readable
SELECT DR.LOCATIONID,
        DR.CALL_LOCATIONID,
        DR.LOC_SEQ,
        DR.CONTACTID,
        DR.CALL_CONTACTID,
        DR.CALL_SEQ,
        DR.CASENO,
        DR.VERSION,
        DR.REP_SEQ,
        DR.LOC_REFNO,
        DR1.PHONE
FROM GT_CONTACT_LVL1_DATA DR LEFT OUTER JOIN VW_GT_CONTACT_TEL DR1
ON DR1.LOCATIONID = DR.LOCATIONID
AND DR1.CONTACTID = DR.CONTACTID
AND DR.CASENO = DR1.CASENO
WHERE DR.CASENO IS NOT NULL -- CASENO IS NOT NULL AND A CORRESPONDING NULL CASENO EXISTS
AND (DR.LOCATIONID,DR.CONTACTID) IN
     (SELECT LOCATIONID,CONTACTID
      FROM GT_CONTACT_LVL1_DATA D
      WHERE CASENO IS NULL
        AND D.CONTACTID = DR.CONTACTID
       AND D.LOCATIONID = DR.LOCATIONID
UNION
SELECT DD.LOCATIONID,
       DD.CALL_LOCATIONID,
       DD.LOC_SEQ,
       DD.CONTACTID,
       DD.CALL_CONTACTID,
       DD.CALL_SEQ,
       DD.CASENO,
       DD.VERSION,
       DD.REP_SEQ,
       DD.LOC_REFNO,
DD1.PHONE
FROM GT_CONTACT_LVL1_DATA DD LEFT OUTER JOIN VW_GT_CONTACT_TEL DD1
ON DD1.LOCATIONID = DD.LOCATIONID
AND DD1.CONTACTID = DD.CONTACTID
AND DD.CASENO = DD1.CASENO
WHERE DD.CASENO IS NULL -- CASENO IS NULL AND A CORRESPONDING NOT NULL CASENO EXISTS
AND (DD.LOCATIONID,DD.CONTACTID)
IN (SELECT LOCATIONID,CONTACTID
    FROM GT_CONTACT_LVL1_DATA D
    WHERE CASENO IS NOT NULL AND D.CONTACTID = DD.CONTACTID
    AND D.LOCATIONID = DD.LOCATIONID
union
SELECT DR.LOCATIONID,
        DR.CALL_LOCATIONID,
        DR.LOC_SEQ,
        DR.CONTACTID,
        DR.CALL_CONTACTID,
        DR.CALL_SEQ,
        DR.CASENO,
        DR.VERSION,
        DR.REP_SEQ,
        DR.LOC_REFNO,
        DD.PHONE
FROM GT_CONTACT_LVL1_DATA DR LEFT OUTER JOIN VW_GT_CONTACT_TEL DD
ON DD.CASENO = DR.CASENO
AND DD.REP_SEQ = DR.REP_SEQ
AND DR.CASENO = DD.CASENO
WHERE DR.CASENO IS NOT NULL
AND (DR.LOCATIONID,DR.CONTACTID)
NOT IN (SELECT LOCATIONID,CONTACTID
        FROM GT_CONTACT_LVL1_DATA
        WHERE CASENO IS NULL
UNION
SELECT DD.LOCATIONID,
       DD.CALL_LOCATIONID,
       DD.LOC_SEQ,
       DD.CONTACTID,
       DD.CALL_CONTACTID,
       DD.CALL_SEQ,
       DD.CASENO,
       DD.VERSION,
       DD.REP_SEQ,
       DD.LOC_REFNO,
       DD1.PHONE
FROM GT_CONTACT_LVL1_DATA DD LEFT OUTER JOIN VW_GT_CONTACT_TEL DD1
ON DD1.LOCATIONID = DD.LOCATIONID
AND DD1.CONTACTID = DD.CONTACTID
AND DD.CASENO = DD1.CASENO
WHERE DD.CASENO IS NULL
AND (DD.LOCATIONID,DD.CONTACTID) NOT IN
(SELECT LOCATIONID,CONTACTID
FROM GT_CONTACT_LVL1_DATA
WHERE CASENO IS NOT NULL
Sybrand Bakker
Senior Oracle DBA

HTMLDB 1.5 SQL Optimization

Hi All
I'm using HTMLDB 1.5, and SQL optimization hints vanish from all regions when my app is migrated from development to production. e.g. /*+ hint INDEX */
Tested re-importing the app in the dev environ and have the same issue.
Is this a htmldb bug or am I doing something wrong?
Thanks
Kezie

Kezie - Actually that particular bug was fixed in 1.5.1. If you can apply the 1.5.1 patch, the application installation page will not strip out hints. For SQL*Plus import/install, you must connect as FLOWS_010500 (DBA can change password) or connect as any schema assigned to the workspace into which your application will be installed. The workspace ID and app ID must be identical to those from the source HTML DB instance for this to work.
Scott

Bug? HTMLDB changing formats when no_translate setting!

This question relates to version 1.6.1.00.02
I have my database,apache and DAD set to NLS_DATE_FORMAT='MM/DD/YYYY'
for the DAD, It is done this way...
dad calls this procedure for each connect (via "PlsqlBeforeProcedure" in dads.conf):
PROCEDURE set_dad_nls IS
BEGIN
DBMS_SESSION.SET_NLS('NLS_DATE_FORMAT','"MM/DD/YYYY"');
END;
It works and is verified if I call a procedure outside of htmldb via the URL method that just does
begin
htp.p(sysdate);
end;
it prints it in the MM/DD/YYYY format
however inside HTMLDB, the same print: htp.p(sysdate); in a pl/sql area prints in the DD-MON-YY format.
If I change my application attribute called:
"Application Language Derived From"
from "NO_NLS APPLICATION NOT TRANSLATED" to "USE_APPLICATION_PRIMARY_LAUNGAGUE"
Then I get the date inside HTMLDB returned in the MM/DD/YYYY format
However, the first setting is telling it to "not translate" yet evidently HTLMDB is translating.
What gives? Is this a bug or a misunderstanding.
I read this and still could not understand:
http://www.oracle.com/technology/products/database/htmldb/howtos/howto_handle_dates.html
In addition to the bug question (my primary question), my goal is for everything to default to MM/DD/YYYY. I have many apps, can I set MM/DD/YYYY in one place for all of HTMLDB apps (including PL/SQL areas)...or is some other method I am not following an option.

Meyer,
This is not a bug.
By default, modplsql pools database connections. Every page view in HTML DB uses one of these connections, does its stuff, and then the connection is returned to the pool.
HTML DB sets the NLS settings (language and territory) for every page view and submission. If it did not, then your page view would "inherit" the NLS settings from some other user's previous page view.
If your Application Language Derived From is set to "No NLS (Application not translated)", that means that HTML DB will do no processing to derive your application langauge and territory settings. But this doesn't remove the fact that you could still inherit some other user's NLS settings, so we must reset it to something. That "something" is the NLS language and territory of the database.
The language setting of HTML DB determines how the NLS_LANGUAGE and NLS_TERRITORY will be set for a particular page view. But for all page views in HTML DB, NLS_LANGUAGE and NLS_TERRITORY must be explicitly set to something.
For evidence of the previous bug in HTML DB where we did not properly reset these NLS settings, check out the first few comments at:
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:7913917986287
So you have at least four choices:
1) Change the database settings. Via SQL*Plus, you can issue "show parameters nls" to see everything you can set.
or
2) In HTML DB, set your application primary language to some language which has territory settings corresponding to NLS_DATE_FORMAT of MM/DD/YYYY.
or
3) Add an application level before header process which performs your DBMS_SESSION.SET_NLS procedure
or
4) Add an application level substitution string, let's say called DATE_FORMAT with a value of MM/DD/YYYY, then any place you display dates (in reports, as items), set the format mask to &DATE_FORMAT. (including the trailing period).
Hope this helps.
Joel

Get HTMLDB in different languages - how?

How can i get HTMLDB in german or other languages. After installation i have english screens.

If you want to use HTML DB in German or another language other than English, you'll have to change the language preference settings of your browser to that language. This only works though, if the HTML DB instance you're trying to access actually has the translated HTML DB applications installed. You'll find the installation scripts in your HTML DB installation folder in the subdirectory /builder/de (for German). Run the load_de.sql script to install the German translations. Before running the script, make sure your NLS_LANG settings are set so that German Umlaute or other special characters are supported (e.g. AMERICAN_AMERICA.AL32UTF8).

Error in load_de

Hi,
I have run load_de set the nls_lang to AMERICAN_AMERICA.AL32UTF8 as proposed. The first statement in load_de is:
ALTER SESSION SET CURRENT_SCHEMA=FLOWS_010404
with my actual flow schema. I have run the script with sys and get the following error:
ERROR at line 1:
ORA-20001: Package variable g_security_group_id must be set.
ORA-06512: at "FLOWS_010404.WWV_FLOW_API", line 57
ORA-06512: at "FLOWS_010404.WWV_FLOW_API", line 275
ORA-06512: at line 4
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production

Juergen,
The error you showed would happen if the 'ALTER SESSION SET CURRENT_SCHEMA=FLOWS_010404' had not been performed. Is FLOWS_010404 the correct schema, or are you doing an installation based on the 10g companion CD, which would install the FLOWS_010500 schema? In any case, the ALTER SESSION statement is not included in the load_de.sql script that we distribute; you must type it in yourself (perhaps you did).
Scott

Help Required With SQL Subquery Across DB Link - Takes Long Time

Hi,
Apologies if this is not the correct forum but I am implementing this through HTMLDB.
I am trying to run a SQL query over a DB link with a sub query on tables in my HTMLDB workspace.
The SQL query over the database link takes 1.23 seconds to run on it's own:
SELECT D.EMAIL_ADDRESS,
D.COL2,
D.COL3,
D.COL4,
D.COL5,
D.COL6,
T.COL1
FROM SCHEMA.TABLE1@DATABASELINK D,
SCHEMA.TABLE2@DATABASELINK T
WHERE D.TABLE_JOIN = T.TABLE_JOIN
AND T.COL1 = '1111111'
AND UPPER(D.COL2) IN ('XXXXXX','YYYYYY')
The SQL query based on HTMLDB workspace tables takes 0.01 seconds to run on it's own:
SELECT UPPER(A.EMAIL_ADDRESS)
FROM HTMLDBTABLE1 M, HTMLDBTABLE2 A
WHERE M.TABLE_JOIN = A.TABLE_JOIN
AND M.ID = 222
However when I try and run these together the results take 280 seconds to complete:
SELECT D.EMAIL_ADDRESS,
D.COL2,
D.COL3,
D.COL4,
D.COL5,
D.COL6,
T.COL1
FROM SCHEMA.TABLE1@DATABASELINK D,
SCHEMA.TABLE2@DATABASELINK T
WHERE D.TABLE_JOIN = T.TABLE_JOIN
AND T.COL1 = '1111111'
AND UPPER(D.COL2) IN ('XXXXXX','YYYYYY')
AND NOT EXISTS
(SELECT UPPER(A.EMAIL_ADDRESS)
FROM HTMLDBTABLE1 M, HTMLDBTABLE2 A
WHERE M.TABLE_JOIN = A.TABLE_JOIN
AND UPPER(A.EMAIL_ADDRESS) = UPPER(D.EMAIL_ADDRESS)
AND M.ID = 222)
Does anyone have any idea why this query is taking so long?
Please let me know if you require additional information.
Many thanks,
Richard.

I've updated my profile to show my email address, so go ahead and email me the strace output (compressed please). Maximum attachment size for emails to Oracle is 10MB (encoded), so split the strace output in 5MB chunks if necessary.
poll() is not normally used by the Oracle network layer for client-server connections. So this may be related to an OS network service, such as DNS or NIS. The strace should make this clear (to me anyway).
Edited by: herb on Aug 14, 2009 10:25 AM

Bug? using MAX() function on char(1) column returns something larger

details:
-- we have a complex nested query, where we are essentially returning the max() value into a variable
-- the max() function is being used on a char(1) column
-- where MAX() is part of an inner select, we have started getting
ORA-06502: PL/SQL: numeric or value error: character string buffer too small
errors.
SELECT MAX(X) INTO var FROM ... works in 9i and 10g
SELECT X INTO var FROM (SELECT MAX(X) X FROM ... worked in 9i, does not work in 10g!
-- We never had problems with the code until upgrading to 10g release 2.
-- the Solution is to cast the final value with TO_CHAR(). The cast MUST be done at the outer most point of the select:
SELECT TO_CHAR(X) INTO var FROM (SELECT MAX(X) X FROM ... works
SELECT X INTO var FROM (SELECT TO_CHAR(MAX(X)) X FROM ... causes an error!
The following script demonstrates the issue, and includes the solution:
* October 3, 2006
* Possible SQL bug introduced with Oracle 10G
* Natalie Gray DBA/Developer, Environment Canada
* Description:
* Have discovered a problem with using the MAX() function
* on columns of type char(1)
* only an issue when used in an inner select
* solution (see test 4)
CREATE TABLE SQL_BUG_TEST
X NUMBER,
Y NUMBER,
Z CHAR(1)
INSERT INTO SQL_BUG_TEST (X, Y, Z)
VALUES (1,1,'A');
INSERT INTO SQL_BUG_TEST (X, Y, Z)
VALUES (1,1,'B');
INSERT INTO SQL_BUG_TEST (X, Y, Z)
VALUES (1,2,'C');
INSERT INTO SQL_BUG_TEST (X, Y, Z)
VALUES (1,2,'D');
DECLARE
TYPE REC IS RECORD (
      x SQL_BUG_TEST.X%TYPE,
      y SQL_BUG_TEST.Y%TYPE,
      z SQL_BUG_TEST.Z%TYPE
v_rec REC;
BEGIN
      -- DISPLAY THE TABLE DATA
      BEGIN
             DBMS_OUTPUT.PUT_LINE('TABLE DATA:');
            DBMS_OUTPUT.PUT_LINE('');
             DBMS_OUTPUT.PUT_LINE('SELECT * FROM SQL_BUG_TEST ORDER BY X,Y,Z;');
             FOR crs IN (SELECT *
                                 FROM SQL_BUG_TEST
                           ORDER BY X,Y,Z) LOOP
                DBMS_OUTPUT.PUT_LINE(':'||crs.X||':'||crs.Y||':'||crs.Z);
            END LOOP;
      EXCEPTION WHEN OTHERS THEN
             DBMS_OUTPUT.PUT_LINE(SQLERRM);
      END;
      -- TEST 1
      -- returning result from MAX into a variable when the MAX is in the outer most select
      -- does not cause an error
      BEGIN
             DBMS_OUTPUT.PUT_LINE('*****************************************************');
             DBMS_OUTPUT.PUT_LINE('TEST 1');
            DBMS_OUTPUT.PUT_LINE('');
             DBMS_OUTPUT.PUT_LINE('SELECT X, Y, MAX(Z) Z');
            DBMS_OUTPUT.PUT_LINE('FROM SQL_BUG_TEST');
            DBMS_OUTPUT.PUT_LINE('GROUP BY X,Y');
            FOR crs IN (SELECT X, Y, MAX(Z) Z
                                 FROM SQL_BUG_TEST
                           GROUP BY X, Y
                           ORDER BY X,Y,Z) LOOP
                 DBMS_OUTPUT.PUT_LINE(':'||crs.X||':'||crs.Y||':'||crs.Z);
            END LOOP;
      EXCEPTION WHEN OTHERS THEN
           DBMS_OUTPUT.PUT_LINE(SQLERRM);
      END;
      -- TEST 2
      -- returning MAX() from an inner select to an outer select and then into a variable
      -- causes an error
      BEGIN
             DBMS_OUTPUT.PUT_LINE('*****************************************************');
             DBMS_OUTPUT.PUT_LINE('TEST 2');
            DBMS_OUTPUT.PUT_LINE('THIS DID NOT CAUSE AN ERROR WITH ORACLE 9i');
            DBMS_OUTPUT.PUT_LINE('');
             DBMS_OUTPUT.PUT_LINE('SELECT * INTO v_rec');
            DBMS_OUTPUT.PUT_LINE('FROM');
            DBMS_OUTPUT.PUT_LINE('(SELECT X, Y, MAX(Z) Z');
            DBMS_OUTPUT.PUT_LINE('FROM SQL_BUG_TEST');
            DBMS_OUTPUT.PUT_LINE('GROUP BY X,Y)');
            DBMS_OUTPUT.PUT_LINE('WHERE Y = 1');
            SELECT * INTO v_rec
            FROM
            (SELECT X, Y, MAX(Z) Z
             FROM SQL_BUG_TEST
             GROUP BY X, Y)
            WHERE Y = 1;
            DBMS_OUTPUT.PUT_LINE(':'||v_rec.X||':'||v_rec.Y||':'||v_rec.Z);
      EXCEPTION WHEN OTHERS THEN
           DBMS_OUTPUT.PUT_LINE(SQLERRM);
      END;
      -- TEST 3
      -- casting the result from MAX to char before returning to the outer select
      -- still causes an error
      BEGIN
             DBMS_OUTPUT.PUT_LINE('*****************************************************');
             DBMS_OUTPUT.PUT_LINE('TEST 3');
            DBMS_OUTPUT.PUT_LINE('');
             DBMS_OUTPUT.PUT_LINE('SELECT * INTO v_rec');
            DBMS_OUTPUT.PUT_LINE('FROM');
            DBMS_OUTPUT.PUT_LINE('(SELECT X, Y, to_char(MAX(Z)) Z');
            DBMS_OUTPUT.PUT_LINE('FROM SQL_BUG_TEST');
            DBMS_OUTPUT.PUT_LINE('GROUP BY X,Y)');
            DBMS_OUTPUT.PUT_LINE('WHERE Y = 1');
            SELECT * INTO v_rec
            FROM
            (SELECT X, Y, to_char(MAX(Z)) Z
             FROM SQL_BUG_TEST
             GROUP BY X, Y)
            WHERE Y = 1;
            DBMS_OUTPUT.PUT_LINE(':'||v_rec.X||':'||v_rec.Y||':'||v_rec.Z);
      EXCEPTION WHEN OTHERS THEN
           DBMS_OUTPUT.PUT_LINE(SQLERRM);
      END;
      -- TEST 4 - SOLUTION
      -- the return value of MAX must be cast with to_char at the point where it is assigned to
      -- variable (outer most select)
      BEGIN
             DBMS_OUTPUT.PUT_LINE('*****************************************************');
             DBMS_OUTPUT.PUT_LINE('TEST 4 SOLUTION');
            DBMS_OUTPUT.PUT_LINE('');
             DBMS_OUTPUT.PUT_LINE('SELECT X, Y, TO_CHAR(Z) Z INTO v_rec');
            DBMS_OUTPUT.PUT_LINE('FROM');
            DBMS_OUTPUT.PUT_LINE('(SELECT X, Y, MAX(Z) Z');
            DBMS_OUTPUT.PUT_LINE('FROM SQL_BUG_TEST');
            DBMS_OUTPUT.PUT_LINE('GROUP BY X,Y)');
            DBMS_OUTPUT.PUT_LINE('WHERE Y = 1');
            SELECT X, Y, TO_CHAR(Z) Z INTO v_rec
            FROM
            (SELECT X, Y, MAX(Z) Z
             FROM SQL_BUG_TEST
             GROUP BY X, Y)
            WHERE Y = 1;
            DBMS_OUTPUT.PUT_LINE(':'||v_rec.X||':'||v_rec.Y||':'||v_rec.Z);
      EXCEPTION WHEN OTHERS THEN
           DBMS_OUTPUT.PUT_LINE(SQLERRM);
      END;
END;

I certainly looks like a bug, but you should raise an iTAR on Metalink since Oracle does not monitor this forum.
I was able to replicate your results on my 10.2.0.1 database.
There is an easier workaround than yours. Try
ALTER TABLE sql_bug_test MODIFY (z VARCHAR2(1));That seems to eliminate the problem on my instance.
John

Creating large polygons in PL/SQL - memory leak?

I'm using PL/SQL to create a polygon with a very large number of vertices. I use SQL*Plus to execute the procedure. I check the memory usage in Windows Task Manager before and after the procedure. After the procedure finishes, 200K or more of memory does not get released. When I exit SQL*Plus, the memory is released. I wonder if I'm mis-understanding garbage collection in PL/SQL?
Background: This is an experiment to prove the feasibility of composing polygons in PL/SQL. I need a procedure that selects x and y vertex coordinates from a table where the x and y are stored as normal numbers. The procedure will then compose an SDO_GEOMETRY and insert it into a spatial table. The procedure may process many thousands of polygons in this way. My experiment is to show that PL/SQL can 1) be used to populate geometry with a large number of vertices, and 2) that performance is adequate for this job.
As a side note: I found that PL/SQL will generate an error when the ordinate array exceeds about 1,040,000 ordinates (500,000 2D vertices).
My real question though is this: What should I do in my procedure to release the memory? Once I figure this out, I will be composing and destroying the geometry object once for each iteration of a loop that generates the object.
Sample:
SET SERVEROUTPUT ON
DECLARE
geom MDSYS.SDO_GEOMETRY;
arrElemInfo MDSYS.SDO_ELEM_INFO_ARRAY;
arrOrd MDSYS.SDO_ORDINATE_ARRAY;
x integer := 0;
y integer := 0;
BEGIN
arrElemInfo := MDSYS.SDO_ELEM_INFO_ARRAY(1,3,1); -- Start offset 1, etype is polygon, Interpret ETYPE as Simple polygon whose vertices are connected by straight line segments
arrOrd := MDSYS.SDO_ORDINATE_ARRAY();
FOR i IN 1..500000 LOOP
x := 1;
y := i;
arrOrd.EXTEND(2);
arrOrd(arrOrd.COUNT-1) := x;
arrOrd(arrOrd.COUNT) := y;
END LOOP;
-- Close the polygon
arrOrd.EXTEND(2);
arrOrd(arrOrd.COUNT-1) := arrOrd(1);
arrOrd(arrOrd.COUNT) := arrOrd(2);
geom := mdsys.sdo_geometry(2003,NULL,NULL,arrElemInfo,arrOrd);
DBMS_OUTPUT.PUT_LINE(geom.sdo_ordinates.count);
END;
null

Hi Dale,
There have been a couple of PL/SQL bug fixes in 9i related to memory use with objects. It is possible you have run into one of those issues.
Also, I've noticed a one-time cost associated with certain functions that cause memory usage to jump once, then stabilize.
Also, the maximum size for a varray column in Oracle (and hence the max size for the sdo_ordinates and sdo_elem_info arrays) is 1048576.
hope this helps,
dan
null

HTMLDB 1.6 load_de.sql bug ?

Similar Messages

Maybe you are looking for