Question

This question is related to my previous one: RaiseError (PERL, DBI) equivalent for unixODBC C API?

As I isolated the problem later, I’ll post new question, that is more specific, isolated and without unnecessary information.

---

Version: unixODBC 2.3.0
lib: unixODBC – C API

Suppose I have a stored FUNCTION:

CREATE FUNCTION "test".func() RETURNING LVARCHAR(1000);
set debug file to '/home/directory_does_not_exists/unknown.log';
trace off;
trace on;
trace off;
return 'result is set here';
END FUNCTION;

And the same body, but in stored PROCEDURE:

CREATE PROCEDURE "test".proc(pDummy SMALLINT)
set debug file to '/home/directory_does_not_exists/unknown.log';
trace off;
trace on;
LET pDummy = 2;
trace off;
END PROCEDURE;

As you can see, they are absolutely the same. The path to debug file is wrong, so error is expected. When I execute call func() from Aqua Data Studio the error is detected:

Cannot open DEBUG file for SPL routine trace

It’s the same for call proc(1).

BUT when I execute these 2 calls through unixODBC (using SQLExecute),

execute procedure proc(1);

returns SQL_ERROR (which is expected and fine), while

execute function func();

returns SQL_SUCCESS.. BUT 'result is set here' is not returned, empty string ('') is returned, instead..

Executing call func() gives the same results, as execute function func();

Calling SQLMoreResults returns SQL_NO_DATA, SQLFetch returns SQL_ERROR.

Any ideas?

Answer 1

First of all – thanks a lot to @Jonathan Leffler(for the hint with SQLIDEBUG=2:xyz + sqliprint and testing on his machine) and @bohica (for the hint with strace ) for the support! That really helped me to find the real problem and solve it! +1 from me for both.
Unfortunately, the answer was not in their posts, that’s why I’ll answer it my own.

---

Summary:

SQLPrepare and SQLExecute fail sometimes on some errors, but not all. When stored procedure is used, these functions catch more errors. Unfortunately, the situation is different with stored functions.

How I catch the errors now? If SQLExecute is successfull, I call SQLNumResultCols – that’s normal. After that, I call SQLFetch which is also expected. BUT, as SQLFetch may fail for many reasons (for example, it always fails on stored procedures), it’s error is ignored. And there’s a while like

if ( SQLNumResultCols( stmt, &nAllCols ) != SQL_SUCCESS )
// ...

int nSucceededFetches = 0; // added now, see below why
while ( SQL_SUCCEEDED( SQLFetch( stmt ) ) )
{
    ++nSucceededFetches; // added now, see below why
    /* bla bla */ 
}

And here’s the key – add additional check:

if( 0 == nSucceededFetches && nColumns > 0 )

which says – if there are returned columns and fetch fails on the FIRST call, then something’s wrong. Then I have

while ( SQL_SUCCESS == SQLError( 0, 0, stmt, szSqlState, &nNativeError, szError, 500, &nErrorMsg ) )
{ /* bla bla */ }

---

And everything’s fine. I still don’t understand why SQLExecute returns SQL_SUCCESS (NOT even SQL_SUCCESS_WITH_INFO ..), but it doesn’t matter.