Pantek Library
Hosting Provided By
CybrHost
High Speed Hosting

RE: Expose errnum() in query -- BadQuery w/Errnum patch part 3

From: Jim Wallace <jwallace(at)kaneva.com>
Date: Thu Oct 25 2007 - 10:52:52 EDT


That's correct, you can't reproduce the problem unless there's a sql call between the exception and your call to errnum(), which occurs on the rollback of a transaction. If you run the deadlock tests, it demonstrates it.

> -----Original Message-----
> From: Warren Young [mailto:mysqlpp@etr-usa.com]
> Sent: Thursday, October 25, 2007 9:16 AM
> To: MySQL++ Mailing List
> Subject: Re: Expose errnum() in query -- BadQuery w/Errnum
> patch part 3
>
> Jim Wallace wrote:
> > + /// If you want the string *and* number you must
> > + /// call errnum() before calling error() since error() clears
>
> I tried to replicate that by causing an error in one of the
> examples, then calling Connection::errnum(), then error(),
> then errnum() again, and it shows the same number both times.
>
> I think this is just leftover confusion from your initial
> problem diagnosis process. It's not mysql_error() clearing
> the error number, it's the second error caused by the
> transaction failure.
>
> --
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe:
> http://lists.mysql.com/plusplus?unsub=jwallace@kaneva.com
>
>
>

-- 
MySQL++ Mailing List
For list archives: 
http://lists.mysql.com/plusplus
To unsubscribe:    
http://lists.mysql.com/plusplus?unsub=lists@pantek.com
Received on Thu Oct 25 10:52:53 2007

This archive was generated by hypermail 2.1.8 : Fri Jul 04 2008 - 00:21:42 EDT


Contact Us  Legal Notices  Order Services Online 
Pantek Home  Privacy Policy  IT news  Site Map  Pantek Library