Thread: [opendbx] Error handling

Brought to you by: nose

libopendbx-devel

[opendbx] Error handling

From: Waters, B. <bw...@sa...> - 2013-10-04 14:02:30

We are considering using OpenDBX in a project that will access mssql
from linux.  I am using the C++ API.  I have a query that is generating
a primary key violation (severity 14), but the error is not being
surfaced.  How should this be handled?

 

Thanks, Brian.

Re: [opendbx] Error handling

From: Norbert S. <no...@li...> - 2013-10-04 14:48:39

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brian

> We are considering using OpenDBX in a project that will access
> mssql from linux.  I am using the C++ API.  I have a query that is
> generating a primary key violation (severity 14), but the error is
> not being surfaced.  How should this be handled?

Can you show me example code?

Severity 14 is considered a warning in the MSSQL backend but should
nevertheless create an backend error which would throw an Exception in
the OpenDBX C++ API.


Norbert

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSTtU0AAoJEA3e3tWv2uU+5l4P/iD+u2RHHdfyrVHb/icLbqOz
sbQ93SY4k6JCSaJtUDuC92uqkJludf24OQNiowGwDZx7zVmdwAbyCuw+unO6J/0E
yyGa9srSspxS34ISGtmLGz+yE3o2sxSv7+l/WdeMPzq0NRiNyH0xLQBjyj99bfLy
QtzRXPU791szE8HhvKe+NgoBuwwT5SnHTjdxz4M2pR7cTw2xXxjGYDg6b5DSPxdc
p/WPLoUivjBvtzH9e/0EpzQRZqvVua1dmFTeo7Sry4DlrwHdM5/WhCSaygTbetqe
PnmIYAUtcOAxB8fwUNNiWvkkSHcWo6x3z2Mbu0IyAvDi9yEh7J3HyPA06iT8VdrY
zzlB65pft9FOWQf+0dTNkaD6jXSjG9QQeQFYk4XOe6nCMjNV1Ljc1WMzdE+D19b3
nthiReIef9erM6EE8xpApR530Q7l9qSPUSu1dfpUYg7brHjRgXwNKNI+Www9jHXx
7bKYnypPwetRFN10xr0yOialH7AZPZrvbaLA80vteHpSJsgFFK5HNgEVyFEKtJin
/WDq1vgy1T207XtzeOg6VnucpC+kIy7Q0l+6lpvNGkG/IJ1IUlyD5ANfQeCfyJWa
mnNEBCHSo6fuB6ombbEVyohpKNUzjQBU278GrMEJLj11M/k0u3tsj1t9RLwc69z9
Y35TlPUZxtdDvJYpT+7X
=iumk
-----END PGP SIGNATURE-----

Re: [opendbx] Error handling

From: Waters, B. <bw...@sa...> - 2013-10-04 15:11:44

Norbert,

Thanks for the quick response.  Below is the SQL statement that is
getting executed and below that is code.  It appears that the issue
might revolve around the dbsqlok().  When dbsqlok() is called in
mssql_odbx_result() the following sequence occurs 1) mssql_msg_handler()
is called with the primary key violation message, 2) mssql_err_handler()
is called, and 3) mssql_msg_handler() is called indicating that the
statement has been terminated.  Then dbsqlok() returns with a return
value other than FAIL.  Since dbsqlok() does not return FAIL,
-ODBX_ERR_BACKEND is not returned and an exception is not raised.

Please let me know what you think.

Thanks, Brian.

EXEC P_CC_REQUEST_ADD
@SESSION_ID=1,@REQUEST_NUMBER=0,@EVENTTIMESTAMP='2013-10-04T14:28:34.000
',@REQUEST_TYPE=1,@RATING_GROUP=0,@REPORTING_REASON=-1,@USED_TIME=0,@USE
D_TOTAL_OCTETS=0,@USED_INPUT_OCTETS=0,@USED_OUTPUT_OCTETS=0

Void GYMessageCCR::recordMessage(GYSession& session, OpenDBX::Conn&
conn)
{
    FTString sql, sevts;
    FTTime evts;
    eCCRequestType type;

    try
    {
        type = getCCRequestType();
        evts = getEventTimestamp();
        evts.Format(sevts,"%i", False);

        sql.format("EXEC P_CC_REQUEST_ADD"
            " @SESSION_ID=%lld"
            ",@REQUEST_NUMBER=%ld"
            ",@EVENTTIMESTAMP='%s'"
            ",@REQUEST_TYPE=%d"
            ",@RATING_GROUP=%d"
            ",@REPORTING_REASON=%d"
            ",@USED_TIME=%d"
            ",@USED_TOTAL_OCTETS=%lld"
            ",@USED_INPUT_OCTETS=%lld"
            ",@USED_OUTPUT_OCTETS=%lld",
            session.getSessionId(),
            getCCRequestNumber(),
            sevts.c_str(),
            (Int)type,
            getCCRRatingGroup(),
            getCCRReportingReason(),
            getUsedTime(),
            getUsedTotalOctets(),
            getUsedInputOctets(),
            getUsedOutputOctets());

        OpenDBX::Result r = conn.create(sql).execute();

        odbxres stat;
        while ((stat = r.getResult()) != ODBX_RES_DONE)
        {
            switch(stat)
            {
                case ODBX_RES_TIMEOUT:
                case ODBX_RES_NOROWS:
                    continue;
                default:
                    break;
            }
        }
    }
    catch (OpenDBX::Exception ex)
    {
        FTError *err = new FTError(FTError::Warning);
        err->setTextf("OpenDBX EXCEPTION: %s - %s", ex.what(),
sql.c_str());
        throw err;
    }
}

-----Original Message-----
From: Norbert Sendetzky [mailto:no...@li...] 
Sent: Friday, October 04, 2013 9:48 AM
To: OpenDBX devel list
Subject: Re: [opendbx] Error handling

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brian

> We are considering using OpenDBX in a project that will access
> mssql from linux.  I am using the C++ API.  I have a query that is
> generating a primary key violation (severity 14), but the error is
> not being surfaced.  How should this be handled?

Can you show me example code?

Severity 14 is considered a warning in the MSSQL backend but should
nevertheless create an backend error which would throw an Exception in
the OpenDBX C++ API.


Norbert

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSTtU0AAoJEA3e3tWv2uU+5l4P/iD+u2RHHdfyrVHb/icLbqOz
sbQ93SY4k6JCSaJtUDuC92uqkJludf24OQNiowGwDZx7zVmdwAbyCuw+unO6J/0E
yyGa9srSspxS34ISGtmLGz+yE3o2sxSv7+l/WdeMPzq0NRiNyH0xLQBjyj99bfLy
QtzRXPU791szE8HhvKe+NgoBuwwT5SnHTjdxz4M2pR7cTw2xXxjGYDg6b5DSPxdc
p/WPLoUivjBvtzH9e/0EpzQRZqvVua1dmFTeo7Sry4DlrwHdM5/WhCSaygTbetqe
PnmIYAUtcOAxB8fwUNNiWvkkSHcWo6x3z2Mbu0IyAvDi9yEh7J3HyPA06iT8VdrY
zzlB65pft9FOWQf+0dTNkaD6jXSjG9QQeQFYk4XOe6nCMjNV1Ljc1WMzdE+D19b3
nthiReIef9erM6EE8xpApR530Q7l9qSPUSu1dfpUYg7brHjRgXwNKNI+Www9jHXx
7bKYnypPwetRFN10xr0yOialH7AZPZrvbaLA80vteHpSJsgFFK5HNgEVyFEKtJin
/WDq1vgy1T207XtzeOg6VnucpC+kIy7Q0l+6lpvNGkG/IJ1IUlyD5ANfQeCfyJWa
mnNEBCHSo6fuB6ombbEVyohpKNUzjQBU278GrMEJLj11M/k0u3tsj1t9RLwc69z9
Y35TlPUZxtdDvJYpT+7X
=iumk
-----END PGP SIGNATURE-----

------------------------------------------------------------------------
------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from 
the latest Intel processors and coprocessors. See abstracts and register
>
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clk
trk
_______________________________________________
libopendbx-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
http://www.linuxnetworks.de/doc/index.php/OpenDBX

Re: [opendbx] Error handling

From: Norbert S. <no...@li...> - 2013-10-04 17:08:18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brian

> Thanks for the quick response.  Below is the SQL statement that is 
> getting executed and below that is code.  It appears that the
> issue might revolve around the dbsqlok().  When dbsqlok() is called
> in mssql_odbx_result() the following sequence occurs 1)
> mssql_msg_handler() is called with the primary key violation
> message, 2) mssql_err_handler() is called, and 3)
> mssql_msg_handler() is called indicating that the statement has
> been terminated.  Then dbsqlok() returns with a return value other
> than FAIL.  Since dbsqlok() does not return FAIL, -ODBX_ERR_BACKEND
> is not returned and an exception is not raised.

Thanks for debugging the problem.
I think it's OK that dbsqlok() does not return "FAIL" because the SQL
statement is correct. Only the execution fails due to the primary key
constraint so I would expect that dbresults() should return something
else than "SUCCEED" or "NO_MORE_RESULTS".

The mssql_err_handler function returns "INT_CANCEL" in your case which
should case a "FAIL" in the function that encountered the error.

Do you use FreeTDS? Which version?
I had a look into the latest version (0.92.79) but I'm not sure how
this problem is handled there. The documentation of the functions
doesn't help either:

dbsqlok():
Wait for results of a query from the server. \retval FAIL SQL syntax
error, typically.

dbresult():
Call dbresults() after calling dbsqlexec() or dbsqlok(), or
dbrpcsend() returns SUCCEED. Unless one of them fails, dbresults will
return either SUCCEED or NO_MORE_RESULTS. SUCCEED does not imply that
DBROWS() will return TRUE or even that dbnumcols() will return nonzero.

dbperror():
Call client-installed error handler. the handler's return code,
subject to correction and adjustment for vendor style: - INT_CANCEL
The db-lib function that encountered the error will return FAIL.

So according to the documentation it should work this way :-/
Maybe you should ask on the FreeTDS list too if this is a bug in the
FreeTDS library.


Norbert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSTvXeAAoJEA3e3tWv2uU+69kQAKZyo0FuoznPHgCEM8LIOpk3
tHitmXLbE3ywGv9JdNraKEERfqQx+9gfoViIbjygD6G2bOJKgyZ+lZXWyZDZojCD
nGq5p8HE6LMdyB9dmnewjjVHp675mzfliD7W4zK/JHtq9JjPWGEaybIEwgNUrz+n
sqnKObwjyzuA47nxT9WsmT2Et9t/awv07Vn91kN8NLQtHqye02Cfbhs+piE9/5zy
90+lKGgNl6htyVGhqVSvI5vHGbxOD84eE36Iux8VAMNc/AYU1PvZlP+wcNGr60zR
U9kop0iRS8ZEvdQ9Q9NQeRQtQm0ekLGeceBzGOXBPESfxwiG6OQrD1bCfBswHEwp
269gSYi+6gzo33+YtUdeVZf8wFPwoRzKvE3w4QQ35HPtXjmxKNaLL879+1O026dj
fHvqnoTHuWHGCpPanx5Fbt3LWd92rExDzBSybWUjXxkwhIQL67JWpft8crcPUOcR
YIkYoDPamGSGwfGCINetnh5ttTzjxa1X/FYfNtcy/FLEUUN61TmqVwoCdElLzVUz
AXDCwXXohdVJjdGobDOF5j0tuk3IkiBIwzyDVBUafZDSEOf0l5dLKzd0TaDP3z5H
yiIbk0AkvvLseHAQCQKCJJWLA9BOab/LandE7Rq8WtnrdC/JeCD55kFKJug1a2A/
bndImUrR0qtxR28hwTty
=YTTi
-----END PGP SIGNATURE-----

Re: [opendbx] Error handling

From: Waters, B. <bw...@sa...> - 2013-10-04 18:21:00

Norbert,

Thanks for the response.  I am current using freetds 0.82.  I started
with version 0.91, but encountered a seg fault, so I went back to 0.82.
In digging through freetds, it appears to be a design oversight.  In
this case, the error handler is being called from
_dblib_handle_info_message().  This method does not capture the return
value from the error handler, therefore it does not cancel the
operation.  Maybe they are expecting to handle the processing of info
messages through some other mechanism other than an error handler.

In any case, I have posted a question to the freetds mail list.

Thanks, Brian.

-----Original Message-----
From: Norbert Sendetzky [mailto:no...@li...] 
Sent: Friday, October 04, 2013 12:08 PM
To: OpenDBX devel list
Subject: Re: [opendbx] Error handling

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brian

> Thanks for the quick response.  Below is the SQL statement that is 
> getting executed and below that is code.  It appears that the
> issue might revolve around the dbsqlok().  When dbsqlok() is called
> in mssql_odbx_result() the following sequence occurs 1)
> mssql_msg_handler() is called with the primary key violation
> message, 2) mssql_err_handler() is called, and 3)
> mssql_msg_handler() is called indicating that the statement has
> been terminated.  Then dbsqlok() returns with a return value other
> than FAIL.  Since dbsqlok() does not return FAIL, -ODBX_ERR_BACKEND
> is not returned and an exception is not raised.

Thanks for debugging the problem.
I think it's OK that dbsqlok() does not return "FAIL" because the SQL
statement is correct. Only the execution fails due to the primary key
constraint so I would expect that dbresults() should return something
else than "SUCCEED" or "NO_MORE_RESULTS".

The mssql_err_handler function returns "INT_CANCEL" in your case which
should case a "FAIL" in the function that encountered the error.

Do you use FreeTDS? Which version?
I had a look into the latest version (0.92.79) but I'm not sure how
this problem is handled there. The documentation of the functions
doesn't help either:

dbsqlok():
Wait for results of a query from the server. \retval FAIL SQL syntax
error, typically.

dbresult():
Call dbresults() after calling dbsqlexec() or dbsqlok(), or
dbrpcsend() returns SUCCEED. Unless one of them fails, dbresults will
return either SUCCEED or NO_MORE_RESULTS. SUCCEED does not imply that
DBROWS() will return TRUE or even that dbnumcols() will return nonzero.

dbperror():
Call client-installed error handler. the handler's return code,
subject to correction and adjustment for vendor style: - INT_CANCEL
The db-lib function that encountered the error will return FAIL.

So according to the documentation it should work this way :-/
Maybe you should ask on the FreeTDS list too if this is a bug in the
FreeTDS library.


Norbert
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSTvXeAAoJEA3e3tWv2uU+69kQAKZyo0FuoznPHgCEM8LIOpk3
tHitmXLbE3ywGv9JdNraKEERfqQx+9gfoViIbjygD6G2bOJKgyZ+lZXWyZDZojCD
nGq5p8HE6LMdyB9dmnewjjVHp675mzfliD7W4zK/JHtq9JjPWGEaybIEwgNUrz+n
sqnKObwjyzuA47nxT9WsmT2Et9t/awv07Vn91kN8NLQtHqye02Cfbhs+piE9/5zy
90+lKGgNl6htyVGhqVSvI5vHGbxOD84eE36Iux8VAMNc/AYU1PvZlP+wcNGr60zR
U9kop0iRS8ZEvdQ9Q9NQeRQtQm0ekLGeceBzGOXBPESfxwiG6OQrD1bCfBswHEwp
269gSYi+6gzo33+YtUdeVZf8wFPwoRzKvE3w4QQ35HPtXjmxKNaLL879+1O026dj
fHvqnoTHuWHGCpPanx5Fbt3LWd92rExDzBSybWUjXxkwhIQL67JWpft8crcPUOcR
YIkYoDPamGSGwfGCINetnh5ttTzjxa1X/FYfNtcy/FLEUUN61TmqVwoCdElLzVUz
AXDCwXXohdVJjdGobDOF5j0tuk3IkiBIwzyDVBUafZDSEOf0l5dLKzd0TaDP3z5H
yiIbk0AkvvLseHAQCQKCJJWLA9BOab/LandE7Rq8WtnrdC/JeCD55kFKJug1a2A/
bndImUrR0qtxR28hwTty
=YTTi
-----END PGP SIGNATURE-----

------------------------------------------------------------------------
------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
from 
the latest Intel processors and coprocessors. See abstracts and register
>
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clk
trk
_______________________________________________
libopendbx-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libopendbx-devel
http://www.linuxnetworks.de/doc/index.php/OpenDBX