Thread: SQLGetDiagRec should not clear error.

A colleague of mine pointed out that calling SQLGetDiagRec on a
connection, after the connection has failed, clears the current error.
The consequence is that if you call SQLGetDiagRec twice, and the first
call returns an error, the second call might return no error. According
to the ODBC spec:

> Calls to SQLGetDiagRec are nondestructive to the header and record
> fields. The application can call SQLGetDiagRec again at a later time to
> retrieve a field from a record as long as no other function, except
> SQLGetDiagRec, SQLGetDiagField, or SQLError, has been called in the interim.

Digging into the commit log, the code line that clears the error message
in CC_get_error has been there since the very first commit.

I pushed a patch to fix that, removing the line in CC_get_error that
clears the error number. I also added a regression test that
demonstrates the issue.

- Heikki

On Fri, Apr 11, 2014 at 4:01 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> A colleague of mine pointed out that calling SQLGetDiagRec on a connection,
> after the connection has failed, clears the current error. The consequence
> is that if you call SQLGetDiagRec twice, and the first call returns an
> error, the second call might return no error. According to the ODBC spec:
>
>> Calls to SQLGetDiagRec are nondestructive to the header and record
>> fields. The application can call SQLGetDiagRec again at a later time to
>> retrieve a field from a record as long as no other function, except
>> SQLGetDiagRec, SQLGetDiagField, or SQLError, has been called in the
>> interim.
>
>
> Digging into the commit log, the code line that clears the error message in
> CC_get_error has been there since the very first commit.
>
> I pushed a patch to fix that, removing the line in CC_get_error that clears
> the error number. I also added a regression test that demonstrates the
> issue.
s/called again:./called again:/g
Thanks,
--
Michael