On 18/10/10 14:58, Roode, Eric wrote: > On Monday, October 18, 2010 9:24 AM, Martin J. Evans wrote: > >> I never meant to offend you with that statement and I agreed it was an >> error. >> >> You are posting on a public list and presumably wanting feedback/help. >> I only know what you've told me, nothing else. Perhaps you might think >> about that before leaping to the conclusion you seem to have. >> >> I spent nearly one hour of my Saturday looking into the problem you >> reported so obviously I took your report seriously. >> >> Perhaps some calm is required. > > I'm sorry, I didn't mean to fly off the handle. I do appreciate any > insight you (or anyone else) can give. I'm just frustrated at what > appears to be a bug in the driver (or possibly DBD::ODBC), and am > looking for any way to work around it. > > My apologies, > -- Eric > >
I was using the Easysoft SQL Server Driver but I also tried with the MS SQL Server Drivers: sqlsrv32.dll 14/04/2008 2000.85.1132.00 sqlncli.dll 14/10/2005 2005.90.1399.00 and the first echoed your result and the second worked (i.e., execute failed). You have a newish driver but it is looking broken to me. Have you tried the native client driver (see above). You could also try calling SQLMoreResults after the execute which appears to succeed until it returns false but ensure RaiseError is on. See odbc_more_results in the pod of DBD::ODBC and t/20SqlServer.t for examples. I only say this is worth trying as normally the final result of a procedure is not known until all of the procedure has finished and you have multiple statements in your proc (but it would be at best a workaround - see below). I tried it myself with the MS SQL Server ODBC Driver above and it did not help. I also checked again the ODBC spec and the only SQL_SUCCESS_WITH_INFO returns are for statements which succeed but may have succeeded for a reason you might like to know e.g., 01003, NULL value eliminated in set function The prepared statement associated with StatementHandle contained a set function (such as AVG, MAX, MIN, and so on), but not the COUNT set function, and NULL argument values were eliminated before the function was applied. (Function returns SQL_SUCCESS_WITH_INFO.) 01004, String data right truncated etc 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. 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
