ORA-1405 처리 방법

제품 : PRECOMPILERS
작성날짜 : 1995-11-02
ORA-01405 는 ERROR 가 아니고 WARNING MESSAGE 이다. 따라서 프로그램 내에서
ERROR CHECK 하는 방법에 따라 PRE*COMPILER OPTION 을 상이하게 설정 ERROR를
처리할 수있다.
1. SQLCODE 로 ERROR CHECK 하는 경우
/* commission 이 null인 경우 */
EXEC SQL SELECT ENAME, SAL, COMM
INTO :emp_name, :salary, :commission
FROM EMP
WHERE EMPNO = :emp_number;
if (sqlca.sqlcode != 0 ) exit(0);
위 경우 sqlca.sqlcode 가 -1405 이므로 exit 하게된다. 따라서 값을
정상적으로 FETCH 를 하였으나 ERROR 로 처리되게 된다. 위의 프로그램을
변경하지않고 처리 할 수 있는방법은 dbms=v6 를 PRECOMPILER OPTION 에
추가해준다. dbms=v6 로 SETTING 할경우는 HOST 변수에 NULL 이 RETURN
되더라도 sqlca.sqlcode 는 0 이 된다.
2. NOT FOUND 로 CHECK 하는 경우
EXEC SQL WHENEVER NOT FOUND DO break;
EXEC SQL SELECT ENAME, SAL, COMM
INTO :emp_name, :salary, :commission
FROM EMP
WHERE EMPNO = :emp_number;
FOUND 인 경우 1403 이 RETURN 되므로 위의 SQL 문은 정상적으로 처리가 된다.

Pl see if MOS Doc 1162862.1 can help

Similar Messages

  • Select count(*) on sql statement returning zero when a matching row exists.

    Our account has an ANSI C application that checks for the existence a row on an Oracle table(s) by using the following SQL:
    int iCount = 0;
    EXEC SQL
    SELECT count(rownum) INTO :iCount
    FROM sys.all_tab_columns
    WHERE table_name IN
    (SELECT table_name FROM
    sys.all_synonyms
    WHERE upper(synonym_name) = upper(:szDestTable))
    AND upper(column_name) = upper(:szColumnName)
    AND owner = 'DBAUSER';
    The bind variables szDestTable and szColumnName are populated with values parsed from columns on another database table. This application is executed through out the day. Occasionally, the application will report a zero in the iCount when there should be a match. I have verified the szDestTable and szColumnName are populated with the correct values which would find a match and they are correct. To make matters even stranger, the application will parse the same input values and find a match (as it should). At some point during the day, and it can be at any time, the application will NOT find a match on the same file, same values. Every subsequent execution of this application will not find a match on the same values. Once the database is brought down and started up in the evening for its normal backups, the application will find a match again on the same values. This problem does not occur every day. I could be a week or a week and a half between incidents.
    I printed the contents of the sqlca.sqqlerrm.sqlerrmc field to a log file. The sqlca.sqlerrm.sqlerrmc field reported an ORA-1405 bind variable was null when the iCount was reporting a zero. When I compiled this application, I set the Proc*C flag to UNSAFE_NULLS=yes since there are other bind variable in the application that can be NULL and that is ok.
    The above SQL is compiled into the C application using the Proc*C compiler. It is compiled using the Oracle 11.2.0.2 libraries. The application is executed against an Oracle 11.2.0.2 database. The database and application are executed on an HP/Unix 11.31 platform.
    This problem did not start occurring until our account went from Oracle 10.2 to Oracle 11.2. Recently, I have changed the SQL to perform a “SELECT COUNT(rownum)” instead of the “SELECT COUNT(*)”. I compiled the application and executed the new application with the SELECT COUNT(rownum) against the same database where the same application with the SELECT COUNT(*) was failing to find a row that actually existed. The application with the SELECT COUNT(rownum) found the matching row as it should have. The new application has been executing in production for about 10 days now without any problems against ten various Oracle 11.2 databases.
    Why would SELECT COUNT(*) and SELECT COUNT(rownum) be any different?

    This forum is about C programming in general, and about using Studio C in particular.
    Your question is about Oracle database programming. You are more likely to find a helpful answer in a forum about database programming. Start here:
    https://forums.oracle.com/forums/category.jspa?categoryID=18

  • PRO*C VERSION MATRIX 및 VERSION 별 특성

    제품 : PRECOMPILERS
    작성날짜 : 1998-02-19
    PRO*C version matrix 및 version 별 지원 내용
    ===========================================
    [1] PRO*C 의 version 별 지원 내용
    RDBMS 의 version 과 PRO*C 의 version 별 지원내용은 다음과 같다.
    PRO*    Last    RDBMS    Languages
    Version Version Version
    ======================================================================
    1.3     1.3.20  <6.0.35      PRO*C
    1.4     1.4.15/6 6.x          "
    1.5     1.5.10   7.0.x        "
    1.6     1.6.7    7.1.x        "
    1.6     1.6.9    7.2.x        "
    2.0     2.0.6    7.1.x        "
    2.1     2.1.3    7.2.x        "
    2.2     2.2.?    7.3.x        "
    [2] 각 version 의 pro*c의 precompile option 추가 부분과 header file
    위치는 다음과 같다.
    (1) version 1.4
    Location: $ORACLE_HOME/proc/demo
    File: proc.mk
    Build from "prog.pc":  make -f proc.mk prog
    Where to add options:  edit PRO14FLAGS
    Header files in:       $ORACLE_HOME/proc/lib
    (2) version 1.5
    Location: $ORACLE_HOME/proc/demo
    File: proc.mk
    Build from "prog.pc":  make -f proc.mk prog
    Where to add options:  edit PROFLAGS
    Header files in:       $ORACLE_HOME/proc/lib
    (3) verion 1.6 , 1.7,1.8
    Location: $ORACLE_HOME/proc16/demo
    File: proc16.mk
    Build from "prog.pc":  make -f proc.mk prog
    Where to add options:  edit PCCFLAGS
    Header files in:       $ORACLE_HOME/sqllib/public
    (4) version 2.0, 2.1
    Location: $ORACLE_HOME/proc/demo
    File: proc.mk
    Build from "prog1.pc": make -f proc.mk EXE=prog OBJS="prog1.o prog2.o"
      and "prog2.pc"
    Where to add options:  add PROFLAGS
    Header files in:       $ORACLE_HOME/sqllib/public
    (5) version 2.2
    Location: $ORACLE_HOME/precomp/demo/proc
    File: proc.mk
    Build from "prog1.pc": make -f proc.mk build EXE=prog OBJS="prog1.o
    prog2.o"
      and "prog2.pc"
    Where to add options:  add PROCFLAGS
    Header files in:       $ORACLE_HOME/precomp/public
    [3]다음은 각 VERSION 별 지원 내용을 살펴 보기로 한다.
    (1) VERSION 1.4
    1. precompiler option 의 추가된 부분은 LINES=YES option지정시 outpute 에
    #line directives 생성 지원되어debugging 에 도움울 줄수 있게
    되었으며, dynamic method 사용시 HOLD_CURSOR=YES option을 사용하여
    cursor의 재사용을 방지할 수 있게 되었다. AREASIZE,REBIND option 이
    없어지고 MODE=ANSI14 option 을 지원 가능하게 되었다. 그러나 이 ANSI14
    option 을 사용시는 4byte inter 인 SQLCODE 를 반드시 declare 해야 한다.
    SQLCHECK=SEMANTICS/SYNTAX/NONE (Default는 SYNTAX) 가 사용되고, 더이상
    log를 db에 기록하지 않게 되었다.
    2  Datatype equivalencing 지원 한다.
        EXEC SQL VAR host_variable IS datatype ;
        EXEC SQL TYPE type is datatype REFERENCE ;
    3. Indicator 변수를 사용가능 ( :host INDICATOR :indicator ) 하게
    되었으며 또한 AT 절에 host 변수를 사용가능하게 되었다. 또host변수
    선언시 auto, extern, static, const, volatile 사용 가능하다.
    4. SQLCA 의 sqlerrd(5) 에 0 based parse offset을 저장하였으나, v2.x 의
    현재 version 에서는 사용되어지지 않고있다..
    5 procedure call 이 가능하게 되었다. (EXEC SQL WHENEVER ... DO
    procedure) .
      또한 EXEC SQL WHENEVER ... DO break; 문이 사용가능하다 .
    6. Precompiler 실행모듈이 각 언어마다 구분되어 pro*c 의 경우function의
    prototypes 생성
       가능하다.
    (2) Version 1.5
    ============
    이 version 은 ORACLE RDBMS 7.x 를 지원하는 pro*c version 으로 완벽한
    ANSI SQL을 지원한다. 또한 NLS 의 support 도 지원가능하다
    1. precompile option 의 변경사항으로는 DBMS=NATIVE/V6/V7 option
    지원하며 FIPS=YES로 설정시 ANSI extension 지원한다.
    2.  data type 변경사항으로는 fixed length datatypes 지원하는 CHARF,
    CHARZ가 사용가능하며 LONG VARCHAR,LONG VARRAW datatypes 지원가능하다.
    또한 MLSLABEL 데이타 타입사용 가능하게 되었는데 이는 variable_lengrh
    의 binary OS label 을 저장할때 사용가능하다.
    3. indicators 없는 host 변수가 null을 fetch하면, DBMS=V6으로
    설정하지 않은 경우는
       ORA-1405를 return 함. PL/SQL table을 파라미터로 하는 stored
    procedures 호출 가능.
    4. 이전 version 에서 space 만 가능했던 (bug) input character string
    데이타 타입이
       terminator를 포함하는 경우도 이를 데이타로 인식 가능
    (3) version 1.6
    ==================
    1.변경된 precompile option 으로 AUTO_CONNECT=YES option
    지원하는데
    이를 지정시는 처음 sql 문 수행시 OPS$<username>으로 자동 connect 된다. 
    또한 CONFIG=<file> option 지원으로 user 의 configuration 의 name 과
    위치를 지정할수 있다. 또한 시스템 config file 사용 가능한데 이의 위치는
    UNIX = $ORACLE_HOME/proc16/pccc.cfg, VMS=ora_pcc:pccc.cfg. 이다.
    2. SQLSTATE 변수는 SQL문 실행 이후에 값이 설정된다. MODE=ANSI로 설정이
    되어 있고, declare section안에 선언되어 있는 경우에만 이값이 설정된다. 
    만일 그렇지 않으면 이 값은 무시된다.만약 SQLCODE가 안에 선언되어 있다면,
    이 두 변수 모두 값이 설정된다.
     만약 SQLCODE가 밖에 선언되어 있다면 SQLSTATE만 설정된다. SQLSTATE는
    coding scheme를 표준화하는데 사용된다. SQLCODE는 declare section
    내부에 선언되거나, SQLSTATE, SQLCA가 사용되지 않는 경우에 사용하게 된다.
    이 점은 1.5 버젼에서 SQLCA를 declare section 밖에 선언하여, SQLCA와
    같이 사용되었던 것과는 차이가 있다.
    3. SQLGLS 함수 지원하는데 이는 마지막 문장을 parse 한 후, 문장의 길이
    및 타입을 return한다. 
    eg) int sqlgls(char *sqlstm ,size_t
    *stmlen,size_t *sqlfc)
    4. select 문에서 stored function 을 call 할수 있다.
    5. 단 SQLCHECK=FULL/SEMANTICS 가 아닌 경우에 FROM 절에서 subquery 가
    가능하다. 이는 PL/SQL 의 semantic check 인 경우는 v7.3 에서 가능하다 .
    (4) Version 1.8
    ================ 
    1. INDICATOR VARIABLE을 사용하지 않고도 NULL FETCH시 ORA-1405 에러가
    발생하지 않도록 UNSAFE_NULL=YES 옵션이 추가됨. UNSAFE_NULL=YES로
    설정하면 ORA-1405 를 방지하기 위해서 DBMS=V6 으로 세팅할 필요없이
    DBMS=V7 으로 할 수 있음. 단, UNSAFE_NULL=YES를 사용하기 위해서는
    MODE=ORACLE 로 설정해야 함.
    2. PACKAGE ARGUMENT로 PL/SQL CURSOR(WEAKLY TYPED)를 사용할 수 있는데
    예를 들면 TYPE GeneralCurTyp IS REF CURSOR;
    3. FROM 절에서 SUBQUERY를 사용할 수 있고 SQLCHECK=SEMANTICS 또는
    SQLCHECK=FULL 옵션을 사용할 수 있음.
    4. PL/SQL 블럭에서 PL/SQL TABLE과 이와 관련된 다음 함수를 지원.
     a_table(index).EXISTS, a_table.COUNT, a_table.FIRST, a_table.LAST,
    a_table.PRIOR(index), a_table.NEXT(index),
    a_table.DELETE(start_index,_index), a_table.DELETE.
    5. WHERE CURRENT OF CURSOR를 이용해서 MULTI-TABLE VIEW를 통해
    KEY-PRESERVED TABLE을 UPDATE 가능.
    (5) version 2.0
    ==================
    RDBMS version 7.3에서 부터 makefile 은
    ins_precomp.mk,env_precomp.mk, proc.mk의 3 개로 나뉘었다.
    Ins_precomp.mk 는 기존의 proc.mk 처럼 precompiler executables 를 build
    하기 위한 routine 이고 env_precomp.mk 는 모든 environment 의 변수와
    libraray 를 포함한다.
    이 file 은 Ins_precomp.mk 와 proc.mk 에 포함되어 사용되어진다.
    1. V1.6과 같이 AUTO_CONNECT, CONFIG 옵션 지원. SYSTEM CONFIGURATION
    FILE은 UNIX에서는 $ORACLE_HOME/proc/pmscfg.h 이고 VMS에서는
    ora_proc20:pmscfg.cfg
    2. V1.6과 같이 SQLSTATE 변수와 SQLGLS 함수가 제공된다.
    3. C PREPROCESSOR가 포함되어서 #define이 EMBEDDED SQL과 함께 이용될 수
    있고 #include 로 PRO*C 헤더화일을 INCLUDE 가능.
    4. 구조체를 HOST 변수로 사용 가능. 이것은 SELECT INTO, FETCH INTO 
    또는 INSERT시 VALUES 절에 사용될 수 있으나 PL/SQL PROCEDURE에 PL/SQL
    RECORD ARGUMENT로 사용할 수는 없음. 구조체 내에 또다른 구조체를 포함할
    수는 없지만 ARRAY는 포함할 수 있음.
    5. HOST 변수를 BEGIN/END DECLARE SECTION 안에 넣을 필요가 없음.
    6. V1.6에서 처럼 SELECT LIST에 STORED FUNCTION의 사용이 가능.
    7. SQLCHECK=FULL/SEMANTOCS를 사용하지 않는 경우 FROM 절에 SUBQUERY를
    쓸 수 있음.
    8. CHARACTER 변수의 BIND TYPE은 MODE 옵션이 아니라 DBMS 옵션에 따라서
    결정됨. DBMS=V6/V6_CHAR 인 경우, CHARACTER는 TYPE 1, DBMS=V7(또는
    NATIVE이고 ORACLE7에 접속할 때) 에서는 TYPE 97.
    9. DBMS=V6_CHAR 는 CHARACTER 변수가 가변 길이 문자열로 다루어질 수
    있도록 함.
    10. SQLVCP 함수는 VARCHAR ARR 변수를 지정한 길이로 만들어 주므로
    VARCHAR를 동적으로 할당할 때 COMPILER가 BYTE ALIGNMENT를 가능하게 함.
    11. PRO*C의 PARSE LEVEL을 설정하는 PARSE 옵션.
    a) NONE - PRO*C V1과 같음(HOST 변수를 DECLARE SECTION에 넣어야 함.
    #define 인식 안함 등)
    b) PARTIAL - HOST 변수를 DECLARE SECTION에 넣어야 함
    c) FULL - PRO*C V2의 기능 모두 지원
    12. EXEC SQL WHENEVER ... DO 함수명(args,...); 와 같이 함수호출시UMENT를
    주고 받을 수 있음.
    13. #ifdef/#ifndef 와 EXEC ORACLE IFDEF/IFNDEF 에서 사용하기 위한
    DEFINE 옵션 지원.
    (6) version 2.1
    ================
    1. PRO*C V1.7에서와 같이 char와 IMPLICIT VARCHAR (VARCHAR=YES 옵션과
    함께 적절한 C 구조체로 선언된 변수) HOST 변수에서 MULTI-BYTE NLS
    CHARACTER 데이타와 MULTI-BYTE 문자열을 지원.
     NLS_CHAR=var1,var2,... 옵션으로 MULTI-BYTE HOST 변수를 지정함.
    MULTI-BYTE 리터럴은 다음과 같이 사용된다.
     EXEC SQL SELECT ... WHERE ENAME = N*이경구*;
     단, 이것은 SQLLIB RUNTIME LIBRARY를 통해서 지원되기 때문에 MULTI-BYTE
    NLS 문자열은 DYNAMIC SQL에서 사용될 수 없음. NCHAR 데이타타입은 DDL 과
    함께 사용될 수 없음.
    2. PRO*C V1.7과 같이 NLS_LOCAL 옵션 지원
    3. DEF_SQLCODE=YES 로 설정하면 PRO*C는 다음 문장을 생성한다.
     #define SQLCODE sqlca.sqlcode
     SQLCA는 반드시 INCLUDE 되어야 하며 SQLCODE 변수는 선언되어서는 안됨.
    4. PRO*C V1.7 과 같이 CURSOR VARIABLE 지원.
    5. VARCHAR=YES 로 설정하면 특정한 구조체를 VARCHAR로 인식할 수 있다. 
    구조체의 형태를 보면
     struct
     short len;
     char arr[n];
     } host_var;
    6. CODE=CPP 로 설정하면 SQLLIB 함수 원형(PROTOTYPE)은 다음과 같이
    extern "C" 형식으로 생성됨.
     extern "C" {
     void sqlora( unsigned long *, void *);
     그리고 "//" 와 같은 COMMENT 처리명령을 인식함. 단, CODE=CPP인 경우
    PARSE 는 자동적으로 PARTIAL로 설정됨.
     CPP_SUFFIX 옵션은 PRECOMPILE된 화일의 확장자를 지정.
    SYS_INCLUDE=(dir1,dir2,...) 옵션은 C 헤더 화일과 다른 위치에 있는 C++
    헤더 화일이 있는 디렉토리를 지정. 이 옵션은 PARSE 옵션이 NONE이 아닌
    경우에만 필요하다. HEADER 화일을 찾는 위치는 SYS_INCLUDE, 현재 디렉토리,
    표준 SYSTEM 디렉토리(UNIX에서 PRO*C 헤더 화일의 위치는
    $ORACLE_HOME/sqllib/public), 그리고 INCLUDE 옵션에 지정된 디렉토리이다.

    제품 : PRECOMPILERS
    작성날짜 : 1998-02-19
    PRO*C version matrix 및 version 별 지원 내용
    ===========================================
    [1] PRO*C 의 version 별 지원 내용
    RDBMS 의 version 과 PRO*C 의 version 별 지원내용은 다음과 같다.
    PRO*    Last    RDBMS    Languages
    Version Version Version
    ======================================================================
    1.3     1.3.20  <6.0.35      PRO*C
    1.4     1.4.15/6 6.x          "
    1.5     1.5.10   7.0.x        "
    1.6     1.6.7    7.1.x        "
    1.6     1.6.9    7.2.x        "
    2.0     2.0.6    7.1.x        "
    2.1     2.1.3    7.2.x        "
    2.2     2.2.?    7.3.x        "
    [2] 각 version 의 pro*c의 precompile option 추가 부분과 header file
    위치는 다음과 같다.
    (1) version 1.4
    Location: $ORACLE_HOME/proc/demo
    File: proc.mk
    Build from "prog.pc":  make -f proc.mk prog
    Where to add options:  edit PRO14FLAGS
    Header files in:       $ORACLE_HOME/proc/lib
    (2) version 1.5
    Location: $ORACLE_HOME/proc/demo
    File: proc.mk
    Build from "prog.pc":  make -f proc.mk prog
    Where to add options:  edit PROFLAGS
    Header files in:       $ORACLE_HOME/proc/lib
    (3) verion 1.6 , 1.7,1.8
    Location: $ORACLE_HOME/proc16/demo
    File: proc16.mk
    Build from "prog.pc":  make -f proc.mk prog
    Where to add options:  edit PCCFLAGS
    Header files in:       $ORACLE_HOME/sqllib/public
    (4) version 2.0, 2.1
    Location: $ORACLE_HOME/proc/demo
    File: proc.mk
    Build from "prog1.pc": make -f proc.mk EXE=prog OBJS="prog1.o prog2.o"
      and "prog2.pc"
    Where to add options:  add PROFLAGS
    Header files in:       $ORACLE_HOME/sqllib/public
    (5) version 2.2
    Location: $ORACLE_HOME/precomp/demo/proc
    File: proc.mk
    Build from "prog1.pc": make -f proc.mk build EXE=prog OBJS="prog1.o
    prog2.o"
      and "prog2.pc"
    Where to add options:  add PROCFLAGS
    Header files in:       $ORACLE_HOME/precomp/public
    [3]다음은 각 VERSION 별 지원 내용을 살펴 보기로 한다.
    (1) VERSION 1.4
    1. precompiler option 의 추가된 부분은 LINES=YES option지정시 outpute 에
    #line directives 생성 지원되어debugging 에 도움울 줄수 있게
    되었으며, dynamic method 사용시 HOLD_CURSOR=YES option을 사용하여
    cursor의 재사용을 방지할 수 있게 되었다. AREASIZE,REBIND option 이
    없어지고 MODE=ANSI14 option 을 지원 가능하게 되었다. 그러나 이 ANSI14
    option 을 사용시는 4byte inter 인 SQLCODE 를 반드시 declare 해야 한다.
    SQLCHECK=SEMANTICS/SYNTAX/NONE (Default는 SYNTAX) 가 사용되고, 더이상
    log를 db에 기록하지 않게 되었다.
    2  Datatype equivalencing 지원 한다.
        EXEC SQL VAR host_variable IS datatype ;
        EXEC SQL TYPE type is datatype REFERENCE ;
    3. Indicator 변수를 사용가능 ( :host INDICATOR :indicator ) 하게
    되었으며 또한 AT 절에 host 변수를 사용가능하게 되었다. 또host변수
    선언시 auto, extern, static, const, volatile 사용 가능하다.
    4. SQLCA 의 sqlerrd(5) 에 0 based parse offset을 저장하였으나, v2.x 의
    현재 version 에서는 사용되어지지 않고있다..
    5 procedure call 이 가능하게 되었다. (EXEC SQL WHENEVER ... DO
    procedure) .
      또한 EXEC SQL WHENEVER ... DO break; 문이 사용가능하다 .
    6. Precompiler 실행모듈이 각 언어마다 구분되어 pro*c 의 경우function의
    prototypes 생성
       가능하다.
    (2) Version 1.5
    ============
    이 version 은 ORACLE RDBMS 7.x 를 지원하는 pro*c version 으로 완벽한
    ANSI SQL을 지원한다. 또한 NLS 의 support 도 지원가능하다
    1. precompile option 의 변경사항으로는 DBMS=NATIVE/V6/V7 option
    지원하며 FIPS=YES로 설정시 ANSI extension 지원한다.
    2.  data type 변경사항으로는 fixed length datatypes 지원하는 CHARF,
    CHARZ가 사용가능하며 LONG VARCHAR,LONG VARRAW datatypes 지원가능하다.
    또한 MLSLABEL 데이타 타입사용 가능하게 되었는데 이는 variable_lengrh
    의 binary OS label 을 저장할때 사용가능하다.
    3. indicators 없는 host 변수가 null을 fetch하면, DBMS=V6으로
    설정하지 않은 경우는
       ORA-1405를 return 함. PL/SQL table을 파라미터로 하는 stored
    procedures 호출 가능.
    4. 이전 version 에서 space 만 가능했던 (bug) input character string
    데이타 타입이
       terminator를 포함하는 경우도 이를 데이타로 인식 가능
    (3) version 1.6
    ==================
    1.변경된 precompile option 으로 AUTO_CONNECT=YES option
    지원하는데
    이를 지정시는 처음 sql 문 수행시 OPS$<username>으로 자동 connect 된다. 
    또한 CONFIG=<file> option 지원으로 user 의 configuration 의 name 과
    위치를 지정할수 있다. 또한 시스템 config file 사용 가능한데 이의 위치는
    UNIX = $ORACLE_HOME/proc16/pccc.cfg, VMS=ora_pcc:pccc.cfg. 이다.
    2. SQLSTATE 변수는 SQL문 실행 이후에 값이 설정된다. MODE=ANSI로 설정이
    되어 있고, declare section안에 선언되어 있는 경우에만 이값이 설정된다. 
    만일 그렇지 않으면 이 값은 무시된다.만약 SQLCODE가 안에 선언되어 있다면,
    이 두 변수 모두 값이 설정된다.
     만약 SQLCODE가 밖에 선언되어 있다면 SQLSTATE만 설정된다. SQLSTATE는
    coding scheme를 표준화하는데 사용된다. SQLCODE는 declare section
    내부에 선언되거나, SQLSTATE, SQLCA가 사용되지 않는 경우에 사용하게 된다.
    이 점은 1.5 버젼에서 SQLCA를 declare section 밖에 선언하여, SQLCA와
    같이 사용되었던 것과는 차이가 있다.
    3. SQLGLS 함수 지원하는데 이는 마지막 문장을 parse 한 후, 문장의 길이
    및 타입을 return한다. 
    eg) int sqlgls(char *sqlstm ,size_t
    *stmlen,size_t *sqlfc)
    4. select 문에서 stored function 을 call 할수 있다.
    5. 단 SQLCHECK=FULL/SEMANTICS 가 아닌 경우에 FROM 절에서 subquery 가
    가능하다. 이는 PL/SQL 의 semantic check 인 경우는 v7.3 에서 가능하다 .
    (4) Version 1.8
    ================ 
    1. INDICATOR VARIABLE을 사용하지 않고도 NULL FETCH시 ORA-1405 에러가
    발생하지 않도록 UNSAFE_NULL=YES 옵션이 추가됨. UNSAFE_NULL=YES로
    설정하면 ORA-1405 를 방지하기 위해서 DBMS=V6 으로 세팅할 필요없이
    DBMS=V7 으로 할 수 있음. 단, UNSAFE_NULL=YES를 사용하기 위해서는
    MODE=ORACLE 로 설정해야 함.
    2. PACKAGE ARGUMENT로 PL/SQL CURSOR(WEAKLY TYPED)를 사용할 수 있는데
    예를 들면 TYPE GeneralCurTyp IS REF CURSOR;
    3. FROM 절에서 SUBQUERY를 사용할 수 있고 SQLCHECK=SEMANTICS 또는
    SQLCHECK=FULL 옵션을 사용할 수 있음.
    4. PL/SQL 블럭에서 PL/SQL TABLE과 이와 관련된 다음 함수를 지원.
     a_table(index).EXISTS, a_table.COUNT, a_table.FIRST, a_table.LAST,
    a_table.PRIOR(index), a_table.NEXT(index),
    a_table.DELETE(start_index,_index), a_table.DELETE.
    5. WHERE CURRENT OF CURSOR를 이용해서 MULTI-TABLE VIEW를 통해
    KEY-PRESERVED TABLE을 UPDATE 가능.
    (5) version 2.0
    ==================
    RDBMS version 7.3에서 부터 makefile 은
    ins_precomp.mk,env_precomp.mk, proc.mk의 3 개로 나뉘었다.
    Ins_precomp.mk 는 기존의 proc.mk 처럼 precompiler executables 를 build
    하기 위한 routine 이고 env_precomp.mk 는 모든 environment 의 변수와
    libraray 를 포함한다.
    이 file 은 Ins_precomp.mk 와 proc.mk 에 포함되어 사용되어진다.
    1. V1.6과 같이 AUTO_CONNECT, CONFIG 옵션 지원. SYSTEM CONFIGURATION
    FILE은 UNIX에서는 $ORACLE_HOME/proc/pmscfg.h 이고 VMS에서는
    ora_proc20:pmscfg.cfg
    2. V1.6과 같이 SQLSTATE 변수와 SQLGLS 함수가 제공된다.
    3. C PREPROCESSOR가 포함되어서 #define이 EMBEDDED SQL과 함께 이용될 수
    있고 #include 로 PRO*C 헤더화일을 INCLUDE 가능.
    4. 구조체를 HOST 변수로 사용 가능. 이것은 SELECT INTO, FETCH INTO 
    또는 INSERT시 VALUES 절에 사용될 수 있으나 PL/SQL PROCEDURE에 PL/SQL
    RECORD ARGUMENT로 사용할 수는 없음. 구조체 내에 또다른 구조체를 포함할
    수는 없지만 ARRAY는 포함할 수 있음.
    5. HOST 변수를 BEGIN/END DECLARE SECTION 안에 넣을 필요가 없음.
    6. V1.6에서 처럼 SELECT LIST에 STORED FUNCTION의 사용이 가능.
    7. SQLCHECK=FULL/SEMANTOCS를 사용하지 않는 경우 FROM 절에 SUBQUERY를
    쓸 수 있음.
    8. CHARACTER 변수의 BIND TYPE은 MODE 옵션이 아니라 DBMS 옵션에 따라서
    결정됨. DBMS=V6/V6_CHAR 인 경우, CHARACTER는 TYPE 1, DBMS=V7(또는
    NATIVE이고 ORACLE7에 접속할 때) 에서는 TYPE 97.
    9. DBMS=V6_CHAR 는 CHARACTER 변수가 가변 길이 문자열로 다루어질 수
    있도록 함.
    10. SQLVCP 함수는 VARCHAR ARR 변수를 지정한 길이로 만들어 주므로
    VARCHAR를 동적으로 할당할 때 COMPILER가 BYTE ALIGNMENT를 가능하게 함.
    11. PRO*C의 PARSE LEVEL을 설정하는 PARSE 옵션.
    a) NONE - PRO*C V1과 같음(HOST 변수를 DECLARE SECTION에 넣어야 함.
    #define 인식 안함 등)
    b) PARTIAL - HOST 변수를 DECLARE SECTION에 넣어야 함
    c) FULL - PRO*C V2의 기능 모두 지원
    12. EXEC SQL WHENEVER ... DO 함수명(args,...); 와 같이 함수호출시UMENT를
    주고 받을 수 있음.
    13. #ifdef/#ifndef 와 EXEC ORACLE IFDEF/IFNDEF 에서 사용하기 위한
    DEFINE 옵션 지원.
    (6) version 2.1
    ================
    1. PRO*C V1.7에서와 같이 char와 IMPLICIT VARCHAR (VARCHAR=YES 옵션과
    함께 적절한 C 구조체로 선언된 변수) HOST 변수에서 MULTI-BYTE NLS
    CHARACTER 데이타와 MULTI-BYTE 문자열을 지원.
     NLS_CHAR=var1,var2,... 옵션으로 MULTI-BYTE HOST 변수를 지정함.
    MULTI-BYTE 리터럴은 다음과 같이 사용된다.
     EXEC SQL SELECT ... WHERE ENAME = N*이경구*;
     단, 이것은 SQLLIB RUNTIME LIBRARY를 통해서 지원되기 때문에 MULTI-BYTE
    NLS 문자열은 DYNAMIC SQL에서 사용될 수 없음. NCHAR 데이타타입은 DDL 과
    함께 사용될 수 없음.
    2. PRO*C V1.7과 같이 NLS_LOCAL 옵션 지원
    3. DEF_SQLCODE=YES 로 설정하면 PRO*C는 다음 문장을 생성한다.
     #define SQLCODE sqlca.sqlcode
     SQLCA는 반드시 INCLUDE 되어야 하며 SQLCODE 변수는 선언되어서는 안됨.
    4. PRO*C V1.7 과 같이 CURSOR VARIABLE 지원.
    5. VARCHAR=YES 로 설정하면 특정한 구조체를 VARCHAR로 인식할 수 있다. 
    구조체의 형태를 보면
     struct
     short len;
     char arr[n];
     } host_var;
    6. CODE=CPP 로 설정하면 SQLLIB 함수 원형(PROTOTYPE)은 다음과 같이
    extern "C" 형식으로 생성됨.
     extern "C" {
     void sqlora( unsigned long *, void *);
     그리고 "//" 와 같은 COMMENT 처리명령을 인식함. 단, CODE=CPP인 경우
    PARSE 는 자동적으로 PARTIAL로 설정됨.
     CPP_SUFFIX 옵션은 PRECOMPILE된 화일의 확장자를 지정.
    SYS_INCLUDE=(dir1,dir2,...) 옵션은 C 헤더 화일과 다른 위치에 있는 C++
    헤더 화일이 있는 디렉토리를 지정. 이 옵션은 PARSE 옵션이 NONE이 아닌
    경우에만 필요하다. HEADER 화일을 찾는 위치는 SYS_INCLUDE, 현재 디렉토리,
    표준 SYSTEM 디렉토리(UNIX에서 PRO*C 헤더 화일의 위치는
    $ORACLE_HOME/sqllib/public), 그리고 INCLUDE 옵션에 지정된 디렉토리이다.

  • ORA-08103: object no longer exists during APEX 2.2 to 3.0 upgrade

    I am trying to upgrade an APEX 2.2 installation on 10.2.0.2 Enterprise Edition on SLES-10 with 400MB shared_pool and 1 GB sga_target. During the upgrade, the session crashes due to ORA-00600: internal error code, arguments: [ktspgfb-1]. I cannot drop the FLOWS_030000 user and 523 corrupt blocks in sys7.dbf including objects source$, argument$ and obj$. So far, I have restored the database and corrupted it 3 times. Each time, I redownloaded apex.zip from technet.oracle.com.
    Here are the errors:
    ...PAGE 1300: Application Comparison
    ...PAGE 1301: Application Comparison Counts
    ...PAGE 1400: Report Layouts
    ...PAGE 1401: Create Report Layout
    ...PAGE 1402: Create Report Layout
    ...PAGE 1405: Edit Report Layout
    ...PAGE 1406: Create Report Query
    ...PAGE 1500: Application Builder
    ...PAGE 1550: User Interface Defaults
    ...PAGE 1552: UI Defaults - Column Defaults LOV
    ...PAGE 1553: UI Defaults - Column Defaults
    ...PAGE 1555: UI Defaults - Table Defaults
    begin
    ERROR at line 1:
    ORA-08103: object no longer exists
    ORA-06512: at "FLOWS_030000.WWV_FLOW_API", line 7733
    ORA-06512: at line 18
    ERROR:
    ORA-00603: ORACLE server session terminated by fatal error
    ERROR:
    ORA-03114: not connected to ORACLE
    SP2-0359: memory exhausted
    Mon Apr 30 11:31:46 2007
    Incremental checkpoint up to RBA [0x175.153ac.0], current log tail at RBA [0x175.2e77b.0]
    Mon Apr 30 11:32:05 2007
    Beginning log switch checkpoint up to RBA [0x176.2.10], SCN: 8173962186001
    Thread 1 advanced to log sequence 374
    Current log# 1 seq# 374 mem# 0: /lv01/oracle/dev10data/log01.dbf
    Mon Apr 30 11:34:24 2007
    Errors in file /lv01/oracle/dev10db/10.2.0/admin/dev10_plato/udump/dev10_ora_11590.trc:
    ORA-00600: internal error code, arguments: [ktspgfb-1], [], [], [], [], [], [], []
    Mon Apr 30 11:34:49 2007
    Errors in file /lv01/oracle/dev10db/10.2.0/admin/dev10_plato/udump/dev10_ora_11590.trc:
    ORA-00603: ORACLE server session terminated by fatal error
    ORA-00600: internal error code, arguments: [ktspgfb-1], [], [], [], [], [], [], []
    Mon Apr 30 11:35:02 2007
    Errors in file /lv01/oracle/dev10db/10.2.0/admin/dev10_plato/bdump/dev10_pmon_7541.trc:
    ORA-00600: internal error code, arguments: [ktspgfb-1], [], [], [], [], [], [], []
    Mon Apr 30 11:35:15 2007
    Errors in file /lv01/oracle/dev10db/10.2.0/admin/dev10_plato/bdump/dev10_pmon_7541.trc:
    ORA-00600: internal error code, arguments: [ktspgfb-1], [], [], [], [], [], [], []
    Mon Apr 30 11:37:18 2007
    Completed checkpoint up to RBA [0x176.2.10], SCN: 8173962186001
    Mon Apr 30 11:37:43 2007
    Errors in file /lv01/oracle/dev10db/10.2.0/admin/dev10_plato/bdump/dev10_p000_12471.trc:
    ORA-00600: internal error code, arguments: [ktspgfb-1], [], [], [], [], [], [], []
    Mon Apr 30 11:37:54 2007
    SMON: Parallel transaction recovery slave got internal error
    SMON: Downgrading transaction recovery to serial
    I now have 523 corrupt blocks in sys7.dbf:
    DBVERIFY: Release 10.2.0.2.0 - Production on Mon Apr 30 11:50:21 2007
    Copyright (c) 1982, 2005, Oracle. All rights reserved.
    DBVERIFY - Verification starting : FILE = /lv01/oracle/dev10data/sys7.dbf
    Page 188161 is marked corrupt
    Corrupt block relative dba: 0x01c2df01 (file 7, block 188161)
    Completely zero block found during dbv:
    Page 188162 is marked corrupt
    Corrupt block relative dba: 0x01c2df02 (file 7, block 188162)
    Completely zero block found during dbv:
    Page 188163 is marked corrupt
    Corrupt block relative dba: 0x01c2df03 (file 7, block 188163)
    Completely zero block found during dbv:
    Page 188164 is marked corrupt
    Corrupt block relative dba: 0x01c2df04 (file 7, block 188164)
    Completely zero block found during dbv:
    Any ideas why this is happening? I see a number of current bugs for ORA-00600: ktspgfb-1, but most knowledge base articles refer to 9.0.1 or 9.2.

    After upgrading to 10.2.0.3 and doubling the shared_pool_size and sga_target, I was able to upgrade to APEX 3.0 without errors.

  • Bind Variable ORA-01006 ??

    How do i set a Bind Variable ?? Because when i excute this i get an error like this appears :
    java.sql.SQLException: ORA-01006: bind variable does not exist
    at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
    at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
    at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
    at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
    at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:822)
    at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1446)
    at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1371)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1900)
    at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:363)
    at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:314)
    at be.brail.data.photo.Photodataaccess.insertphoto(Photodataaccess.java:93)
    at be.brail.data.photo.Photoaction.perform(Photoaction.java:144)
    at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1786)
    at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1585)
    at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
    at com.sssw.srv.resources.AgWarResource.doServletDispatch(AgWarResource.java:936)
    at com.sssw.srv.resources.AgWarResource.service(AgWarResource.java:712)
    at com.sssw.srv.resources.AgWarURLResource.perform(AgWarURLResource.java:114)
    at com.sssw.srv.http.httpd.perform(httpd.java:4568)
    at com.sssw.srv.http.Client.processRequest(Client.java)
    at com.sssw.srv.http.Client.loop(Client.java)
    at com.sssw.srv.http.Client.runConnection(Client.java)
    at com.sssw.srv.http.Client.run(Client.java)
    at java.lang.Thread.run(Unknown Source)
    This is the code :
    Class.forName("oracle.jdbc.driver.OracleDriver");
                   Connection con = DriverManager.getConnection("jdbc:oracle:thin:D156_1/karma@DEVBLOCKDB01:1521:WW3D");
                   System.out.println("Connectie DataBase -- OK!!");
                   //PrepareStatement
                   PreparedStatement ps=con.prepareStatement("INSERT INTO S156_PHOTO VALUES('?','?','?','?','?','?',EMPTY_BLOB())");
                   ps.setString(1,personid);
                   ps.setString(2,begindate);
                   ps.setString(3,enddate);
                   ps.setString(4,"");
                   ps.setString(5,"");
                   ps.setString(6,"");
                   System.out.println("PrepareStatements -- OK!!");
                   ps.executeQuery();
                   System.out.println("PrepareStatements Execute -- OK!!");
                   InputStream fileStream = photo.getInputStream();
                   byte by[] = new byte[fileStream.available()];
                   fileStream.read(by);
                   ps=con.prepareStatement("select PHOTO from S156_PHOTO for update of PHOTO");
                   ResultSet rs=ps.executeQuery();
                   Blob blob = null;
                   if(rs.next())
                        blob=rs.getBlob(1);
                   BLOB sblob = foto.File2Blob((oracle.sql.BLOB)blob);
                   OutputStream blobOutputStream = ((oracle.sql.BLOB)blob).getBinaryOutputStream();
                   // Buffer to hold chunks of data to being written to the Blob.
                   // In Oracle8.1.5 JDBC2.0 drivers a method getBufferSize() is available
                   // in the Blob class, that returns the optimal buffer size
                   byte[] buffer = new byte[10* 1024];
                   // Read a chunk of data from the sample file input stream, and write the
                   // chunk to the Blob column output stream. Repeat till file has been
                   // fully read.
                   int nread = 0; // Number of bytes read
                   while( (nread= fileStream.read(buffer)) != -1 ) // Read from file
                        blobOutputStream.write(buffer, 0, nread); // Write to Blob
         System.out.println("FILE->BLOB -- OK!!");
                   // Close both streams
                   fileStream.close();
                   blobOutputStream.close();
                   //blob.putBytes(1,by);
                   con.commit();
                   rs.close();
                   ps.close();
              catch (Exception e) {
                   e.printStackTrace();

    I had the same problem and have just fixed it. You need to drop the single quotes around the question marks from the sql string. I guess that the PreparedStatement puts these in for you and we both ended up with two sets of single quotes and confused the number of variables. Thus the error.
    Rich

  • FOR UPDATE on scrollable cursor and error: ORA-00907: missing right parenthesis

    If change my query to have a FOR UPDATE and make it an updatable scrollable cursor I get an error on the updateRow() command saying "ORA-00907: missing right parenthesis"
    If I remove the FOR UPDATE it works OK.
    The problem I have is trying to update a CLOB from a ResultSet. If I do not upate any other column I get the error saying that the error"
    "ORA-22920: row containing the LOB value is not locked"
    I can get around this by adding FOR UPDATE. But if I add FOR UPDATE and try to update any non-CLOB column I get the 00907 error above.
    Hmmmm. So here is what I can and cannot do:
    - I CAN update the CLOB IF I update another column 1st and NO FOR UPDATE clause.
    - I CAN update the CLOB only if I have FOR UPDATE clause.
    - I CANNOT update just the CLOB without FOR UPDATE.
    - I CANNOT update any non-CLOB column with FOR UPDATE.
    What a pain in the ***! How am I to provide generic access to the applications being built on my DB layer. This is crazy!

    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Andrew Edgar ([email protected]):
    I have this same problem!
    The error occurs when performing updateRow.
    The turning off of auto commit only gets the query to work but not the actual update.
    Will this be fixed in the next version of the Driver?<HR></BLOCKQUOTE>
    Here is the stack Trace I recieved:
    java.sql.SQLException: ORA-00907: missing right parenthesis
    at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
    at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
    at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
    at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
    at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:822)
    at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1446)
    at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1371)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1900)
    at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:363)
    at oracle.jdbc.driver.UpdatableResultSet.execute_updateRow(UpdatableResultSet.java:2135)
    at oracle.jdbc.driver.UpdatableResultSet.updateRow(UpdatableResultSet.java:1322)

  • FOR UPDATE on updatable cursor and error: ORA-00907: missing right parenthesis

    Anyone run into this? I've searched the message board and bug db to no avail.
    - Using latest Oracle JDBC 2.0 compliant "thin" driver and Oracle 8.1.6 database.
    1) Using prepareStatement specifying an updatable cursor for something like "SELECT FNAME,LNAME FROM USERS FOR UPDATE OF FNAME,LNAME"
    2) Updating FNAME using updateString("FNAME","whatever"), and then calling updateRow() of the ResultSet yields:
    ORA-00907: missing right parenthesis
    If I remove the FOR UPDATE clause then everything works just fine.
    Workarounds/suggestions appreciated!
    Thanks,
    Ryan
    null

    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Andrew Edgar ([email protected]):
    I have this same problem!
    The error occurs when performing updateRow.
    The turning off of auto commit only gets the query to work but not the actual update.
    Will this be fixed in the next version of the Driver?<HR></BLOCKQUOTE>
    Here is the stack Trace I recieved:
    java.sql.SQLException: ORA-00907: missing right parenthesis
    at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
    at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
    at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
    at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
    at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:822)
    at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1446)
    at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1371)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1900)
    at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:363)
    at oracle.jdbc.driver.UpdatableResultSet.execute_updateRow(UpdatableResultSet.java:2135)
    at oracle.jdbc.driver.UpdatableResultSet.updateRow(UpdatableResultSet.java:1322)

  • ORA-12560: TNS:proto adapter error

    Dear Gurus,
    I am having a big problem all of a sudden i am unable to connect to my database (10g 10.2.0.1.0) running on Windows 2003 server.
    It give me the following error
    ORA-12560: TNS:proto adapter error
    When i say
    D:\oracle\product\10.2.0\db_1\BIN>sqlplus / as sysdba
    SQL*Plus: Release 10.2.0.1.0 - Production on Sun Apr 13 12:51:34 2008
    Copyright (c) 1982, 2005, Oracle. All rights reserved.
    ERROR:
    ORA-12560: TNS:proto adapter error
    SO i have opne the SR, they asked me to increase the patch set from 10.2.0.1.0 to 10.2.0.2.0 which i did but still get the same error
    D:\>cd D:\oracle\product\10.2.0\db_1
    D:\oracle\product\10.2.0\db_1>cd bin
    D:\oracle\product\10.2.0\db_1\BIN>sqlplus /nolog
    SQL*Plus: Release 10.2.0.2.0 - Production on Wed Apr 16 12:14:56 2008
    Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
    SQL> startup nomount
    ORA-12560: TNS:proto adapter error
    SQL>
    Tried to set the env such as ORACLE_HOME and ORACLE_SID. Listner is also started.
    More funny is when i check in control panel --> Administration --> Services i can see OracleServiceSID is running as well Oracle Listner is running.
    Any help will make my day
    Regards
    Kiran Rana

    Here we go
    Mon Apr 07 11:11:00 2008
    Thread 1 advanced to log sequence 1403
    Current log# 1 seq# 1403 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ZRB\REDO01.LOG
    Mon Apr 07 22:00:58 2008
    Thread 1 advanced to log sequence 1404
    Current log# 2 seq# 1404 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ZRB\REDO02.LOG
    Mon Apr 07 22:19:12 2008
    Thread 1 advanced to log sequence 1405
    Current log# 3 seq# 1405 mem# 0: D:\ORACLE\PRODUCT\10.2.0\ORADATA\ZRB\REDO03.LOG
    Regards
    Kiran Rana

  • ORA-31201 and APEX ERR-1082 LDAP sessions

    Hello!
    While using Single-Sing-On from APEX against OID (Portal Applicationserver 10.1.4) we get the following error:
    ORA-31201: DBMS_LDAP: allgemeiner Fehler: number of active LDAP sessions exceeded the limit of 63 sessions
    Error ERR-1082 Error in executing authorization scheme code.
    It works many times, but suddenly we seem to get a limit!
    Details:
    ========
    We use Application Express Version 2.2.1.00.04.
    First we've tried to use the APEX-LDAP-Function is_member().
    (See thread Re: Using Oracle Portal group for an authorization scheme
    It worked, but we got the same error as above.
    Then:
    But as I read in thread ERR-1082 Error in executing authorization scheme code I changed the strategy and then used the CHECK_GROUP_MEMBERSHIP function.
    We set the evaluation point for the authorization scheme to "Once per Session", too.
    But we still got the error.
    What am I doing wrong?
    What can we check? OID or APEX?
    Here is the code for both (main-function for checking the membership and a helping function which is getting the right value out of the OID on basis of the :APP_USER-Value).
    Create or Replace Function PRUEFE_MITGLIEDSCHAFT (p_uid varchar2, p_gid varchar2) return BOOLEAN is
    --CALL for testing:
    --set serveroutput on;
    --BEGIN
    --IF PRUEFE_MITGLIEDSCHAFT('glasauerj','KV_OKL_P_SCHUL_ADM') THEN
    --DBMS_OUTPUT.PUT_LINE('yes!');
    --END IF;
    --END;
    --CALL for APEX:
    --return PRUEFE_MITGLIEDSCHAFT(:APP_USER,'KV_OKL_P_SCHUL_ADM')
    --Declarations
    ldap_port PLS_INTEGER;
    ldap_host VARCHAR2(256);
    ldap_user VARCHAR2(256):= NULL;
    ldap_passwd VARCHAR2(256):= NULL;
    retval PLS_INTEGER;
    my_session DBMS_LDAP.session;
    group_handle DBMS_LDAP_UTL.HANDLE;
    user_handle DBMS_LDAP_UTL.HANDLE;
    user_type PLS_INTEGER;
    user_id VARCHAR2(2000);
    group_type PLS_INTEGER;
    group_id VARCHAR2(2000);
    begin
    NULL;
    ldap_host := 'host';
    ldap_port := '389';
    user_id := 'cn='||get_oid_cn(lower(p_uid))||','||get_oid_searchbase(lower(p_uid));
    group_id := 'cn='||lower(p_gid)||', cn=portal30.060830.1405, cn=Groups, dc=lkh-ktn, dc=local';
    my_session := DBMS_LDAP.init(ldap_host,ldap_port);
    user_type := DBMS_LDAP_UTL.TYPE_DN;
    group_type := DBMS_LDAP_UTL.TYPE_DN;
    retval := DBMS_LDAP_UTL.create_user_handle(user_handle,user_type,user_id);
    --DBMS_OUTPUT.PUT_LINE('create_user_handle='||retval);
    retval := DBMS_LDAP_UTL.create_group_handle(group_handle,group_type,group_id);
    --DBMS_OUTPUT.PUT_LINE('create_group_handle='||retval);
    retval := DBMS_LDAP_UTL.check_group_membership( my_session,user_handle,group_handle,DBMS_LDAP_UTL.NESTED_MEMBERSHIP);
    --DBMS_OUTPUT.PUT_LINE('check_group_membership='||retval);
    IF retval = DBMS_LDAP_UTL.SUCCESS THEN
         --DBMS_OUTPUT.PUT_LINE('DBMS_LDAP_UTL.SUCCESS');
         return true;
    else
         return false;
    end if;
    IF retval != DBMS_LDAP_UTL.SUCCESS THEN
    DBMS_OUTPUT.PUT_LINE('Error : check_group_membership returns : ' || to_char(retval));
    IF retval = DBMS_LDAP_UTL.PARAM_ERROR THEN
         DBMS_OUTPUT.PUT_LINE('DBMS_LDAP_UTL.PARAM_ERROR');
    end if;
    return false;
    ELSE
    NULL;
    --DBMS_OUTPUT.PUT_LINE(': Successful.');
    END IF;
    DBMS_LDAP_UTL.free_handle(user_handle);
    DBMS_LDAP_UTL.free_handle(group_handle);
    return false;
    End;
    HELPING-FUNCTION
    Create or Replace FUNCTION get_oid_searchbase(p_uid varchar2) return varchar2 is
    l_dn varchar2(500);
    l_searchbase varchar2(500);
    l_uid varchar2(100);
    my_session DBMS_LDAP.session;
    my_message DBMS_LDAP.message;
    my_attrs DBMS_LDAP.string_collection;
    retval PLS_INTEGER;
    ldap_host VARCHAR2(256):= 'host';
         ldap_port VARCHAR2(256):= '389';
    ldap_user VARCHAR2(256):= NULL;
    ldap_passwd VARCHAR2(256):= NULL;
    ldap_userbase VARCHAR2(500) := 'cn=Users,dc=lkh-ktn,dc=local';
    BEGIN
    -- Beispiel dn und searchbase aufgrund von uid
    -- Choosing exceptions to be raised by DBMS_LDAP library.
         DBMS_LDAP.USE_EXCEPTION := TRUE;
         -- Generieren der LDAP-message
         my_session := DBMS_LDAP.init(ldap_host,ldap_port);
    retval := DBMS_LDAP.simple_bind_s(my_session, ldap_user, ldap_passwd);
    my_attrs(1) := 'uid'; -- retrieve this attribute
    l_uid := 'uid='||p_uid;
    retval := DBMS_LDAP.search_s(my_session,
    ldap_userbase,
    DBMS_LDAP.SCOPE_SUBTREE,
    l_uid,
    my_attrs,
    0,
    my_message);
    -- LDAP-message mit get_dn auslesen und cn wegschneiden
    l_dn := DBMS_LDAP.get_dn(my_session,my_message);
    l_searchbase := substr(l_dn,instr(l_dn,',')+1,length(l_dn));
    return l_searchbase;
    EXCEPTION
    WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE(' Error code : ' || TO_CHAR(SQLCODE));
    DBMS_OUTPUT.PUT_LINE(' Error Message : ' || SQLERRM);
    DBMS_OUTPUT.PUT_LINE(' Exception encountered .. exiting');
    return null;
    END;
    sho err;
    PLEASE, I would appreciate any help!
    Joerg

    I should have called it unreachable code. You have this block:
    IF retval = DBMS_LDAP_UTL.SUCCESS THEN
    --DBMS_OUTPUT.PUT_LINE('DBMS_LDAP_UTL.SUCCESS');
    return true;
    else
    return false;
    end if;
    No code after this block will execute but there is code after it.
    Scott

  • Help!! ORA-01000: maximum open cursors exceeded

    Dear All,
    Here is my software information:
    Platform: WLP7.0sp2
    OS : solaris8
    And I have two connection Pools, their settings are:
    Initial Capacity: 10
    Maximum Capacity: 10
    Capacity Increment: 1
    Login Delay Seconds: 0 seconds
    Refresh Period: 0 minutes
    Shrink Period: 15 minutes
    Prepared Statement Cache Size: 5
    When I start my Weblogic Portal server, it happened the following exceptions:
    java.sql.SQLException: ORA-01000: maximum open cursors exceeded
    ORA-06512: at "SYS.STANDARD", line 1014
    ORA-06512: at "TU_PORTLET_P13N", line 2
    ORA-04088: error during execution of trigger 'TU_PORTLET_P13N'
    at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:169)
    at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
    at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
    at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
    at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:822)
    at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1602)
    at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1527)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2045)
    at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:39
    5)
    at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:446)
    at weblogic.jdbc.pool.Statement.execute(Statement.java:274)
    at weblogic.jdbc.rmi.internal.PreparedStatementImpl.execute(PreparedStatementImpl.java:378)
    at weblogic.jdbc.rmi.SerialPreparedStatement.execute(SerialPreparedStatement.java:401)
    at com.bea.portal.manager.internal.persistence.jdbc.JdbcPortalPersistenceHelper.addOrUpdate
    PageP13nPortlets(JdbcPortalPersistenceHelper.java:785)
    at com.bea.portal.manager.internal.persistence.jdbc.JdbcPortalPersistenceHelper.addOrUpdate
    PortalP13nPages(JdbcPortalPersistenceHelper.java:508)
    at com.bea.portal.manager.internal.persistence.jdbc.JdbcPortalPersistenceManager.addOrUpdat
    ePortalPersonalization(JdbcPortalPersistenceManager.java:414)
    at com.bea.portal.manager.internal.persistence.MainPersistenceManager.addOrUpdatePortalPers
    onalization(MainPersistenceManager.java:104)
    at com.bea.portal.manager.internal.PortalPersistenceManager.updatePortalModel(PortalPersist
    enceManager.java:330)
    at com.bea.portal.manager.internal.PortalPersistenceManager.createDataItem(PortalPersistenc
    eManager.java:199)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.handleDataItemMe
    ssage(AbstractDataRepository.java:814)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.onDataSyncMessag
    e(AbstractDataRepository.java:990)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.executeMessage(A
    bstractDataRepository.java:252)
    at com.bea.p13n.management.data.message.internal.JvmCommunicationPipe.sendMessage(JvmCommun
    icationPipe.java:116)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.onSyncRequestRes
    ultMessage(AbstractDataRepository.java:1185)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.executeMessage(A
    bstractDataRepository.java:261)
    at com.bea.p13n.management.data.message.internal.JvmCommunicationPipe.sendMessage(JvmCommun
    icationPipe.java:116)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.onSyncRequestMes
    sage(AbstractDataRepository.java:1086)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.executeMessage(A
    bstractDataRepository.java:257)
    at com.bea.p13n.management.data.message.internal.JvmCommunicationPipe.sendMessage(JvmCommun
    icationPipe.java:116)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.notifyDataReposi
    tory(AbstractDataRepository.java:706)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.onRefreshMessage
    (AbstractDataRepository.java:912)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.executeMessage(A
    bstractDataRepository.java:247)
    at com.bea.p13n.management.data.message.internal.JvmCommunicationPipe.sendMessage(JvmCommun
    icationPipe.java:116)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.sendRefreshMessa
    geToThis(AbstractDataRepository.java:341)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.addNotifiedDataR
    epository(AbstractDataRepository.java:324)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.addNotifiedDataR
    epository(AbstractDataRepository.java:304)
    at com.bea.portal.manager.internal.DeploymentManager.initializePortal(DeploymentManager.jav
    a:142)
    at com.bea.portal.manager.internal.DeploymentManager.initialize(DeploymentManager.java:101)
    at com.bea.portal.manager.internal.PortalManagerDelegateImpl.<init>(PortalManagerDelegateIm
    pl.java:86)
    at com.bea.portal.manager.PortalFactory.createPortalManagerDelegate(PortalFactory.java:248)
    at com.bea.portal.manager.ejb.internal.PortalManagerBean.ejbCreate(PortalManagerBean.java:1
    47)
    Any ideas will be appreciated.
    Robert

    Robert Chao wrote:
    Dear All,
    Here is my software information:
    Platform: WLP7.0sp2
    OS : solaris8
    And I have two connection Pools, their settings are:
    Initial Capacity: 10
    Maximum Capacity: 10
    Capacity Increment: 1
    Login Delay Seconds: 0 seconds
    Refresh Period: 0 minutes
    Shrink Period: 15 minutes
    Prepared Statement Cache Size: 5Hi. You should either configure your DBMS to allow more open cursors per connection,
    or you can try setting the prepared statement cache size to zero.
    Joe
    >
    When I start my Weblogic Portal server, it happened the following exceptions:
    java.sql.SQLException: ORA-01000: maximum open cursors exceeded
    ORA-06512: at "SYS.STANDARD", line 1014
    ORA-06512: at "TU_PORTLET_P13N", line 2
    ORA-04088: error during execution of trigger 'TU_PORTLET_P13N'
    at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:169)
    at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
    at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
    at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
    at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:822)
    at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:1602)
    at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1527)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2045)
    at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:39
    5)
    at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:446)
    at weblogic.jdbc.pool.Statement.execute(Statement.java:274)
    at weblogic.jdbc.rmi.internal.PreparedStatementImpl.execute(PreparedStatementImpl.java:378)
    at weblogic.jdbc.rmi.SerialPreparedStatement.execute(SerialPreparedStatement.java:401)
    at com.bea.portal.manager.internal.persistence.jdbc.JdbcPortalPersistenceHelper.addOrUpdate
    PageP13nPortlets(JdbcPortalPersistenceHelper.java:785)
    at com.bea.portal.manager.internal.persistence.jdbc.JdbcPortalPersistenceHelper.addOrUpdate
    PortalP13nPages(JdbcPortalPersistenceHelper.java:508)
    at com.bea.portal.manager.internal.persistence.jdbc.JdbcPortalPersistenceManager.addOrUpdat
    ePortalPersonalization(JdbcPortalPersistenceManager.java:414)
    at com.bea.portal.manager.internal.persistence.MainPersistenceManager.addOrUpdatePortalPers
    onalization(MainPersistenceManager.java:104)
    at com.bea.portal.manager.internal.PortalPersistenceManager.updatePortalModel(PortalPersist
    enceManager.java:330)
    at com.bea.portal.manager.internal.PortalPersistenceManager.createDataItem(PortalPersistenc
    eManager.java:199)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.handleDataItemMe
    ssage(AbstractDataRepository.java:814)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.onDataSyncMessag
    e(AbstractDataRepository.java:990)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.executeMessage(A
    bstractDataRepository.java:252)
    at com.bea.p13n.management.data.message.internal.JvmCommunicationPipe.sendMessage(JvmCommun
    icationPipe.java:116)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.onSyncRequestRes
    ultMessage(AbstractDataRepository.java:1185)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.executeMessage(A
    bstractDataRepository.java:261)
    at com.bea.p13n.management.data.message.internal.JvmCommunicationPipe.sendMessage(JvmCommun
    icationPipe.java:116)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.onSyncRequestMes
    sage(AbstractDataRepository.java:1086)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.executeMessage(A
    bstractDataRepository.java:257)
    at com.bea.p13n.management.data.message.internal.JvmCommunicationPipe.sendMessage(JvmCommun
    icationPipe.java:116)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.notifyDataReposi
    tory(AbstractDataRepository.java:706)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.onRefreshMessage
    (AbstractDataRepository.java:912)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.executeMessage(A
    bstractDataRepository.java:247)
    at com.bea.p13n.management.data.message.internal.JvmCommunicationPipe.sendMessage(JvmCommun
    icationPipe.java:116)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.sendRefreshMessa
    geToThis(AbstractDataRepository.java:341)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.addNotifiedDataR
    epository(AbstractDataRepository.java:324)
    at com.bea.p13n.management.data.repository.internal.AbstractDataRepository.addNotifiedDataR
    epository(AbstractDataRepository.java:304)
    at com.bea.portal.manager.internal.DeploymentManager.initializePortal(DeploymentManager.jav
    a:142)
    at com.bea.portal.manager.internal.DeploymentManager.initialize(DeploymentManager.java:101)
    at com.bea.portal.manager.internal.PortalManagerDelegateImpl.<init>(PortalManagerDelegateIm
    pl.java:86)
    at com.bea.portal.manager.PortalFactory.createPortalManagerDelegate(PortalFactory.java:248)
    at com.bea.portal.manager.ejb.internal.PortalManagerBean.ejbCreate(PortalManagerBean.java:1
    47)
    Any ideas will be appreciated.
    Robert

  • Mysterious java.sql.SQLException: ORA-00600:

    Hi All,
    I'm running oracle 9.0.2 on windows xp, 512meg mem.
    No problem accessing the db via isql, no problem with jdbc
    doing inserts but can't query?!
    DriverManager.registerDriver((Driver)drvClass.newInstance());
    m_con = DriverManager.getConnection(jdbc:oracle:thin:@127.0.0.1:1521:oracle, "SCOTT","TIGER");
    stmt = m_con.createStatement();
    rs = stmt.executeQuery("SELECT EMPNO,ENAME FROM EMP WHERE EMPNO=7900");
    while(rs.next()) System.out.println(rs.getString("ENAME"));
    Running the above gets this result:
    java.sql.SQLException: ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
         at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
         at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
         at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
         at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
         at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:889)
         at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:1681)
         at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1870)
         at oracle.jdbc.driver.OracleStatement.executeQuery(OracleStatement.java:538)
         at testprg.DbTest2.main(DbTest2.java:17)
    Exception in thre[i]Long postings are being truncated to ~1 kB at this time.

    Take a look at the version of the JDBC driver. There a thread in a metalink forum regarding the same 600 error.
    Ken

  • ORA-00610: Internal error code

    We are getting the following error in production can anybody suggest
    ORA-00610: Internal error code
    Tue Feb 27 16:55:47 2007
    Process J001 died, see its trace file
    Tue Feb 27 16:55:47 2007
    kkjcre1p: unable to spawn jobq slave process
    Tue Feb 27 16:55:47 2007
    Errors in file e:\oracle\product\10.2.0\admin\erp\bdump\erp_cjq0_4928.trc:
    Tue Feb 27 17:07:59 2007
    kkjcre1p: unable to spawn jobq slave process
    Tue Feb 27 17:07:59 2007
    Errors in file e:\oracle\product\10.2.0\admin\erp\bdump\erp_cjq0_4928.trc:

    Dump file e:\oracle\product\10.2.0\admin\erp\bdump\erp_cjq0_4928.trc
    Tue Feb 27 14:37:18 2007
    ORACLE V10.2.0.1.0 - 64bit Production vsnsta=0
    vsnsql=14 vsnxtr=3
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
    With the Partitioning, OLAP and Data Mining options
    Windows Server 2003 Version V5.2 Service Pack 1
    CPU : 8 - type 8664, 4 Physical Cores
    Process Affinity : 0x0000000000000000
    Memory (Avail/Total): Ph:8460M/16379M, Ph+PgF:10027M/17250M
    Instance name: erp
    Redo thread mounted by this instance: 1
    Oracle process number: 10
    Windows thread id: 4928, image: ORACLE.EXE (CJQ0)
    *** 2007-02-27 14:38:15.171
    *** SERVICE NAME:(SYS$BACKGROUND) 2007-02-27 14:37:18.734
    *** SESSION ID:(547.1) 2007-02-27 14:37:18.734
    Waited for process J001 to initialize for 60 seconds
    *** 2007-02-27 14:38:15.187
    Dumping diagnostic information for J001:
    OS tid = 3104
    Memory (Avail/Total): Ph:8460M/16379M, Ph+PgF:10030M/17250M
    ------------------- Call Stack Trace ---------------------
    calling location entry point arg #1 arg #2 arg #3 arg #4
    0000000078EF149A 0000000000000000 0000000000000000 0000000000000000 000000000df50080 0000000000000000
    0000000078EE4DEC 0000000078EF149A 0000000005b60000 000000001df59870 0000000000000001 0000000005cad78d
    0000000078EE62CB 0000000078EE4DEC 0000000005caec0d 000000001df5a690 000000001df598d8 0000000000000000
    0000000078EE68FA 0000000078EE62CB 0000000000000002 000000001df5a450 0000000000000002 000000001df599f0
    000007FF7FC6880A 0000000078EE68FA 00000001984abcf0 0000000005cab218 000000001df59f40 0000000000000001
    pfr_chk_inst+121 000007FF7FC6880A 000000000000ff80 0000000000002000 0000000014166514 0000000004b07ac8
    pfrinstr_XCAL_SCAL+73 pfr_chk_inst+121 0000000000000000 0000000000000002 0000000015112368 0000000015112368
    pfrinstr_XCAL+15 pfrinstr_XCAL_SCAL+73 00000000141664c8 000000001df5a658 000000001df5a6e0 0000000005b60000
    pfrrun_no_tool+76 pfrinstr_XCAL+15 0000000000000001 000000018d1f3208 0000000000007fff 0000000000000458
    pfrrun+1093 pfrrun_no_tool+76 0000000000000fff 0000000000000030 0000000000000000 0000000000000000
    plsql_run+929 pfrrun+1093 0000000015112368 0000000014160040 000000001df5b140 0000000005cf29e9
    peicnt+316 plsql_run+929 0000000015112368 0000000004f10001 0000000000000000 0000000001d83b0b
    kkxexe+573 peicnt+316 000000001df5b140 0000000015112368 00000001a6c2c4d0 0000000000000000
    opiexe+5165 kkxexe+573 0000000015110df8 0000000100000003 0000000000000102 0000000000000000
    opiodr+1305 opiexe+5165 0000000000000004 0000000000000004 000000001df5d710 0000000000000000
    rpidrus+230 opiodr+1305 0000000000000004 0000000000000004 000000001df5d710 0000000000000005
    rpidru+112 rpidrus+230 000000001df5cf10 000000001df5cf80 0000000000000013 0000000026d4a010
    rpiswu2+508 rpidru+112 0000000000000008 0000000000952eaa 0000000000000000 0000000000000000
    rpidrv+1756 rpiswu2+508 00000001b053ca98 0000027f00000033 000000001df5d5e0 0000000000000002
    rpiexe+89 rpidrv+1756 0000000000000005 0000000000000004 000000001df5d710 000000000000000a
    kkjex1e+7530 rpiexe+89 0000000000000008 00000001b053ca02 0000000000000001 0000000000000000
    kkjsexe+414 kkjex1e+7530 000000001df5e5bc 0000000100000001 0000000000000000 000000001df5e5a0
    kkjrdp+965 kkjsexe+414 0000000000000000 000000000759f030 00000000075a06f0 00000000000000b9
    opirip+1216 kkjrdp+965 30315c740000001e 0000000003a782e8 000000001df5fa70 0000000000000000
    opidrv+860 opirip+1216 0000000000000032 0000000000000004 000000001df5fda0 0000000000000000
    sou2o+52 opidrv+860 0000000000000032 0000000000000004 000000001df5fda0 00000000066cfa22
    opimai_real+272 sou2o+52 0000000000000000 0000000007580000 000000000000353c 0000000000000000
    opimai+96 opimai_real+272 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    BackgroundThreadStart+530 opimai+96 000000001df5fef0 0000000000000001 0000000000000000 0000000000000000
    0000000077D6B69A BackgroundThreadStart+530 00000000402bc1a0 0000000000000000 0000000000000000 000000001df5ffa8
    ---------------- End of Call Stack Trace -----------------
    Call stack acquisition performance stats:
    setup time (lock acquis., memory alloc.): 16141 ms
    frame get time (time the target proc was suspended): 1062 ms
    symbol translation time: 139438 ms
    total time: 156641 ms
    *** 2007-02-27 14:40:56.078
    *** 2007-02-27 15:03:06.000
    Waited for process J000 to be spawned for 60 seconds
    *** 2007-02-27 15:03:17.000
    Waited for process J000 to be spawned for 71 seconds
    *** 2007-02-27 15:03:28.000
    Waited for process J000 to be spawned for 82 seconds
    *** 2007-02-27 15:03:39.000
    Waited for process J000 to be spawned for 93 seconds
    *** 2007-02-27 15:03:50.000
    Waited for process J000 to initialize for 104 seconds
    *** 2007-02-27 15:03:50.000
    Dumping diagnostic information for J000:
    OS tid = 1076
    Memory (Avail/Total): Ph:8448M/16379M, Ph+PgF:10023M/17250M
    ------------------- Call Stack Trace ---------------------
    calling location entry point arg #1 arg #2 arg #3 arg #4
    0000000078EF13EA 0000000000000000 0000000000000000 0000000000000000 000000000df50080 0000000000000000
    0000000077D6F407 0000000078EF13EA 000000002bccd850 0000000000000022 00000001b0704c08 000000005bde7450
    0000000077D6F451 0000000077D6F407 0000004c0000002e 0000000000000000 0000000000080000 0000000006be9bc0
    ssrf_mem_alc+120 0000000077D6F451 000000002bcce01f 0000000000000008 0000000000000020 0000000000030000
    skgmrf_extend+348 ssrf_mem_alc+120 0000000000000000 00000002097c0030 0000000004b45a60 0000000004b43860
    skgmrf_alloc+1306 skgmrf_extend+348 000000002bcce258 000000002bcce2b8 000000002bccdf2c 000000002bccdf18
    ksmrf_init_alloc+58 skgmrf_alloc+1306 0000000000000c00 000000005bdcf638 000000005bdcf668 0000000004ef0e61
    ksmarfg+162 ksmrf_init_alloc+58 00000000184966e8 00000000000000ff 0000000000000000 00000000184aa7c8
    kghgex+1405 ksmarfg+162 0000000000000458 0000000000000000 0000000000000000 0000000018496550
    kghfnd+612 kghgex+1405 0000000000007fff 00000000184aa814 0000000000000428 000000005bdcbef0
    kghalo+560 kghfnd+612 0000000000000418 0000000000000000 0000000003e69950 0000000000000000
    kghgex+554 kghalo+560 01c75a5226618c76 0000000000000000 00000000002887fa 00000000004995b4
    kghalf+516 kghgex+554 000000000539bf20 0000000004efcb8e 00000000151f47d8 0000000000000000
    kghssgai+998 kghalf+516 000000000001d570 000000002bccdf60 000000000001d6a0 000000005bdcb8b0
    kodpai+299 kghssgai+998 000000005bdcbef0 00000000184a6930 00000000184964c8 0000000008000000
    kokgugi+555 kodpai+299 000000005bdcbef0 0000000000000000 0000000003b9d048 0000000000000006
    ksmuin+33 kokgugi+555 0000a531fe24a2cd 00000001b03a8838 00000001b05d5c90 000000000001d570
    ksucre+920 ksmuin+33 00000001b055ec80 6375646f72705c65 302e322e30315c74 6c6e5c315f62645c
    kkjrdp+708 ksucre+920 0000000000000000 00000000151af030 00000000151b06f0 00000000000000b9
    opirip+1216 kkjrdp+708 30315c740000001e 0000000003a782e8 000000002bccfa70 0000000000000000
    opidrv+860 opirip+1216 0000000000000032 0000000000000004 000000002bccfda0 0000000000000000
    sou2o+52 opidrv+860 0000000000000032 0000000000000004 000000002bccfda0 00000000066cfa22
    opimai_real+272 sou2o+52 0000000000000000 0000000015190000 0000000000003878 0000000000000000
    opimai+96 opimai_real+272 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    BackgroundThreadStart+530 opimai+96 000000002bccfef0 0000000000000001 0000000000000000 0000000000000000
    0000000077D6B69A BackgroundThreadStart+530 00000000245750b0 0000000000000000 0000000000000000 000000002bccffa8
    ---------------- End of Call Stack Trace -----------------
    Call stack acquisition performance stats:
    setup time (lock acquis., memory alloc.): 1937 ms
    frame get time (time the target proc was suspended): 469 ms
    symbol translation time: 63 ms
    total time: 2469 ms
    *** 2007-02-27 15:05:19.015
    *** 2007-02-27 16:50:45.125
    Waited for process J001 to initialize for 60 seconds
    *** 2007-02-27 16:50:45.125
    Dumping diagnostic information for J001:
    OS tid = 788
    Memory (Avail/Total): Ph:8463M/16379M, Ph+PgF:10122M/17250M
    ------------------- Call Stack Trace ---------------------
    calling location entry point arg #1 arg #2 arg #3 arg #4
    0000000078EF149A 0000000000000000 0000000000000000 0000000000000000 000000000df50080 0000000000000000
    0000000078EE4DEC 0000000078EF149A 0000000078ec0000 000000006f16d930 0000000000000001 0000000078fb5cfc
    0000000078EE62CB 0000000078EE4DEC 000007ff7fc6880a 000000006f16f040 000000006f16d998 0000000000000000
    0000000078EE68FA 0000000078EE62CB 0030003100000002 000000006f16d950 0000000000000002 000000006f16dab0
    000007FF7FC6880A 0000000078EE68FA 000000000001d570 000000000095a61d 000000006f16e000 00000000000001bf
    kgepop+176 000007FF7FC6880A 0000000000000000 0000a531fe414f41 0000000000000000 000000005c59a370
    kgesev+130 kgepop+176 0000000000000000 0000000000000000 0000000003a74dfc 0000000000000000
    ksesec0+102 kgesev+130 0000000000000000 000000005c586990 000000005c5861d0 000000005c5a4548
    kkjrdp+2094 ksesec0+102 00000000000001bf 000000005c586990 000000002e35f780 000000002e35ec80
    opirip+1216 kkjrdp+2094 30315c740000001e 0000000003a782e8 000000006f16fa70 0000000000000000
    opidrv+860 opirip+1216 0000000000000032 0000000000000004 000000006f16fda0 0000000000000000
    sou2o+52 opidrv+860 0000000000000032 0000000000000004 000000006f16fda0 00000000066cfa22
    opimai_real+272 sou2o+52 0000000000000000 000000001d220000 0000000000003010 0000000000000000
    opimai+96 opimai_real+272 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    BackgroundThreadStart+530 opimai+96 000000006f16fef0 0000000000000001 0000000000000000 0000000000000000
    0000000077D6B69A BackgroundThreadStart+530 00000000245510b0 0000000000000000 0000000000000000 000000006f16ffa8
    ---------------- End of Call Stack Trace -----------------
    Call stack acquisition performance stats:
    setup time (lock acquis., memory alloc.): 1563 ms
    frame get time (time the target proc was suspended): 31 ms
    symbol translation time: 31 ms
    total time: 1625 ms
    *** 2007-02-27 16:55:25.203
    *** 2007-02-27 16:55:36.203
    Waited for process J001 to initialize for 71 seconds
    *** 2007-02-27 16:55:36.203
    Dumping diagnostic information for J001:
    OS tid = 788
    Memory (Avail/Total): Ph:8485M/16379M, Ph+PgF:10127M/17250M
    ------------------- Call Stack Trace ---------------------
    calling location entry point arg #1 arg #2 arg #3 arg #4
    0000000078F11C9B 0000000000000000 0000000000000000 0000000000000000 000000000df50080 0000000000000000
    0000000078EF6810 0000000078F11C9B 0000000000000000 000000003b19d1c0 0000000000000000 0000000004940000
    0000000078EE37F4 0000000078EF6810 000000003b19d1d0 000000005c588898 00000000ffffffff 000000000001e5e0
    sltsmxd+21 0000000078EE37F4 000000005c59a370 000000005c588898 000000000001d850 000000000001e5e0
    kpomeminit+246 sltsmxd+21 000000000001d570 000000006f16f3a0 000000005c59a370 000000006f16f3a0
    kscnfy+691 kpomeminit+246 0000000000000017 0000000000000000 0000000000000000 0000000000000037
    ---------------- End of Call Stack Trace -----------------
    Call stack acquisition performance stats:
    setup time (lock acquis., memory alloc.): 3672 ms
    frame get time (time the target proc was suspended): 1281 ms
    symbol translation time: 485 ms
    total time: 5438 ms
    *** 2007-02-27 16:55:45.468
    *** 2007-02-27 16:55:47.468
    Process J001 is dead (pid=788, state=5):
    *** 2007-02-27 17:01:01.375
    Waited for process J001 to initialize for 60 seconds
    *** 2007-02-27 17:01:01.375
    Dumping diagnostic information for J001:
    OS tid = 3716
    Memory (Avail/Total): Ph:8432M/16379M, Ph+PgF:9935M/17250M
    ------------------- Call Stack Trace ---------------------
    calling location entry point arg #1 arg #2 arg #3 arg #4
    0000000078EF12AA 0000000000000000 0000000000000000 0000000000000000 000000000df50080 0000000000000000
    0000000077D7047F 0000000078EF12AA 0000000010c258b8 0000000010c401e0 0000000010c40160 0000000010c258b8
    ssthreadop+241 0000000077D7047F 00000000000000ac 000007ff7fc485c4 0000000000000000 000000005b6bf9e8
    ---------------- End of Call Stack Trace -----------------
    Call stack acquisition performance stats:
    setup time (lock acquis., memory alloc.): 828 ms
    frame get time (time the target proc was suspended): 141 ms
    symbol translation time: 0 ms
    total time: 969 ms
    *** 2007-02-27 17:01:03.046
    *** 2007-02-27 17:05:17.031
    Waited for process J000 to be spawned for 60 seconds
    *** 2007-02-27 17:05:28.031
    Waited for process J000 to be spawned for 71 seconds
    *** 2007-02-27 17:05:39.031
    Waited for process J000 to be spawned for 82 seconds
    *** 2007-02-27 17:05:50.031
    Waited for process J000 to be spawned for 93 seconds
    *** 2007-02-27 17:06:01.031
    Waited for process J000 to be spawned for 104 seconds
    *** 2007-02-27 17:06:12.031
    Waited for process J000 to be spawned for 115 seconds
    *** 2007-02-27 17:07:59.093
    *** 2007-02-27 17:11:22.093
    Waited for process J000 to be spawned for 60 seconds
    *** 2007-02-27 17:11:33.093
    Waited for process J000 to initialize for 71 seconds
    *** 2007-02-27 17:11:33.093
    Dumping diagnostic information for J000:
    OS tid = 2156
    Memory (Avail/Total): Ph:8266M/16379M, Ph+PgF:9441M/17250M
    ------------------- Call Stack Trace ---------------------
    calling location entry point arg #1 arg #2 arg #3 arg #4
    0000000078EF149A 0000000000000000 0000000000000000 0000000000000000 000000000df50080 0000000000000000
    0000000078EE4DEC 0000000078EF149A 0000000078ec0000 000000003fbed370 0000000000000001 0000000078fb5c30
    0000000078EE62CB 0000000078EE4DEC 0000000078ee6fd2 000000003fbee790 000000003fbed3d8 000000003fbee060
    0000000078EE68FA 0000000078EE62CB 0000000000000002 000000003fbedad0 0000000000000002 000000003fbedb90
    0000000078EE6D89 0000000078EE68FA 0000000000000000 000000000045ef9f 000000003fbee6e0 ffffffffebadebad
    0000000078EE4BDD 0000000078EE6D89 000000000045ef92 000000003fbee790 000000003fbee6e0 0000000000000000
    0000000078EE685A 0000000078EE4BDD 0000000000000001 0000000000000000 000000003fbee6e0 000000003fbee6c0
    0000000078EE6FD2 0000000078EE685A 0000000000000000 000000003fbee1e0 000000003fbee6e0 000000003fbee7b0
    0000000077D67D4D 0000000078EE6FD2 000000000643ac04 00000001df492010 0000000000000000 00000001df497750
    skdstinit_late+36 0000000077D67D4D 0000000400000000 00000001df4a61b0 0000000000000000 00000001df497750
    skdstinitex+107 skdstinit_late+36 00000001df497750 0000000000000340 000000000001d568 0000000004f70e75
    skdstinit+105 skdstinitex+107 000000001906e6d0 0000000004c56cf2 000000003fbef350 0000000004c49b04
    ksenfy+107 skdstinit+105 0000000000000003 0000000077d5d62f 0000000000000000 000000000596ab58
    kscnfy+691 ksenfy+107 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    opirip+116 kscnfy+691 30315c7400000007 0000000000000000 726f7774656e5c31 71735c676f6c5c6b
    opidrv+860 opirip+116 0000000000000032 0000000000000004 000000003fbefda0 0000000000000000
    sou2o+52 opidrv+860 0000000000000032 0000000000000004 000000003fbefda0 00000000066cfa22
    opimai_real+272 sou2o+52 0000000000000000 0000000019050000 0000000000001dac 0000000000000000
    opimai+96 opimai_real+272 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    BackgroundThreadStart+530 opimai+96 000000003fbefef0 0000000000000001 0000000000000000 0000000000000000
    0000000077D6B69A BackgroundThreadStart+530 00000000404e6320 0000000000000000 0000000000000000 000000003fbeffa8
    ---------------- End of Call Stack Trace -----------------
    Call stack acquisition performance stats:
    setup time (lock acquis., memory alloc.): 4281 ms
    frame get time (time the target proc was suspended): 453 ms
    symbol translation time: 0 ms
    total time: 4734 ms
    *** 2007-02-27 17:11:46.609
    *** 2007-02-27 17:11:57.609
    Waited for process J000 to initialize for 82 seconds
    *** 2007-02-27 17:11:57.609
    Dumping diagnostic information for J000:
    OS tid = 2156
    Memory (Avail/Total): Ph:8266M/16379M, Ph+PgF:9448M/17250M
    ------------------- Call Stack Trace ---------------------
    calling location entry point arg #1 arg #2 arg #3 arg #4
    0000000078EF12AA 0000000000000000 0000000000000000 0000000000000000 000000000df50080 0000000000000000
    0000000078EFC216 0000000078EF12AA 00000001df492650 0000000000000000 0000000000000000 0000000000000000
    0000000078EFC2A8 0000000078EFC216 0000000078fa7e20 00000001df4adbb0 0000000000000004 0000000000000001
    0000000078EFB9CB 0000000078EFC2A8 0000000004944fe0 0000000000000015 000000003fbedab0 000000003fbedab0
    0000000078EFA9BE 0000000078EFB9CB 0000000000000000 0000000000000000 00000001df492398 00000001df492390
    0000000077D6C3FB 0000000078EFA9BE 000000001de40010 0000000000000000 0000a531fe6647a6 00000001df492350
    000007FF771557CD 0000000077D6C3FB 0000000000000238 0000000000000000 0000000000000000 0000000000000290
    sldmInit+63 000007FF771557CD 0000000003e00002 00000001df492650 0000000000000001 000000001de4f1d0
    ldmInit+326 sldmInit+63 000000003fbedfa0 000000000001eb18 000000000001d570 0000000000d9124d
    keltnfy+226 ldmInit+326 0000000000000000 0000000000000000 00000001b05d5dd8 000000000000000f
    kscnfy+691 keltnfy+226 000000000000000f 00000001b03b8f78 0000000000004558 0000000000000000
    ksucrp+1037 kscnfy+691 007072650000000f 00000001b03b8f78 0000000000000000 000007ff7fc4d21d
    kkjrdp+363 ksucrp+1037 0000000000000001 000000001906f030 00000000190706f0 00000000000000b9
    opirip+1216 kkjrdp+363 30315c740000001e 0000000003a782e8 000000003fbefa70 0000000000000000
    opidrv+860 opirip+1216 0000000000000032 0000000000000004 000000003fbefda0 0000000000000000
    sou2o+52 opidrv+860 0000000000000032 0000000000000004 000000003fbefda0 00000000066cfa22
    opimai_real+272 sou2o+52 0000000000000000 0000000019050000 0000000000001dac 0000000000000000
    opimai+96 opimai_real+272 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    BackgroundThreadStart+530 opimai+96 000000003fbefef0 0000000000000001 0000000000000000 0000000000000000
    0000000077D6B69A BackgroundThreadStart+530 00000000404e6320 0000000000000000 0000000000000000 000000003fbeffa8
    ---------------- End of Call Stack Trace -----------------
    Call stack acquisition performance stats:
    setup time (lock acquis., memory alloc.): 4516 ms
    frame get time (time the target proc was suspended): 156 ms
    symbol translation time: 891 ms
    total time: 5563 ms
    *** 2007-02-27 17:12:03.171
    *** 2007-02-27 17:16:40.765
    Waited for process J000 to initialize for 60 seconds
    *** 2007-02-27 17:16:40.765
    Dumping diagnostic information for J000:
    OS tid = 5420
    Memory (Avail/Total): Ph:8192M/16379M, Ph+PgF:9182M/17250M
    ------------------- Call Stack Trace ---------------------
    calling location entry point arg #1 arg #2 arg #3 arg #4
    0000000078EF12AA 0000000000000000 0000000000000000 0000000000000000 000000000df50080 0000000000000000
    0000000077D7047F 0000000078EF12AA 0000000200000000 0000a531fe24a2cd 0000a531fe24a2cd 0000000000000121
    skgpwwait+145 0000000077D7047F 00000000000060d4 0000000000000000 0000000000000000 0000000000000000
    kslgess+1652 skgpwwait+145 0000000055dec570 00000001b0704c08 0000000055dee978 0000000055dee978
    kslgetsl+907 kslgess+1652 000000020e58ddb0 000000020e58ddf0 0000000000000003 00000000004995b4
    kswsgsnp+257 kslgetsl+907 0000000000000000 0000000000010000 0000000009001100 0000000004ef0e61
    ksucre+473 kswsgsnp+257 6c6361726f5c3a45 6375646f72705c65 302e322e30315c74 6c6e5c315f62645c
    kkjrdp+708 ksucre+473 0000000000000000 000000001ca3f030 000000001ca406f0 00000000000000b9
    opirip+1216 kkjrdp+708 30315c740000001e 0000000003a782e8 000000020e58fa70 0000000000000000
    opidrv+860 opirip+1216 0000000000000032 0000000000000004 000000020e58fda0 0000000000000000
    sou2o+52 opidrv+860 0000000000000032 0000000000000004 000000020e58fda0 00000000066cfa22
    opimai_real+272 sou2o+52 0000000000000000 000000001ca20000 00000000000060d4 0000000000000000
    opimai+96 opimai_real+272 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    BackgroundThreadStart+530 opimai+96 000000020e58fef0 0000000000000001 0000000000000000 0000000000000000
    0000000077D6B69A BackgroundThreadStart+530 00000000245755c0 0000000000000000 0000000000000000 000000020e58ffa8
    ---------------- End of Call Stack Trace -----------------
    Call stack acquisition performance stats:
    setup time (lock acquis., memory alloc.): 2969 ms
    frame get time (time the target proc was suspended): 16 ms
    symbol translation time: 0 ms
    total time: 2985 ms
    *** 2007-02-27 17:16:49.765

  • Data Pump Error - ORA-04063: package body "SYS.DBMS_INTERNAL_LOGSTDBY" has

    Hi All,
    I am getting the following errors when I am trying to connect with datapump.My db is 10g and os is linux.
    Connected to: Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production
    With the Partitioning, OLAP and Data Mining options
    ORA-31626: job does not exist
    ORA-04063: package body "SYS.DBMS_INTERNAL_LOGSTDBY" has errors
    ORA-06508: PL/SQL: could not find program unit being called
    ORA-06512: at "SYS.DBMS_LOGSTDBY", line 24
    ORA-06512: at "SYS.KUPV$FT", line 676
    ORA-04063: package body "SYS.DBMS_INTERNAL_LOGSTDBY" has errors
    ORA-06508: PL/SQL: could not find program unit being called
    When I tried to compile this package I am getting the following error
    SQL> alter package DBMS_INTERNAL_LOGSTDBY compile body;
    Warning: Package Body altered with compilation errors.
    SQL> show error
    Errors for PACKAGE BODY DBMS_INTERNAL_LOGSTDBY:
    LINE/COL ERROR
    1405/4 PL/SQL: SQL Statement ignored
    1412/38 PL/SQL: ORA-00904: "SQLTEXT": invalid identifier
    1486/4 PL/SQL: SQL Statement ignored
    1564/7 PL/SQL: ORA-00904: "DBID": invalid identifier
    1751/2 PL/SQL: SQL Statement ignored
    1870/7 PL/SQL: ORA-00904: "DBID": invalid identifier
    Can anyony suggest/guide me how to resolve the issue.
    Thanks in advance

    SQL> SELECT OBJECT_TYPE,OBJECT_NAME FROM DBA_OBJECTS
    2 WHERE OWNER='SYS' AND STATUS<>'VALID';
    OBJECT_TYPE OBJECT_NAME
    VIEW DBA_COMMON_AUDIT_TRAIL
    PACKAGE BODY DBMS_INTERNAL_LOGSTDBY
    PACKAGE BODY DBMS_REGISTRY_SYS
    Thanks

  • PL/SQL report errors: ORA-01422

    Hi all,
    (before i you read i would like to say i have searched the net for this error code but nothing shows up like this problem..)
    I am getting an error problem when i select certain Schemas from a list on an apex app. page, it only works for some schemas not all..
    When i select one schema, it is supposed to display one row.. when i select [ALL] it is supposed to show them all.
    It does work if i select '[ALL]' from the select list (p3_schema_name), just not for every single individual one.
    the error code:
    ORA-01422: exact fetch returns more than requested number of rows
    declare
      vSchema  varchar2(20);
      vStmt  varchar2(1000);
      vVersion number(5);
      vDBName  varchar2(20);
      vHostName varchar2(80);
      vStmt2  varchar2(1000);
      vVersion2 number(5);
      vDBName2  varchar2(20);
      vServer2 varchar2(80);
      vSchema2 varchar2(80);
      CURSOR c_schemas IS
        select owner from dba_tables@P3_DB_NAME.db_link where table_name = 'DDL_LOG' and num_rows > 0 order by owner;
    begin
      IF :P3_SCHEMA_NAME != '[ALL]' AND :P3_DB_NAME IS NOT NULL AND :P3_SERVER_NAME IS NOT NULL THEN
        vServer2 := :P3_SERVER_NAME;
        vSchema2 := :P3_SCHEMA_NAME;
          vStmt2 := 'select distinct DDH_DB_NM, max(DDH_SCHEMA_NR)keep(dense_rank last order by ddh_runstart_td) AS "PATCH" from &P3_SCHEMA_NAME..ddl_log@&P3_DB_NAME.db_link GROUP BY DDH_DB_NM';
          Execute Immediate vStmt2 into vDBName2, vVersion2;
            htp.p('<br>');
            htp.p('<table border="1">');
            htp.p('<tr>');
            htp.p('<th bgcolor="#FFCC99">SERVER NAME</th>');
            htp.p('<th bgcolor="#FFCC99">DB NAME</th>');
            htp.p('<th bgcolor="#FFCC99">SCHEMA NAME</th>');
            htp.p('<th bgcolor="#FFCC99">PATCH</th>');
            htp.p('</tr>');
            htp.p('<tr>');
            htp.p('<td>');
            htp.p(vServer2);
            htp.p('</td>');
            htp.p('<td>');
            htp.p(vDBName2);
            htp.p('</td>');
            htp.p('<td>');
            htp.p(vSchema2);
            htp.p('</td>');
            htp.p('<td>');
            htp.p(vVersion2);
            htp.p('</td>');
            htp.p('<td>');
            htp.p('<BR>');
            htp.p('</td>');
            htp.p('</tr>');
            htp.p('</tr>');
            htp.p('</table>');
       ELSE IF :P3_SCHEMA_NAME = '[ALL]' AND :P3_DB_NAME IS NOT NULL AND :P3_SERVER_NAME IS NOT NULL THEN
       vHostName := :P3_SERVER_NAME;
       vDBName := :P3_DB_NAME;
         open c_schemas;
          htp.p('<br>');
          htp.p('<table border="1">');
          htp.p('<tr>');
          htp.p('<th bgcolor="#FFCC99">SERVER NAME</th>');
          htp.p('<th bgcolor="#FFCC99">DB NAME</th>');
          htp.p('<th bgcolor="#FFCC99">SCHEMA NAME</th>');
          htp.p('<th bgcolor="#FFCC99">PATCH</th>');
          htp.p('</tr>');
        LOOP
          FETCH c_schemas INTO vSchema;
          EXIT WHEN c_schemas%NOTFOUND;
          vStmt  := 'select max(DDH_SCHEMA_NR)keep(dense_rank last order by ddh_runstart_td) AS "PATCH" from '||vSchema||'.ddl_log@&P3_DB_NAME.db_link where DDH_SCHEMA_NR = (select max(DDH_SCHEMA_NR) from '||vSchema||'.ddl_log@&P3_DB_NAME.db_link) and rownum < 2' ;
          Execute Immediate vStmt into vVersion  ;
          htp.p('<tr>');
          htp.p('<td>');
          htp.p(vHostName);
          htp.p('</td>');
          htp.p('<td>');
          htp.p(vDBName);
          htp.p('</td>');
          htp.p('<td>');
          htp.p(vSchema);
          htp.p('</td>');
          htp.p('<td>');
          htp.p(vVersion);
          htp.p('</td>');
          htp.p('<td>');
          htp.p('<BR>');
          htp.p('</td>');
          htp.p('</tr>');
        END LOOP;
          htp.p('</tr>');
          htp.p('</table>');  
      CLOSE c_schemas;
    END IF;
    END IF;
    END;I have checked the DDH_SCHEMA_NR for repeating entries of the highest number.. some of the ones that dont work do have repeating entries some don't.
    Sorry if this is confusing, i have tried to explain it as best as i can.
    Thanks in advance for any help.
    Ashleigh

    Hello Ashleigh,
    Based on your code, I'd start by running this piece of SQL via command-line (thru SQL Workshop, SQL*Plus, Toad, etc.), replacing &P3_SCHEMA_NAME. and &P3_DB_NAME. with values that are currently causing the routine to fail and see if it returns more than one row. I don't know your data, but DISTINCT and GROUP BY are typically used to return multiple (though grouped/summarized) rows. It appears to be the only statement that would cause the error your seeing (more than one row being returned into single variables).
    select distinct DDH_DB_NM, max(DDH_SCHEMA_NR)keep(dense_rank last order by ddh_runstart_td) AS "PATCH" from &P3_SCHEMA_NAME..ddl_log@&P3_DB_NAME.db_link GROUP BY DDH_DB_NM;I'm actually surprised that the code runs at all. I didn't think 'execute immediate' would know what to do with substitutions indicated as "&something." (I've typically seen that when substituting in dynamic HTML/Javascript code but maybe I'm learning something new). But since you already have vServer2 and vSchema2, I'd be more apt to code it as:
    vStmt2 := 'select distinct DDH_DB_NM, max(DDH_SCHEMA_NR)keep(dense_rank last order by ddh_runstart_td) AS "PATCH" from ' ||
    vSchema2 || '.ddl_log@' || vServer2 || '.db_link GROUP BY DDH_DB_NM';Hope this helps,
    John

  • Ora-00604 error and ora 01000 error while report generation.

    hi all,
    I am trying to generate the multiple reports of same template through a program.
    While this job is running, i get the following error at the BIP console and the reports don't get generated.
    [101711_044115578][][EXCEPTION] java.sql.SQLException: ORA-00604: error occurred
    at recursive SQL level 1
    ORA-01000: maximum open cursors exceeded
    ORA-00604: error occurred at recursive SQL level 1
    ORA-01000: maximum open cursors exceeded
    ORA-01000: maximum open cursors exceeded
    Kindly help.
    Thanks.

    Lots of resources with a simple search to see what this is about, for example:
    http://www.orafaq.com/wiki/ORA-01000
    ORA-01000:     maximum open cursors exceeded
    Cause:     A host language program attempted to open too many cursors. The initialization parameter OPEN_CURSORS determines the maximum number of cursors per user.
    Action:     Modify the program to use fewer cursors. If this error occurs often, shut down Oracle, increase the value of OPEN_CURSORS, and then restart Oracle.
    open_cursors parameter
    http://download.oracle.com/docs/cd/E11882_01/server.112/e25513/initparams160.htm#REFRN10137
    Oracle support note:
    OERR: ORA-1000 maximum open cursors exceeded (Doc ID 18591.1)

Maybe you are looking for