How to catch sql error in script?

Hi Gurus,

I have a script which send sql query to oracle db and return value to my script.
dummy code like below:

sqlplus -s  user/${PASSWD}@${ORACLE_SID} @${DIR}/query.sql > outputfile

using above code, when query has error, it send error to same out put file and exit code is 0, is there any way to make the sqlplus exit code other than 0 if the query contains any error?

thanks in advance

Put this line whenever sqleror exit sql.sqlcode as the first line of your "query.sql" file...

That won't quite work as expected:

 > more gg.sql
whenever sqlerror exit sql.sqlcode;

select 1/0 from dual;

exit

 > sqlplus -s myid@mydb @gg.sql
Enter password:
select 1/0 from dual
        *
ERROR at line 1:
ORA-01476: divisor is equal to zero


 > echo $?
196
 >

So not quite.
has something to do with 1476 being modded down by 256 (or something - i'll let somebody more knowledgeable comment on that)

I've had most success by just grepping the output file for an ORA- error code (or SP2, etc.)

# error codes to look for (add/remove what you want to look for)
ERRCODES="(ORA-|EXP-|IMP-|KUP-|MOD-|PLS-|SP2-|SQL-|TNS-)"

sqlplus -s myid@mydb @gg.sql   2>&1 >> ${LOGFILE}
ERR=$?

ERRC=`egrep "${ERRCODES}" ${LOGFILE} | wc -l`

and then you have an error if either:
[ $ERR -ne 0 ] || [ $ERRC -ne 0 ]

Also, to the OP: Ken6503: you should be careful with this.

Your password will be visible to anyone on the same server, via "ps -ef" command.

If you're using an automated script, you really should consider externally defined ids, and then just use:

sqlplus -s  / @${DIR}/query.sql > outputfile

Thanks for reminding me. I am going to take consideration about the security issue

My reply was geared towards providing the OP with an exit code other than zero from sqlplus in case of failure...because the default behavior of sqlplus is to return zero to its environment irrespective of what goes on inside of it. Also the sqlcode returned to the shell will always be truncated to stay within the shell limits <0-255>. In the example you provided the sqlcode for the ORA error is 1476 which is not mod'd down...but is truncated bitwise leaving only the 8 least significant bits. As 1476 is 0x000005C4 and its 8 LS bits are 0xC4 giving a decimal value of 196. However the exact sqlcode will still be be dumped to the logfile and can be extracted from there...

Yes it can be re-directed to the logfile and viewed in there...

I too agree with the above comments...

Understood, however, the only issue I was trying point out was that because of that bit-wise fun, depending on the error code sent back, it *could* come back as 0, despite throwing an error.
(ie if Oracle throws ORA-00256, even with the WHENEVER logic there, it'll pass error code 256 back to unix, get mashed to 0, and say "oh hey, everything's fine" :wink:
So unfortunately, it's hard to rely on that. Just have to be careful.

Yes that is correct since error codes with all zeros in their LS byte would be interpreted as success because $? evaluates to zero...

ORA-00256 is 0x100 with its least significant byte being zero meaning that $? is zero and for all scenarios where the lsb is zero...perhaps the only workaround is to have a hard-coded value i.e. whenever sqlerror exit 1 and redirect all stdout/stderr to a logfile and after the sqlplus sessions ends...peek inside to see the exact error that caused the abend or wait until the shell is fixed so that no bits are truncated...:wink: