Exec sql Execute in Pro*C

Hi,
My ProC code works fine when I have Exec sql in it but when I include plsql block in it using EXEC SQL EXECUTE, it throws the following error:
/tmp/cc88UGZa.o(.text+0x2c0): In function `main':
: undefined reference to `ECPGget_sqlca'
I have included all these below header files:
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <sqlca.h>
#include <sqlda.h>
#include <sqlcpr.h>
and the path have been mentioned in pcscfg.cfg as well.
what can be the reason and the solution to this please? Help is appreciated.
Thanks in advance!
Ash

You have to use 'BEGIN procedure_name END' in the execute statement while calling PL/SQL Procedures
EXEC SQL EXECUTE
DECLARE
BEGIN
END;
END-EXEC;

Similar Messages

  • EXEC SQL / EXECUTE PROCEDURE

    Hi,
    I´ve been asked to develop a program that should be run in background as a job.
    The aim of this program is to select certain data from SAP an then pass it to a DB (sql) outside SAP so that this DB always gets the most updated data.
    I´ve already set up an entry in table
    DBCON.
    My problem is that when I change the DB name in table DBCON the program does not work because it always “remembers” the former entry, that is, it re-uses the stored procedure already used in the former execution of the program. 
    Here goes the code:
      EXEC SQL.
        SET CONNECTION DEFAULT
      ENDEXEC.
      EXEC SQL.
        CONNECT TO 'TOMAS3' AS 'con'
      ENDEXEC.
      EXEC SQL.
        SET CONNECTION 'con'
      ENDEXEC.
      LOOP AT ti_vbap INTO wa_vbap.
        CLEAR: wa_itab, g_input.
        wa_itab-sapOrdID  = wa_vbap-vbeln.
        …………… etc
        CONCATENATE
                    wa_itab-sapOrdID
                    wa_itab-CopPos
                    wa_itab-isbn
                    wa_itab-isbnOLD
                    wa_itab-sta
                    wa_itab-dat
                    wa_itab-pte
                    wa_itab-snu INTO g_input.
    call to the stored procedure that updates the external DB
            EXEC SQL.
              EXECUTE PROCEDURE RefrescaCOPdeSAP_JOBSAP2 ( IN :g_input )
            ENDEXEC.
      ENDLOOP.
    *Close connection to external DB
      EXEC SQL.
        DISCONNECT 'con'
      ENDEXEC.
    Is there an statement like BEGIN TRANS… / COMMIT that is missing?
    Have you got an example so that I may have an idea of how to deal with this situation?.
    Best regards.

    Hi,
    i think i´ve found out where the problem is.
    In table
    DBCON i´ve got the following entry:
    MSSQL_SERVER=1XX.X0.X.X2 MSSQL_DBNAME=ESPAÑA
    it seems as if the character 'Ñ' causes the connection to fail.
    i´ve tried to connect to another DB where MSSQL_DBNAME=ESPANA (coy of the former one) and there was no problem.
    could it be that the character 'Ñ' is the cause of the problem?.Best regards.

  • Enbedding PL/SQL function in Pro Cobol

    HI,
    I am trying to compile an existing pro cobol program because of a small enhancement. I am trying to embed a pl/sql function in to the program..and the compiler is throwing errors.Can someone please tell me what i am doing wrong? Please look at the piece of code that i added to the existing program.I have set the Oracle option sqlcheck = semantic...
    exec sql execute
    BEGIN
    finddatatype(:ws-destination-tbl1,
    :ws-destination-tbl-col-1,
    :ws-data-type);
    END;
    end-exec
    null

    It's been a while since I used Pro*C but I think sqlcheck should be set to FULL not SEMANTICS for embedded PL/SQL.
    Maybe this is the same for Pro*Cobol?

  • Call to package not being executed in Pro*C

    Hello!
    We are doing a machine migration from a Sequent Computer System (DYNIX/ptx(R) V4.4.8) to an HP-UX B.11.11 U 9000/800; and from the Oracle version 8.1.7.3.0 to 8.1.7.4.0.
    And we are having some problems, which we did not found a valid solution yet.
    I have a call to a function of a package that inst being (strangely) executed. The only clue I have is that the variable OS_CREATE_ID is the cause of the problem (after some tests), although it has a valid value ('MSI-PROC') on it, passed correctly to it using another variable that gets it value from a cursor fetch.
    If I put the value of the referred variable OS_CREATE_ID ('MSI-PROC', in the call to the package (i.e. hard coded), then the package is called and executed correctly. If the variable stays in the call then the PL/SQL block isn't even executed.
    I also tried to initialise the variable os_create_id or/and copy it to another local (similar) variable and nothing seems to works.
    One solution is to keep the hard coded value in the call to the package but, I guess this problem can appear in other Proc*s with
    similar situations.
    Does anybody have any idea/clue to solve this problem, or experienced a similar situation ?
    There a very close situation like this one but involved VARHCAR variables which isn't the current case, in which the solution was to initialise the variables of this type.
    Here is an extract of the code:
    /* Here is the variables declaration: */
    char os_tsfalloc_no[NULL_TSFALLOC_NO];
    EXEC SQL VAR os_tsfalloc_no IS STRING(NULL_TSFALLOC_NO);
    char os_tsf_no[NULL_TSF_NO];
    EXEC SQL VAR os_tsf_no IS STRING(NULL_TSF_NO);
    char os_sku[NULL_SKU];
    EXEC SQL VAR os_sku IS STRING(NULL_SKU);
    char os_from_loc[NULL_LOC];
    EXEC SQL VAR os_from_loc IS STRING(NULL_LOC);
    char os_to_loc[NULL_LOC];
    EXEC SQL VAR os_to_loc IS STRING(NULL_LOC);
    char os_create_id[NULL_CREATE_ID];
    EXEC SQL VAR os_create_id IS STRING(NULL_CREATE_ID);
    EXEC SQL EXECUTE
    DECLARE
    L_table VARCHAR(50) := NULL;
    L_sub_sku WIN_WH.sku%TYPE := NULL;
    L_avail_stock WIN_WH.STOCK_ON_HAND%TYPE := NULL;
    O_error_message VARCHAR2(255) := NULL;
    BEGIN
    if NB_SUB_SKU.NB_F_GET_SUB_SKU(:os_sku,
    :os_from_loc,
    :os_to_loc,
    :os_tsf_no,
    :os_tsfalloc_no,
    :ls_create_id,
    to_date(:os_system_date,'YYYYMMDDHH24MISS'),
    L_sub_sku,
    L_avail_stock,
    O_error_message) = FALSE then
    :plsql_pkg_failed := -1;
    :plsql_pkg_message := O_error_message;
    SQL_LIB.BATCH_MSG(:ol_sql_holder,
    L_table,
    :plsql_pkg_message);
    :table := L_table;
    else
    (...)

    Hello!
    I found out that the problem was not in the variable os_create_id as I described before, instead in the another variable, l_temp_sku.
    But a strange behaviour persists.
    The program aborts strangely, if the following variable l_temp_sku isn't initialised like this:
    l_temp_sku[0] = '\0'; (if this is done the pro*c runs ok)
    This variable gets it value from a Output variable of the package called, and these have the same length, as you can see above.
    In the old machine (version 8.1.3.0 as already mentioned) it worked fine without initialisation.
    The (strings) precompiler options are the following:
    dbms=v8
    char_map=string (We already tried to change this to VARCHAR2)
    My questions are:
    Is this a normal behaviour or is this a non documented feature (bug) ?
    Is there any precompiler option that solves this kind of problems ?
    We have lots of Pro*C´s with situations like this one, our problem is if all these programs start to blow without warning. Only after lots of time spent around this Pro*C we found where was the problem, and what kind of problem.
    /* Code Extract: */
    char ls_error_msg[NULL_ERROR];
    EXEC SQL VAR ls_error_msg IS STRING(NULL_ERROR);
    char l_temp_sku[NULL_SKU];
    EXEC SQL VAR l_temp_sku IS STRING(NULL_SKU);
    EXEC SQL EXECUTE
    DECLARE
    L_table VARCHAR(50) := NULL;
    L_sub_sku WIN_WH.sku%TYPE := NULL;
    L_avail_stock WIN_WH.STOCK_ON_HAND%TYPE := NULL;
    O_error_message VARCHAR2(255) := NULL;
    BEGIN
    if NB_SUB_SKU_SQL.NB_F_CHECK_SUB_SKU(:os_sku,
    :os_from_loc,
    :os_to_loc,
    :os_tsf_no,
    :os_tsfalloc_no,
    :os_create_id,
    to_date(:os_system_date,'YYYYMMDDHH24MISS'),
    L_sub_sku,
    L_avail_stock,
    O_error_message) = FALSE then
    :plsql_pkg_failed := -1;
    :plsql_pkg_message := O_error_message;
    SQL_LIB.BATCH_MSG(:ol_sql_holder,
    L_table,
    :plsql_pkg_message);
    :table := L_table;
    else
    /* Only if ret true and the sub sku, everything its ok */
    if L_sub_sku IS NOT NULL then
    :l_temp_sku := L_sub_sku;
    :plsql_pkg_failed := 0;
    Best Regards,
    JAP

  • BUG?? Exeption handling brakes a Loop?! (PL/SQL executed by C) Anybody know this ????

    (OS - SCO, Oracle 817, Pro*C/C++: Release 2.2.4.0.0)
    In C program I have a PL/SQL block with WHILE LOOP. Inside the loop I have SELECT statement with a begin..end arroung it and with EXCEPTION WHEN NO_DATA_FOUND for internal block. In this exception I have no RAISE statement. So, I expect the loop will be not broken by NO_DATA_FOUND error.
    After control comes to the EXCEPTION NO_DATA_FOUND the loop is not continue anymore (but error is not populated out of this begin..end.) If EXCEPTION NO_DATA_FOUND is commented by -- the loop runs completely.
    Is it known bug? Does anybody get something like this?
    To be more specific, my EXEC SQL EXECUTE .. END EXECUTE block looks like this:
    DECLARE
    BEGIN
    WHILE .. LOOP
    begin SELECT ...
    exception when NO_DATA_FOUND then NULL;
    when others then ... RAISE;
    end;
    END LOOP;
    END;
    Would appreciate any response on this matter.
    Thanks!
    Alex.

    Call the procedure from another "wrapper" procedure. In the wrapper, place the call within to your existing procedure in a
    for i in 1..3 loop
      call procedure;
      if <successful condition> then
        exit loop;
      end if;
    end loop;I think that'd be easier than trying to work on controlling everything from within a single procedure. You could even set up a PACKAGE where the wrapper was the only public procedure, where your current procedure is private, and thus, can't be called outside of the wrapper, by accident. --=cf

  • Pl/sql compile in pro*c

    [oracle@Robbie replicate]$ make -f demo_proc.mk tt.c
    proc iname=tt
    Pro*C/C++: Release 8.1.7.0.0 - Production on Fri Aug 29 10:40:08 2003
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    System default option values taken from: /oracle/product/8.1.7/precomp/admin/pcscfg.cfg
    Error at line 28, column 1 in file tt.pc
    PCC-S-02022, Found end of file while scanning a SQL statement
    Error at line 0, column 0 in file tt.pc
    PCC-F-02102, Fatal error while doing C preprocessing
    make: *** [tt.c] Error 1
    #include<stdio.h>
    EXEC SQL BEGIN DECLARE SECTION;
    char username[20];
    char password[20];
    EXEC SQL END DECLARE SECTION;
    EXEC SQL INCLUDE sqlca;
    void sqlerror();
    void main()
    strcpy(username,"system");
    strcpy(password,"manager");
    EXEC SQL CONNECT :username IDENTIFIED BY :password;
    EXEC SQL WHENEVER SQLERROR DO sqlerror();
    EXEC SQL EXECUTE
    BEGIN
    select * from red7;
    END;
    END_EXEC;
    void sqlerror()
    EXEC SQL WHENEVER SQLERROR CONTINUE;
    EXEC SQL ROLLBACK WORK RELEASE;
    printf("\n Oracle error detected:\n");
    printf("\n%.70s\n",sqlca.sqlerrm.sqlerrmc);
    EXEC SQL ROLLBACK RELEASE;
    thanks

    the topic i posted is wrong. the correct as follow:
    tt.pc
    #include<stdio.h>
    EXEC SQL BEGIN DECLARE SECTION;
    char username[20];
    char password[20];
    EXEC SQL END DECLARE SECTION;
    EXEC SQL INCLUDE sqlca;
    void sqlerror();
    void main()
    strcpy(username,"system");
    strcpy(password,"manager");
    EXEC SQL CONNECT :username IDENTIFIED BY :password;
    EXEC SQL WHENEVER SQLERROR DO sqlerror();
    EXEC SQL EXECUTE
    BEGIN
    select * from red7;
    END;
    END-EXEC;
    void sqlerror()
    EXEC SQL WHENEVER SQLERROR CONTINUE;
    EXEC SQL ROLLBACK WORK RELEASE;
    printf("\n Oracle error detected:\n");
    printf("\n%.70s\n",sqlca.sqlerrm.sqlerrmc);
    EXEC SQL ROLLBACK RELEASE;
    [oracle@Robbie replicate]$ make -f demo_proc.mk tt.c
    proc iname=tt
    Pro*C/C++: Release 8.1.7.0.0 - Production on Fri Aug 29 10:59:50 2003
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    System default option values taken from: /oracle/product/8.1.7/precomp/admin/pcscfg.cfg
    Error at line 16, column 21 in file tt.pc
    select * from red7;
    ....................1
    PLS-S-00201, identifier 'RED7' must be declared
    Error at line 16, column 3 in file tt.pc
    select * from red7;
    ..1
    PLS-S-00000, SQL Statement ignored
    Semantic error at line 15, column 2, file tt.pc:
    BEGIN
    .1
    PCC-S-02346, PL/SQL found semantic errors
    make: *** [tt.c] Error 1

  • EXEC SQL with IN Clause

    Hello,
    I'm trying to run an EXEC SQL statement with an IN clause.  Here's my SQL code:
    EXEC SQL.
          OPEN C FOR
          SELECT name
                 FROM sv_hoover_data
                 where dunsNum in :DUNS_NUMBERS
        ENDEXEC.
    My DUNS_NUMBERS variable is of type String and contains the following data:
    ('12334223','4353434','54674563')
    When the statement is executed, I receive the following error message in SM21:
    Line 1: Incorrect syntax near '@P1'.
    Also, the underlying database is MS SQL Server.  When I run the query via MS Query Ananlyzer, it runs fine.
    Does any know if EXEC SQL can handle IN clauses, and if so, how they're written?
    Thanks,
    Matt

    I haven't used it myself (yet), but this is what I found in the help:
    EXEC SQL - EXECUTE
    Syntax
    EXEC SQL.
      EXECUTE PROCEDURE proc ( IN    p_in1    IN    p_in2 ...,
                               OUT   p_out1   OUT   p_out2 ...,
                               INOUT p_inout1 INOUT p_inout2 ... )
    ENDEXEC.
    Effect
    In database systems, you can define procedures as so-called "stored procedures". Since the syntax for calling such procedures and the pertinent parameter transfer for various database systems can vary widely, a uniform command exists in Native SQL.
    The statement EXECUTE PROCEDURE calls a procedure proc stored in the database. For all formal parameters of the procedure, you must specify the actual parameters, separated by commas. You must specify IN, OUT or INOUT before every actual parameter, in order to indicate whether the parameter is an input, output, or input/output parameter. You can use literals or Host Variables labeled by a colon(:)for the actual parameters.
    Example
    This example defines a selfunc procedure using database specific SQL-Statements (Informix). It also calls the procedure using the SAP-specific Native-SQL-Statement EXECUTE PROCEDURE in a LOOP-loop by means of a Selection Table, and deletes the the procedure using an SQL-Statement. In the case shown here, the procedure is a function whose return value output in EXECUTE PROCEDURE is copied to the host variable name.
    DATA scarr_carrid TYPE scarr-carrid.
    SELECT-OPTIONS s_carrid FOR scarr_carrid NO INTERVALS.
    DATA s_carrid_wa LIKE LINE OF s_carrid.
    DATA name TYPE c LENGTH 20.
    TRY.
        EXEC SQL.
          CREATE FUNCTION selfunc( input CHAR(3) )
            RETURNING char(20);
            DEFINE output char(20);
            SELECT carrname
                   INTO output
                   FROM scarr
                   WHERE mandt  = '000' AND
                         carrid = input;
            RETURN output;
            END FUNCTION;
        ENDEXEC.
        LOOP AT s_carrid INTO s_carrid_wa
                         WHERE sign = 'I' AND option = 'EQ'.
          TRY.
             EXEC SQL.
                EXECUTE PROCEDURE selfunc( IN  :s_carrid_wa-low,
                                           OUT :name )
              ENDEXEC.
              WRITE: / s_carrid_wa-low, name.
            CATCH cx_sy_native_sql_error.
              MESSAGE `Error in procedure execution` TYPE 'I'.
          ENDTRY.
        ENDLOOP.
        EXEC SQL.
          DROP FUNCTION selfunc;
        ENDEXEC.
      CATCH cx_sy_native_sql_error.
        MESSAGE `Error in procedure handling` TYPE 'I'.
    ENDTRY.

  • Memory Allocated using EXEC SQL VAR in ProC

    For a table that stores resumes, I have a ProC program which outputs LONG column values into a host variable. Here is the table definition:
         create table resume (resume_id number(5),
                   resume_size number(15),
                   resume_text LONG)
    The size of the resume_text can be vary from 0 bytes up to 90K bytes. We use the column "resume_size" to store the size of the resume_text in bytes. Since most of them are smaller than 8K, we don't want to allocate 90K memory for every resume SELECT call. Before we do the SELECT on the resume_text, a host variable pointer is used to allocate memory according to the size of the resume_text:     
         char *resume_buffer;
    len = get_resume_size(id); /* A SELECT statement to fetch the resume_size for this resume from the table */               
         resume_buffer = malloc(len); /* Allocate memory for the resume according to the resume_size. For example, len could be 6000 */
         EXEC SQL VAR resume_buffer IS LONG (100000);      /* without using a constant number will lead to a compiler error */
         EXEC SQL SELECT resume_text INTO :resume_buffer FROM resume WHERE resume_id = :id;
    Is 100000" the size actually allocated in memory (either OS level or Oracle data buffer cache) every time it runs or is it just the maximum possible size needed to satisfy the precompiler?
    Any help greatly appreciated.

    You have to use 'BEGIN procedure_name END' in the execute statement while calling PL/SQL Procedures
    EXEC SQL EXECUTE
    DECLARE
    BEGIN
    END;
    END-EXEC;

  • EXEC SQL FAILS

    Hi,
    I am having 2 SQL blocks which calls the function HPS_SELECT_PIN_NB and INC_PIN_ERROR_NUMBER in oracle . Now the problem is that in the function inc_pin_error_number () .I see the trace event
    trace_event("Debut inc_pin_error_number()", PROCESSING);
    but i am NOT able to execute the EXEC SQL EXECUTE statement ( I guess that the control is not going in this EXEC statement ) , but when i call this same function (HPS_INC_PIN_NB) from the function load_pin_error_number it works .
    Please have a look at the two functions below and suggest as to why the functions is NOT being called from inc_pin_error_number .
    BLOCK 1
    int load_pin_error_number (V_card_number,
    V_pin_verification_number)
    char *V_card_number;
    int *V_pin_verification_number;
    EXEC SQL BEGIN DECLARE SECTION;
    int response_code;
    VARCHAR T_card_number[22];
    int T_pin_verification_number;
    VARCHAR ERREUR[256];
    EXEC SQL END DECLARE SECTION;
    char buffer[LG_MAX];
    trace_event("Debut load_pin_error_number()", PROCESSING);
    memset(T_card_number.arr, 0, sizeof(T_card_number.arr));
    memcpy(T_card_number.arr, V_card_number, strlen(V_card_number));
    T_card_number.len = strlen(V_card_number);
    response_code =999;
    EXEC SQL EXECUTE
    BEGIN
    :response_code:= HPS_SELECT_PIN_NB (:T_card_number,
    :T_pin_verification_number);
    EXCEPTION
    WHEN OTHERS THEN BEGIN
    :response_code :=-2;
    :ERREUR := SQLERRM;
    END;
    END;
    END-EXEC;
    if (response_code == -2)
    memset(buffer, 0, sizeof(buffer));
    sprintf(buffer,"GET PIN ERROR ERROR : %s\n", ERREUR.arr);
    trace_event(buffer, ERROR);
    *V_pin_verification_number = T_pin_verification_number;
    sprintf(buffer,"V_pin_verification_number %d\n", V_pin_verification_number);
    trace_event(buffer,V_pin_verification_number);
    trace_event("Fin load_pin_error_number()", PROCESSING);
    sprintf(buffer,"Response_code %d\n", response_code);
    trace_event(buffer,response_code);
    return(response_code);
    BLOCK 2
    int inc_pin_error_number (V_card_number)
    char *V_card_number;
    EXEC SQL BEGIN DECLARE SECTION;
    int response_code;
    VARCHAR T_card_number[22];
    VARCHAR ERREUR[256];
    EXEC SQL END DECLARE SECTION;
    char buffer[LG_MAX];
    trace_event("Debut inc_pin_error_number()", PROCESSING);
    memset(T_card_number.arr, 0, sizeof(T_card_number.arr));
    memcpy(T_card_number.arr, V_card_number, strlen(V_card_number));
    T_card_number.len = strlen(V_card_number);
    response_code =-1;
    EXEC SQL EXECUTE
    BEGIN
    :response_code:= HPS_INC_PIN_NB (:T_card_number);
    EXCEPTION
    WHEN OTHERS THEN BEGIN
    :response_code :=-2;
    :ERREUR := SQLERRM;
    END;
    END;
    END-EXEC;
    if (response_code == -2)
    memset(buffer, 0, sizeof(buffer));
    sprintf(buffer,"INC PIN ERROR ERROR : %s\n", ERREUR.arr);
    trace_event(buffer, ERROR);
    trace_event("Fin inc_pin_error_number()", PROCESSING);
    return(response_code);
    Regards
    Dhananjay Javalkar
    null

    Perhaps you can trap (profile) the query in Oracle to see what it gets submitted,
    thing is this query
    select id from table where ProcessedStatusColumn is null and DateColumn = (sub select to get most recent date in table where ProcessedStatusColumn is null)
    is not guaranteed to return a value, you need a default returned in case the search failed e.g.
    select
    NVL(id, 0)
    from table where ProcessedStatusColumn is null and DateColumn =
    (sub select to get most recent date in table where
    ProcessedStatusColumn is null)
    Arthur My Blog

  • Pro*C with Visual C++ - leaks memory with EXEC SQL CONTEXT FREE

    Hello,
    I am making an aplication with threads, using Visual C++ with Pro*C... and I have a problem when the aplication execute EXEC SQL CONTEXT FREE the memory reserved is not free.
    this is my code:
    #include <sqlca.h>
    EXEC SQL BEGIN DECLARE SECTION;
    sql_context ctx;
    EXEC SQL END DECLARE SECTION;
    EXEC SQL ENABLE THREADS;
    EXEC SQL CONTEXT ALLOCATE :ctx;
    EXEC SQL CONTEXT USE :ctx;
    EXEC SQL COMMIT WORK RELEASE;
    EXEC SQL CONTEXT FREE :ctx;
    thanks in advance

    Hi!
    I suppose to helping in solve your question is necessary see how your application is working with threads.
    Can you print them also?

  • SQL error 3113 occurred when executing EXEC SQL.

    Hi,
    We are facing one typical problem, One background is failing regularly with
    below dump. as we now got all notes giving information, if database  restarted
    taking backup, these type of failures occur, but our database is only down for backup once in a week, but it is failing with frequenly.
    in this two servers are located in different place, in this job tries to connect
    another server to get material statistics.
    It is giving some error message in sm21 with
    SQL error 3113 occurred when executing EXEC SQL.
    work procees in reconnect mode.
    all notes saying these types of dump occur when database restared, but this dump
    even though database is up.
    below is short dump, please can anyone help me from this problem.
    ABAP runtime errors    DBIF_DSQL2_SQL_ERROR
          Occurred on    08.01.2007 at 00:30:28
    >> Short dump has not been completely stored. It is too big.
    SQL error 3113 occurred when executing EXEC SQL.
    What happened?
    The error occurred in the current database connection "AZ1".
    What can you do?
    Note the actions and input that caused the error.
    Inform your SAP system administrator.
    You can print out this message by choosing "Print". Transaction ST22
    allows you to display and manage termination messages, including keeping
    them beyond their normal deletion date.
    Error analysis
    How to correct the error
    Database error text........: "ORA-03113: end-of-file on communication channel#"
    Triggering SQL statement...: "select mara.groes, mara.brgew, mara.ntgew,
    mara.gewei, mara.volum, mara.voleh, mara.mstae, mara.mstde, mara.prdha,
    marc.matnr, marc.werks, marc.mmsta, marc.mmstd from sapr3.mara, sapr3.m
    where sapr3.mara.mandt = sapr3.marc.mandt and sapr3.mara.matnr =
    Internal call code.........: "[DBDS/NEW DSQL]"
    Please check the entries in the system log (Transaction SM21).
    If the error occurred in a non-modified SAP program, you may be
    able to find a solution in the SAP note system.
    If you have access to the note system yourself, use the following
    search criteria:
    "DBIF_DSQL2_SQL_ERROR"
    "ZM2431216 " or "ZM2431216 "
    "EXTRACT_GENERAL_DATA"
    If you cannot solve the problem yourself, please send the
    following documents to SAP:
    1. A hard copy print describing the problem.
      To obtain this, select the "Print" function on the current screen.
    2. A suitable hardcopy prinout of the system log.
      To obtain this, call the system log with Transaction SM21
      and select the "Print" function to print out the relevant
      part.
    3. If the programs are your own programs or modified SAP programs,
      supply the source code.
      To do this, you can either use the "PRINT" command in th
      print the programs using the report RSINCL00.
    4. Details regarding the conditions under which the error o
      or which actions and input led to the error.
    System environment
    SAP Release.............. "46C"
    Application server....... "essceu3"
    Network address.......... "172.19.119.198"
    Operating system......... "AIX"
    Release.................. "5.3"
    Hardware type............ "00C7ADBD4C00"
    Database server.......... "ukblx176"
    Database type............ "ORACLE"
    Database name............ "EU3"
    Database owner........... "SAPR3"
    Character set............ "es_ES.ISO8859-1"
    SAP kernel............... "46D"
    Created on............... "Jul 9 2006 20:26:33"
    Created in............... "AIX 1 5 00447C4A4C00"
    Database version......... "OCI_920__OCI_7_API "
    Patch level.............. "2257"
    Patch text............... " "
    Supported environment....
    Database................. "ORACLE 8.0.5.., ORACLE 8.0.6.., ORACLE
    8.1.6.., ORACLE 8.1.7.., ORACLE 9.2.0.., ORACLE 10.2.0.."
    SAP database version..... "46D"
    Operating system......... "AIX 1 4, AIX 2 4, AIX 3 4, AIX 1 5, AIX 2 5, AIX 3
    5, , System build information:,                                      , LCHN :
    841480"
    User, transaction...
    Client.............. 600
    User................ "MPZMMES"
    Language key........ "S"
    Transaction......... " "
    Program............. "ZM2431216 "
    Screen.............. "SAPMSSY0 1000"
    Screen line......... 6
    Information on where termination occurred
    The termination occurred in the ABAP/4 program "ZM2431216 " in
    "EXTRACT_GENERAL_DATA".
    The main program was "ZM2431216 ".
    The termination occurred in line 980
    of the source code of program "ZM2431216 " (when callin
    The program "ZM2431216 " was started as a background jo
    Source code extract
    009500              mara.ntgew,
    009510              mara.gewei,
    009520              mara.volum,
    009530              mara.voleh,
    009540              mara.mstae,
    009550              mara.mstde,
    009560              mara.prdha,
    009570              marc.matnr,
    009580              marc.werks,
    009590              marc.mmsta,
    009600              marc.mmstd
    009610        into :w_ops-groes,
    009620              :w_ops-brgew,
    009630              :w_ops-ntgew,
    009640              :w_ops-gewei,
    009650              :w_ops-volum,
    009660              :w_ops-voleh,
    009670              :w_ops-mstae,
    009680              :w_ops-mstde,
    009690              :w_ops-prdha,
    009700              :w_ops-matnr,
    009710              :w_ops-werks,
    009720              :w_ops-mmsta,
    009730              :w_ops-mmstd
    009740        from sapr3.mara, sapr3.marc
    009750        where sapr3.mara.mandt = sapr3.marc.mandt
    009760          and sapr3.mara.matnr = sapr3.marc.matnr
    009770          and sapr3.mara.mandt = :p_mandt
    009780          and sapr3.mara.matnr = :w_ebs-matnr
    009790          and sapr3.marc.werks = :p_owerks
        >    ENDEXEC.
    009810  endform.                    " extract_general_data
    009820  *&
    009830  *&      Form  append_i_ops
    009840  *&
    009850  *      Appends W_OPS to I_OPS
    009860  *
    009870  form append_i_ops.
    009880    append w_ops to i_ops.
    009890  endform.                    " append_i_ops
    009900  *&
    009910  *&      Form  extract_material_description
    009920  *&
    009930  *      Extracts a Material Description from the remote database an
    009940  *      modifies the current record in I_OPS.
    009950  *
    009960  *        >P_SPRAS  Language Key
    009970  *
    009980  form extract_material_description using    p_spras.
    009990    EXEC sql performing set_langauge.
    Contents of system fields
    SY field contents..................... SY field contents............
    SY-SUBRC 0                            SY-INDEX 0
    SY-TABIX 1                            SY-DBCNT 1
    SY-FDPOS 18                            SY-LSIND 0
    SY-PAGNO 0                            SY-LINNO 1
    SY-COLNO 1
    Chosen variables
    Name.......................... Contents.1........2........3....+..
    W_EBS-PRAT4
                                  2
                                  0
    W_OPS-GROES
                                  22222222222222222222222222222222
                                  00000000000000000000000000000000
    W_OPS-BRGEW                    #######
                                  0000000
                                  000000C
    W_OPS-NTGEW                    #######
                                  0000000
                                  000000C
    regards,
    krishnaiah.

    Hi,
    This is usually a SERVER SIDE DATABASE PROBLEM or SQLNET LISTENER (server side) PROBLEM.  The client side should initially be ignored and instead the server should be investigated. In rare cases, this can be caused by client
    side memory or other resource problem, or a DLL version mismatch, but this is
    unlikely.
    Enlist the assistance of your DBA.  Then reproduce the ORA-3113 error on your
    client application.  Ask your DBA to look at the database side Alert.log and
    trace files and look for ANY activity.  Any activity that coincides with your
    ORA-3113 will be a clue.
    REgards
    Vinod

  • Pro*Cで「EXEC SQL AT」句のエラーについて

    お世話になります。
    Pro*CでのEXEC SQL AT句について、複数ユーザをログインして、ユーザを切り替え(?)しようと
    したとき、記述の仕方によって、エラーになるケースとならないケースとあって、困っています。
    下に示すソースコードの要点を説明しますと、「_select_usr」という関数で操作しようとするユーザを
    切り替えしています。
    この関数を用いて、1回目((1)と示す箇所)は正常に明示出来ますが、2回目((2)と示す箇所)は
    次のエラーメッセージが出ます。
    ORACLE ERROR msg => SQL-02122: データベースへ接続でのOPENまたはPREPAREが無効です。
    そこで、(2)の箇所をコメントにして、(3)で示す箇所の記述を有効、つまり「_select_usr」関数の
    呼び出しを無効にし、EXEC SQL AT句を直に書き込んで実行すると、正常に別のユーザを明示して
    くれます。
    要は、関数を用いて、ユーザの切り替えが出来る様にしたいのですが、正常に実行出来る方法が
    ありましたら、ご教示頂きたく存じます。
    よろしくお願い致します。
    【環境仕様】
    クライアントOS : Windows7 Professional SP1
    Oracle : Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 (Linuxサーバ)
    開発ツール : Microsoft Visual Studio 2005 Version 8.0.50727.42
    Microsoft .NET Framework Version 2.0.50727 SP2
    Microsoft Visual C++ 2005
    Pro*C/C++(PC) : Pro*C/C++: Release 10.2.0.1.0
    【ソースコード】
    #include <stdio.h>
    #include <string.h>
    #include <stdlib.h>
    #include "sqlca.h"
    #include "sqlda.h"
    void* db_error_handler_ptr();
    extern void truncate_blank(char *a);
    static     char *current_dbn;
    static     FILE     *fp;
    static void _connect( char* uid, char* pwd, char* host, char* dbn )
         EXEC SQL CONNECT :uid IDENTIFIED BY :pwd AT :dbn USING :host;
         fprintf(fp, "connect scima[%s] sqlcode[%d]\n", uid, sqlca.sqlcode );
    void _disconnect(char *dbn)
    EXEC SQL WHENEVER SQLERROR CONTINUE;
    EXEC SQL AT :dbn ROLLBACK WORK RELEASE;
         fprintf(fp, "disconnect dbn[%s] sqlcode[%d]\n", dbn, sqlca.sqlcode );
    void ora_sql_error(char *file, int line)
         char buf[512], *all_msg;
         int buf_len, msg_len;
         if (sqlca.sqlcode == -1405) {
              return;
         } else {
              buf_len = sizeof(buf);
              sqlglm(buf, &buf_len, &msg_len);
              buf[msg_len] = '\0';
              fprintf(fp, "ORACLE ERROR msg => %s\n", buf );
    static int selectusr( char* dbn, char* uid )
         int          rtn;
         char     u[56];
         EXEC SQL AT :dbn SELECT USER INTO :u FROM DUAL;
         rtn = 1;
         if (sqlca.sqlcode != 0) {
              if (sqlca.sqlcode == -1012) {
                   rtn = -1;
              ora_sql_error(__FILE__, __LINE__);
         } else {
              rtn = 0;
              truncate_blank(u);
              strcpy( uid, u );
              fprintf(fp, "select scima[%s]\n", uid );
         return( rtn );
    void main()
         char*     uid1="UID1";
         char*     pwd1="PWD1";
         char*     name1="orcl";
         char*     db_name1="DB1";
         char*     uid2="UID2";
         char*     pwd2="PWD2";
         char*     name2="orcl";
         char*     db_name2="DB2";
         char     u[56];
         fp = fopen("***.txt", "w");
         if( !fp ) exit( 1 );
         connect( uid1, pwd1, name1, dbname1 );
         connect( uid2, pwd2, name2, dbname2 );
    /*** (1) ↓ ***/
         if( selectusr( db_name1, u )!=0 ){
              exit( 1 );
         fprintf( fp, "current scima(1) : [%s] \n", u );
    /*** (1) ↑ ***/
    /*** (2) ↓ ***/
         if( selectusr( db_name2, u )!=0 ){
              exit( 1 );
         fprintf( fp, "current scima(2) : [%s] \n", u );
    /*** (2) ↑ ***/
    /*** (3) ↓ ***/
         EXEC SQL AT :db_name2 SELECT USER INTO :u FROM DUAL;
         if (sqlca.sqlcode != 0) {
              if (sqlca.sqlcode == -1012) {
              ora_sql_error(__FILE__, __LINE__);
              exit( 1 );
         } else {
              truncate_blank(u);
              fprintf( fp, "current scima(3) : [%s] \n", u );
    /*** (3) ↑ ***/
         disconnect(dbname1);
         disconnect(dbname2);
         if(fp) fclose(fp);
    }

    Matsuoka様
    ご教示有難うございました。
    コンテキストの方法でやってみようかと思ったところ、社の者が、プリコンパイラのオプションhold_cursorを「yes」にしていたのを「no」に切り替えたら、出来たんだそうです。とりあえず、それでやってみますが、何か問題あれば、コンテキストの方法でやってみたいと思います。
    有難うございました。

  • Getting core dump when using EXEC SQL CLOSE

    In my pro*c program , i have used a cursor to fetch the set of accounts.Once cursor is opened , code will perform set
    of operation using fetched data and then cursor is closed. Between open and closing of cursor , i have used 23 EXEC
    SQL CLOSE. For example i am copying the value of a to b using strlcpy between fetch and close cursor statement.If
    returned value from strlcpy is greater than size of destination variable, then flow should not proceed , in that case I will
    close the cursor using EXEC SQL CLOSE and return the flow to calling program. Similarly i have closed the cursor at
    another 22 locations.
    When i compile the code and run binary the core dump occurs. On analyzing the core it shows
    t@null (l@8) terminated by signal SEGV (no mapping at the fault address)
    0xffffffffffffffff: <bad address 0xffffffffffffffff>
    dbx: core file read error: address 0xfc4ffe48 not in data space
    Current function is dbMtBaseClass::Pswd_Change
    7860 sqlcxt(&_dbMtCtx, &sqlctx, &sqlstm, &sqlfpn);
    if I remove any of the three EXEC SQL CLOSE commands , core dump does not occurs.
    It looks strange.Please help me to resolve the issue.

    In my pro*c program , i have used a cursor to fetch the set of accounts.Once cursor is opened , code will perform set
    of operation using fetched data and then cursor is closed. Between open and closing of cursor , i have used 23 EXEC
    SQL CLOSE. For example i am copying the value of a to b using strlcpy between fetch and close cursor statement.If
    returned value from strlcpy is greater than size of destination variable, then flow should not proceed , in that case I will
    close the cursor using EXEC SQL CLOSE and return the flow to calling program. Similarly i have closed the cursor at
    another 22 locations.
    When i compile the code and run binary the core dump occurs. On analyzing the core it shows
    t@null (l@8) terminated by signal SEGV (no mapping at the fault address)
    0xffffffffffffffff: <bad address 0xffffffffffffffff>
    dbx: core file read error: address 0xfc4ffe48 not in data space
    Current function is dbMtBaseClass::Pswd_Change
    7860 sqlcxt(&_dbMtCtx, &sqlctx, &sqlstm, &sqlfpn);
    if I remove any of the three EXEC SQL CLOSE commands , core dump does not occurs.
    It looks strange.Please help me to resolve the issue.

  • Can I issue this command in PL/SQL: EXECUTE IMMEDIATE '@filename.sql';

    can I issue this command in PL/SQL: EXECUTE IMMEDIATE '@filename.sql';

    Hi,
    Rather the opening a new process (sqlplus), a new connection (need password) etc... I would rather read and execute the file in pl/sql.
    I do not know if someone wrote it already, but here is a quick and dirty code for doing that with UTL_FILE.GET_LINE
    Here, I am only processing some DML statements and no SELECT statements. Correct it as you like !
    CREATE OR REPLACE PROCEDURE run_script ( dir_name IN VARCHAR2,file_name IN VARCHAR2)
    IS
    vSFile UTL_FILE.FILE_TYPE;
    vCmd VARCHAR2(200);
    vNewLine VARCHAR2(200);
    BEGIN
        vSFile := UTL_FILE.FOPEN(dir_name, file_name,'r');
        vCmd := NULL;
        IF UTL_FILE.IS_OPEN(vSFile) THEN
        LOOP
            BEGIN
                UTL_FILE.GET_LINE(vSFile, vNewLine);
                if (vCmd is null) THEN
                    if (upper(vNewLine) like 'INSERT%' or upper(vNewLine) like 'UPDATE%' or upper(vNewLine) like 'DELETE%') THEN
                        if (vNewLine like '%;') THEN
                            /* we have a single line command, execute it now */
                            dbms_output.put_line(substr(vNewLine,1, length(vNewLine)-1));
                            execute immediate substr(vNewLine,1, length(vNewLine)-1);
                        else
                            /* we have a command over multiple line, set vCmd */
                            vCmd := vNewLine;
                        end if;
                    else
                        /* ignore the rest like spool, prompt, accept, errors, host, @, ... */
                        null;
                    end if;
                else
                    if (vNewLine like '%;') THEN
                        /* we have a the last line of the command, execute it now */
                        vCmd := vCmd || ' ' || substr(vNewLine,1, length(vNewLine)-1);
                        dbms_output.put_line(vCmd);
                        execute immediate vCmd;
                        vCmd := null;
                    else
                        /* keep concatenating to vCmd */
                        vCmd := vCmd ||' '|| vNewLine;
                    end if;
                end if;
            EXCEPTION
                WHEN NO_DATA_FOUND THEN
                    EXIT;
                END;
        END LOOP;
        COMMIT;
        END IF;
        UTL_FILE.FCLOSE(vSFile);
    EXCEPTION
        WHEN utl_file.invalid_path THEN
            RAISE_APPLICATION_ERROR (-20052, 'Invalid File Location');
        WHEN utl_file.read_error THEN
            RAISE_APPLICATION_ERROR (-20055, 'Read Error');
        WHEN others THEN
            RAISE_APPLICATION_ERROR (-20099, 'Unknown Error');
    END run_script;
    set serverout on
    create directory scriptdir as '/home/oracle';
    grant read,write on directory to scott;
    exec run_script('SCRIPTDIR', 'test.sql')

  • High "CPU + Wait for CPU" event on pl/sql execute operation

    I am executing a pl/sql in 256 parallel sessions, on 11G r2 DB (RAC 2 nodes), on a 42core IBM P7 Machine.
    PL/sql function opens a cursor on a huge table with around 20M rows and does further processing.
    Work-load is equally divided into 256 parallel sessions. 256 parallel sessions are opened by a middle-ware application and each session processes data based on an identifier (there are 256 distinct identifier values).
    PL/sql function is comprised of some SQL operations, on which i am experiencing some cluster waits. But CPU + wait for CPU event on pl/sql execute operation is close to 80% of the total execution time.
    Top user events:
    Event Event Class % Event Avg Active Sessions
    CPU + Wait for CPU CPU 80.88 98.15
    gc current block 2-way Cluster 3.33 4.05
    gc cr block busy Cluster 2.01 2.44
    gc cr block 2-way Cluster 1.97 2.39
    db file sequential read User I/O 1.81 2.20
    Top SQL command type:
    SQL Command Type Distinct SQLIDs % Activity Avg Active Sessions
    PL/SQL EXECUTE 3 60.99 74.02
    SELECT 66 12.90 15.65
    INSERT 24 9.89 12.01
    UPDATE 9 6.00 7.28
    DELETE 2 1.33 1.61Rest of the SQL queries seem to be very optimum, but waits on pl/sql execute operation are causing very low tps.
    Can anybody give me some heads-up about where to and what to look for to resolve?
    Please let me know if any extra information is required.

    AWR report :
    Header
    DB      Name      DB Id           Instance      Inst num      Startup Time           Release RAC
    FCR           1304316316      fcrypp1      1                01-12ÔÂ-12 04:12      11.2.0.2.0 YES
    Host           Name Platform                     CPUs      Cores      Sockets Memory (GB)
    z4ci2011      AIX-Based Systems (64-bit)      168      42        320.00
                   Snap Id      Snap Time                     Sessions      Cursors/Session
    Begin Snap: 40650           01-12ÔÂ-12 06:40:03      1203           5.8
    End Snap:      40669           01-12ÔÂ-12 09:50:01      1122           5.3
    Elapsed:        189.96 (mins)    
    DB Time:        22,251.65 (mins)
    Load profile
    Per Second           Per Transaction      Per Exec      Per Call
    DB Time(s):           117.1                19.5                     0.00           3.89
    DB CPU(s):                16.1                2.7                     0.00           0.53
    Redo size:                12,759,186.3      2,126,361.0    
    Logical reads:           181,875.9           30,310.2    
    Block changes:           54,515.5           9,085.2    
    Physical reads:      1,340.3           223.4    
    Physical writes:      8,788.9           1,464.7    
    User calls:           30.1                5.0    
    Parses:                26.5                4.4    
    Hard parses:           0.4                0.1    
    W/A MB processed:      8.5                1.4    
    Logons:                0.1                0.0    
    Executes:                41,176.0           6,862.1    
    Rollbacks:                1.9                0.3    
    Transactions:           6.0      
    Time model statistics
    Statistic Name                                             Time (s)          % of DB Time
    sql execute elapsed time                              1,334,935.55     99.99
    PL/SQL execution elapsed time                         1,180,376.60     88.41
    DB CPU                                                       182,904.44          13.7
    repeated bind elapsed time                              292.83               0.02
    sequence load elapsed time                              279.75               0.02
    parse time elapsed                                        87.4               0.01
    hard parse elapsed time                                   22.52               0
    failed parse elapsed time                              5.12               0
    connection management call elapsed time               4.61               0
    PL/SQL compilation elapsed time                         1.91               0
    hard parse (sharing criteria) elapsed time          0.49               0
    hard parse (bind mismatch) elapsed time               0.39               0
    inbound PL/SQL rpc elapsed time                         0.1     0
    DB time                                                       1,335,099.30     
    background elapsed time                                   33,298.67     
    background cpu time                                        11,692.76     
    Operating System Statistics
    Statistic Value End Value
    AVG_BUSY_TIME 202,428  
    AVG_IDLE_TIME 936,397  
    AVG_IOWAIT_TIME 4,124  
    AVG_SYS_TIME 84,480  
    AVG_USER_TIME 117,573  
    BUSY_TIME 34,074,303  
    IDLE_TIME 157,378,825  
    IOWAIT_TIME 755,368  
    SYS_TIME 14,256,010  
    USER_TIME 19,818,293  
    LOAD 21 10
    OS_CPU_WAIT_TIME 23,770,800  
    VM_IN_BYTES 20,496  
    VM_OUT_BYTES 2,086,940,520  
    PHYSICAL_MEMORY_BYTES 343,597,383,680  
    NUM_CPUS 168  
    NUM_CPU_CORES 42  
    NUM_LCPUS 168  
    NUM_VCPUS 42  
    GLOBAL_RECEIVE_SIZE_MAX 41,943,040  
    GLOBAL_SEND_SIZE_MAX 41,943,040  
    TCP_RECEIVE_SIZE_DEFAULT 16,384  
    TCP_RECEIVE_SIZE_MAX 9,223,372,036,854,775,807  
    TCP_RECEIVE_SIZE_MIN 4,096  
    TCP_SEND_SIZE_DEFAULT 16,384  
    TCP_SEND_SIZE_MAX 9,223,372,036,854,775,807  
    TCP_SEND_SIZE_MIN 4,096
    SQL ordered by CPU Time
    CPU Time (s)      Executions       CPU per Exec (s) %Total      Elapsed Time (s)      %CPU      %IO      SQL Id SQL Module SQL Text
    180,330.13           127                1,419.92                98.59      1,326,401.03           13.60      1.08      04kt8u64udphu    BEGIN :1 := ap_ch_eod_shell_en...
    8,025.48           9,868,469           0.00                     4.39      10,809.88                74.24      9.21      arnkbsnzhha77 ch_txn_shell_115  SELECT * FROM CH_ACCT_MAST WHE...
    6,117.64           9,873,495           0.00                     3.34      8,557.64                71.49      7.14      8qcryvj294s79 ch_eod_shell_138  UPDATE CH_ACCT_MAST_PAR SET DA...
    4,614.71           3,185,313           0.00                     2.52      11,130.77                41.46      11.88      b75wwkxw34x2k ch_eod_shell_228  INSERT INTO CH_TMP_XF_GL_TXNS ...
    4,374.29           9,866,217           0.00                     2.39      5,876.00                74.44      37.88      g22p493ra2zr5 ch_eod_shell_248  UPDATE CH_ACCT_MAST SET BAL_LA...
    3,514.57           14,026,451           0.00                     1.92      6,274.60                56.01      29.55      7bwhphfnnuqpr ch_eod_shell_59  INSERT INTO CH_ACCT_INT_BREAKU...
    3,253.36           3,185,706           0.00                     1.78      3,875.42                83.95      9.20      9dq134q9btxq8 ch_eod_shell_74  INSERT INTO CH_ST_CAP_INPUT_TX...
    3,131.64           9,875,603           0.00                     1.71      5,338.43                58.66      15.55      6xhwk1b37rh1t ch_txn_shell_143  UPDATE CH_ACCT_ATTRIBUTES SET ...
    2,954.15           9,878,718           0.00                     1.62      5,692.88                51.89      13.22      b4at7uq2hw6r7 ch_sweepin_shell  SELECT TRIM(A.COD_PKG) FROM RP...
    2,572.01           9,867,277           0.00                     1.41      4,605.88                55.84      12.58      54ud0a8tuwwbc ch_txn_shell_17  SELECT * FROM CH_ACCT_ATTRIBUT...
    1,941.29           19,730,455           0.00                     1.06      5,580.38                34.79      7.02      dx5kng8qu560t ch_txn_shell_59  UPDATE CH_ACTIONS_DUE SET COD_...
    1,846.01           9,875,239           0.00                     1.01      4,737.66                38.96      12.55      af7f92f13rmy4 ch_txn_shell_85  INSERT INTO CH_ACTIONS_DUE (CO...

Maybe you are looking for