Srdjan,
> I have played a bit more
As did I.
> I am not sure if the difference in operating systems is significant
> (Solaris vs. WinNt)?
Behavior is similar but not the same. In my case all the software is on one
machine (I am not connecting remotely).
> oerr ORA 24338
> 24338, 00000, "statement handle not executed"
> // *Cause: A fetch or describe was attempted before executing a
> // statement handle.
> // *Action: Execute a statement and then fetch or describe the data.
I thought this was caused by the fact that the DBI code expected a ref
cursor that was not forthcoming.
> ========= SUCCESSFULL EXECUTION
> ====================================================================
> bind :p3 - initialising new DBI::st=HASH(0x28b8dc) for cursor
> 0x24c5f0...
Above the ref cursor sth is initialized
> ======== NOT QUITE AS SUCCESSFUL EXECUTION
> =========================================================
> dbd_describe SELECT (implicit, lb 80)...
> !! ERROR: 24338 'ORA-24338: statement handle not executed (DBD
> ERROR: OCIAttrGet OCI_ATTR_PARAM_COUNT)'
> <- execute= undef at DBI_Driver.pl line 328 via
> /export/home/c828764/CPAN/DBI_Driver/DBI_Driver.pl line 327
> =================== END OF DUMP
But in the above case a parameter is 'missing', so the ref cursor is never
initialized.
I have played with other aspects of your script, and the stored code.
Specifically I return 5 for success,
2 for invalid query and 3 no data found. Also:
IF IN_COL1 is null THEN // changed here
RAISE INVALID_QUERY_DATA;
END IF;
was required to access the invalid query exception, even from SQL plus.
To be honest, I was very surprised to be able to access a ref cursor that
was an out parameter in a stored function.
That particular construct is some what unusual. If the stored function is
converted to a stored procedure (though I realise you cannot modify the
stored code) it is better behaved.
David
