Tim,

As I understand it...

Problem Summary:

Certain versions of the Oracle Client Interface will return additional
information on success.  This return seems to be inconsistent between Oracle
Versions and DBI/DBD::Oracle tends to interpret this return string/code as
an error.

The Oracle issue is documented at:

http://technet.oracle.com/doc/server.815/a67846/basics.htm#425597

Excerpt:  OCI_SUCCESS_WITH_INFO The function completed successfully; a call
to OCIErrorGet() will return additional diagnostic information. This may
include warnings.

Symptoms:

DBI returns SUCCESS_WITH_INFO but OCIGetError returns nothing. Thus,
depending on how strictly you write your code, the program either dies with
an error, or appears to execute and throw a spurious message.

Examples:

1.  [At least at one time] t/long.t, test five shows the error:

        ORA-01801: date format is too long for internal buffer

2.  Creating a stored procedure or trigger shows the error:

        DBD::Oracle::db do failed: ORA-00000: normal, successful completion
(DBD SUCCESS_WITH_INFO: OCIStmtExecute) at ...

3.  At least one person reported creating stored procedures incorrectly (no
'END;' statement in the code) yet Oracle created an unusable stored
procedure without complaint.

Solutions:

1.  You mentioned a temporary fix to this with the following patch: 

*** 1.47 1998/12/28 00:04:37
--- dbdimp.c 1999/01/15 22:02:18
***************
*** 1031,1037 ****
/* we don't AutoCommit on select so LOB locators work */
(DBIc_has(imp_dbh,DBIcf_AutoCommit) && !is_select)
? OCI_COMMIT_ON_SUCCESS : OCI_DEFAULT);
! if (status != OCI_SUCCESS) {
oci_error(sth, imp_sth->errhp, status, "OCIStmtExecute");
return -2;
}
--- 1031,1037 ----
/* we don't AutoCommit on select so LOB locators work */
(DBIc_has(imp_dbh,DBIcf_AutoCommit) && !is_select)
? OCI_COMMIT_ON_SUCCESS : OCI_DEFAULT);
! if (status != OCI_SUCCESS && status != OCI_SUCCESS_WITH_INFO) {
oci_error(sth, imp_sth->errhp, status, "OCIStmtExecute");
return -2;
}

2.  Due to the following, you may have undone the above fix by design.  The
discussion around it did not make that clear.  The solution suggested the
following coding style:

        $dbh->{RaiseError} = 0;
        $rv = $dbh->do(whatever);                      # succeeds
        $rv = $dbh->do(whatever) || die $DBI::errstr;  # succeeds
    die $DBI::errstr if die $DBI::err;             # dies

        Thus, those who where interested in capturing these messages could,
others could just ignore it and carry on.

3.  Finally if I have the dates on the messages correct you fixed this with
version 1.04 of DBD::Oracle announced on the 11th of July 2000.  No details
mentioned in the announcement.



I'm not sure if this helps or not.  I can try setting RaiseError in my own
code.  I don't remember straight off if it defaults to 1 or 0.  If 0, and
solution 1 is still valid, my code should work.  Do I also need to catch and
suppress the error messages explicitly so they do not print out?

Robert Kuropkat



-----Original Message-----
From: Tim Bunce [mailto:[EMAIL PROTECTED]]
Sent: Sunday, March 24, 2002 5:32 AM
To: Robert Kuropkat (MIS Contractor)
Cc: '[EMAIL PROTECTED]'
Subject: Re: Error Message?


Can you read these
    http://www.google.com/search?q=SUCCESS%5FWITH%5FINFO+DBI+bunce
and send me a summary of what I said :)

Then I can update the docs...

Tim.


On Sat, Mar 23, 2002 at 03:55:56PM -0800, Robert Kuropkat (MIS Contractor)
wrote:
> 
> What does this mean?
> 
> DBD::Oracle::db do failed: ORA-00000: normal, successful completion (DBD
> SUCCESS_WITH_INFO: OCIStmtExecute) at RTE/Schema_Code.pm line 746.
> 
> I can't tell if this is saying the DBI call failed or succeeded.  The
stored
> procedure gets created so it does not seem to actually be a failure of the
> method call.  I don't get this when trying to create tables, constraints,
> etc.  So, what's with the messages spewing forth?  If the procedure is
> actually working, can I suppress this message?
> 
> Platform:  Solaris 5.8
> Oracle version: 8.1.7
> perl version: 5.6.1
> DBI version: 1.21
> DBD::Oracle version: 1.12
> 
> As a side note, I do not get this error when I run it on windows.
> 
> perl version: 5.6.1 (ActiveState)
> DBI version 1.14
> DBD::Oracle version: 1.06
> 
> Robert Kuropkat
> 
> 

Reply via email to