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.
> 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.
> 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
