Ok, my SQL isn't that expert but to find out how many were deleted you
might:
- SELECT @@ROWCOUNT as NumDeleted together with your delete statement which
would give you the number of rows deleted as a result set.
- Use a stored procedure that does that. Then you come to having to adapt
SOCI to stored procedures. Incidentally we did the outbound parameter
binding with direct SQLBind and not attempting to support it with SOCI.
Not sure about the syntax if not using a stored procedure.
On Thu, May 3, 2012 at 2:25 PM, Vadim Zeitlin <[email protected]> wrote:
> On Thu, 3 May 2012 12:08:29 +0100 Neil Morgenstern <
> [email protected]> wrote:
>
> NM> We had to modify the odbc error in our code to make it more
> descriptive,
> NM> i.e. actually give the error message in the what() text.
>
> Hello Neil,
>
> This looks like a good idea in its own right but I'm not sure how does it
> really help with my question as I definitely don't want to try parsing
> what() message to see if anything was deleted. Also, at the moment no
> exceptions are being thrown anyhow, even if nothing was deleted so, again,
> I'm not sure what do you really propose to do -- throwing an exception in
> this case doesn't look like a good idea, if only from the backwards
> compatibility point of view.
>
> NM> There are a bunch of other fixes you need to make using ODBC, which we
> got
> NM> to work with Stored Procedures (but using statement not procedure, in
> NM> particular calling SQLMoreData (I think that's the call) until you
> either
> NM> reach the end of get a column count.
>
> I'd be interested to knowing which other problems did you fix in the ODBC
> backend, do you have your changes available somewhere?
>
> NM> Calling SQLFetch is an error if there is no data, i.e. no columns, but
> is
> NM> legal if there are simply no rows.
>
> Sorry if I'm missing something here because I'm not an ODBC expert but how
> does SQLFetch() help with deleting rows from the database?
>
> Anyhow, for now my question remains whether this patch, from my original
> post, should be applied:
>
> --- 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_,
>
>
> It does solve the problem for me but I don't know how do the other backends
> behave in this case. If they do return ef_no_data, then this would seem to
> be the right thing to do for ODBC too. Does anybody know if they do?
>
> Thanks,
> 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
