We had to modify the odbc error in our code to make it more descriptive,
i.e. actually give the error message in the what() text.
I've never been that fond of the use of the type system in C++ exceptions
and prefer to throw standard ones like std::runtime_error pretty much every
time. The user doesn't care that the backend is odbc, or even that there is
a SOCI library implementation. They are making a generic database call and
if there's a try..catch it will probably be std::exception.
The only exception is when a deadlock has occurred as we want to retry the
command, so actually I added a new exception type for deadlocks and threw
that if it occurred.
There are a bunch of other fixes you need to make using ODBC, which we got
to work with Stored Procedures (but using statement not procedure, in
particular calling SQLMoreData (I think that's the call) until you either
reach the end of get a column count.
Calling SQLFetch is an error if there is no data, i.e. no columns, but is
legal if there are simply no rows.
On Thu, May 3, 2012 at 12:09 AM, Vadim Zeitlin <[email protected]> wrote:
> Hello,
>
> I'm just starting to use SOCI so sorry in advance if I'm missing something
> obvious but is there any way to detect if a "delete" SQL statement affected
> any rows? I thought that got_data() would return false if it didn't delete
> anything but at least with the ODBC backend this is not the case as it is
> always true.
>
> Looking at the code I see that odbc_statement_backend::execute() always
> returns ef_success in this case (as fetch() is not called), but is this
> really the right thing to do if the returned value is SQL_NO_DATA? Perhaps
> something like this:
>
> --- a/src/backends/odbc/statement.cpp
> +++ b/src/backends/odbc/statement.cpp
> @@ -157,6 +157,11 @@ odbc_statement_backend::execute(int number)
> SQLCloseCursor(hstmt_);
>
> SQLRETURN rc = SQLExecute(hstmt_);
> + if (SQL_NO_DATA == rc)
> + {
> + return ef_no_data;
> + }
> +
> if (is_odbc_error(rc))
> {
> throw odbc_soci_error(SQL_HANDLE_STMT, hstmt_,
>
>
> should simply be added there?
>
> And if the code is correct, is there some other way to check whether
> anything was deleted or not? get_affected_rows() is not implemented for the
> ODBC backend and I can't think of anything else.
>
> Thanks in advance for any advice!
> VZ
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Soci-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/soci-users
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Soci-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/soci-users
