Handling Errors Oracle Tips by Burleson Consulting

Errors are diagnosed by use of the iserror() function invoked on any PEAR DB handle (connection, statement, result), and returns TRUE if an error has occurred or FALSE if one has not. The syntax is extremely simple:

    if (DB::iserror($handle)) {
       //do something
    }

Each handle type has methods which allow the further examination of the error that has occurred. These methods are common to all PEAR modules and are described in the class called PEAR_Error. The online documentation reveals the following information regarding PEAR_Error:

• PEAR_Error::addUserInfo() - Add user information.

• PEAR_Error::getCallback() - Get callback function name.

• PEAR_Error::getCode()- Get error code.

• PEAR_Error::getMessage() - Get error message.

• PEAR_Error::getMode() - Get error mode.

• PEAR_Error::getDebugInfo() - Get debug information.

• PEAR_Error::getType() - Get error type.

• PEAR_Error::getUserInfo() - Get additional user-supplied information.

• PEAR_Error::PEAR_Error() - Constructor.

• PEAR_Error::toString() - Make string representation.

• PEAR_Error  is an object created by every function in PEAR in case of a failure. It provides information on why a function failed.

This same interface is implemented by all types of PEAR DB handles. Among the available methods, several are useful for dealing with Oracle RDBMS. 

When connecting to Oracle, the getMessage() method is not practical because it simply reports that an error has occurred, without providing any further detail.  However, the getUserInfo()and getDebugInfo() methods are quite useful for detailed error reporting. Both methods return the same thing; the full text of the error statement and the error message. A demonstration is shown below:

#!/usr/local/bin/php
<?php
require_once('DB.php');
$DSN="oci8://scott:lion@local";
$db=DB::connect($DSN);
if (DB::iserror($db)) {
   die($db->getUserInfo());
}
$sql="select * from non_existing_table";
$sth=$db->query($sql);
if (DB::iserror($sth)) {
   die($sth->getDebugInfo());
}
?>

If the above code is executed, assuming the password for the user “scott” is “tiger” and that the table, “non_existing_table” does not exist, the result is noted as follows: 

$ ./example20a.php
 [nativecode=ORA-01017: invalid username/password; logon denied] ** oci8://scott:lion@local$

This reveals that the password is incorrect. If the password is corrected in the DSN and the procedure executed, the following results:

$ ./example20a.php
select * from non_existing_table [nativecode=ORA-00942: table or view does not exist]$

The full text of the erroneous SQL statement is shown together with the error message, but the offset in the SQL statement where the error is detected cannot be seen. OCI8 can give that offset. The “user info” method, getUserInfo(), provides essentially identical information.

If the following line is inserted into the example above before the second call to the “die” function,

   echo "Error code is:".$sth->getCode()."\n";

the following results:

$ ./example20a.php

Error code is:-18
select * from non_existing_table [nativecode=ORA-00942: table or view does not exist] 
The error code returned is “-18”; the error code from PEAR DB, not the Oracle error code.

The following is an example of using the getMessage() method, instead of the getUserInfo() or getDebugInfo() methods:

$ ./example20a.php
DB Error: no such table$

This is less than useful, especially if there are several SQL statements in the same application. When debugging the system, information regarding the SQL statement that has failed can sometimes be useful.

SEE CODE DEPOT FOR FULL SCRIPTS

---

The above book excerpt is from  "Easy Oracle PHP: Creating Dynamic Web Pages with Oracle Data".  You can buy it direct from the publisher for 50%-off and get instant access to the code depot of Oracle tuning scripts:

Expert Remote DBA BC is America's oldest and largest Remote DBA Oracle support provider.  Get real Remote DBA experts, call BC Remote DBA today.