On Tue, Oct 19, 2010 at 08:59:19AM +0100, Martin J. Evans wrote:
> On 18/10/10 22:54, Tim Bunce wrote:
> > On Mon, Oct 18, 2010 at 04:45:51PM +0100, Martin J. Evans wrote:
> >>
> >> State 23000 you are getting is "Integrity constraint violation" which is
> >> an error but note the text on the end of the error you are getting:
> >>
> >> "[state was 23000 now 01000]"
> >>
> >> 01000 is a general warning. I don't understand why the "now 01000" in the
> >> text of the error.
> >
> > "[state was 23000 now 01000]" looks like the behaviour of the set_err
> > method: http://search.cpan.org/~timb/DBI/DBI.pm#set_err
>
> Of course, I always forget that.
>
> > It looks like state 23000 was recorded but then updated to 01000 by a
> > separate event. But, looking at the internal code for set_err_sv,
> > I see that message might get appended even if the code then decides not
> > to change the err value.
Which is probably a bug.
> > You could use something like $h->{HandleSetErr} = sub { warn "@_"; return
> > 0; }
> > to see the second event getting recorded.
>
> All drivers I've tried this with report 2 things. The 23000 error for the
> insert of a null into a column which does not allow nulls (the tds_error
> packet) then a 01000 informational (tds_info) which states the statement has
> been terminated.
>
> However, it does not get around the fact that SQLExecute is returning
> SQL_SUCCESS_WITH_INFO with the broken driver. DBD::ODBC uses the SQLExecute
> return to determine if the execute was successful or not (as per the ODBC
> docs) and not the state of any error it sees when recovering details of the
> errors and informationals.
>
> I suppose this could be changed but it would need additional logic everywhere
> "if (SQL_SUCCEEDED(ret))" is called and some way of recording the states it
> has seen since the last ODBC call. I'm not keen on doing that and not only
> because the driver in this case is broken.
I agree.
Tim.
p.s. Thanks for the doc patch.
> > Tim.
> >
> >> So something is a amiss there. Having said that the MS native client
> >> reports the same error but SQLExecute returns SQL_ERROR.
> >>
> >> As far as I am concerned (and I've written ODBC drivers and code to ODBC
> >> Drivers for more years than I care to admit) the condition you have hit is
> >> an error and when SQLError is called an error number, state and text is
> >> returned BUT the call to SQLExecute is returning SQL_SUCCESS_WITH_INTO
> >> instead of SQL_ERROR. I've read your comment from the Microsoft guy but I
> >> don't believe it and in any case I have 1 of their drivers which behaves
> >> differently than the one you've got.
> >>
> >> Martin
> >> --
> >> Martin J. Evans
> >> Easysoft Limited
> >> http://www.easysoft.com
> >>
>
> Martin
> --
> Martin J. Evans
> Easysoft Limited
> http://www.easysoft.com
>
