Re: Bug in the SQLGetDiagRec function of psqlodbc

From: PSequel Support <support(at)psequel(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: pgsql-odbc(at)postgresql(dot)org
Subject: Re: Bug in the SQLGetDiagRec function of psqlodbc
Date: 2015-09-19 05:30:10
Message-ID: CABqkTWRB5ewY64PKSCeYq+mN2+qcS_kqcQ=btZ7J4QzNz_KeHQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

Cool! That works!

On Thu, Sep 17, 2015 at 11:32 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
wrote:

> On 09/18/2015 08:13 AM, PSequel Support wrote:
>
>> Thanks for your reply! Actually I've tried calling SQLFreeStmt after each
>> query, but it doesn't seem to change anything. See the example code below.
>>
>> #include <stdio.h>#include <sql.h>#include <sqlext.h>
>> void printError(SQLHANDLE handle) {
>> char message[256];
>> SQLSMALLINT i = 0;
>> while (SQLGetDiagRec(SQL_HANDLE_DBC, handle, ++i, NULL, NULL,
>> (SQLCHAR*)message, sizeof(message), NULL) != SQL_NO_DATA) {
>> printf("%s\n", message);
>> }}
>> ...
>>
>
> Oh, you're getting the diagnostic from the *connection* handle, not the
> statement handle. According to the documentation of SQLExecDirect(), it
> sets the diagnostics on the statement handle.
>
> I agree that psqlODBC's behaviour here is pretty strange, and probably
> incorrect. I wouldn't expect SQLExecDirect to set any diagnostics on the
> connection handle, at least for a syntax error. But if it does, the second
> call probably should do so as well, and overwrite the previous error
> message.
>
> But the immediate fix for your application would be to get the diagnostics
> from the statement handle instead of the connection handle.
>
> - Heikki
>

In response to

Browse pgsql-odbc by date

  From Date Subject
Next Message Andrus 2015-09-19 07:48:51 Re: How to fix buffer overrun in Windows x32
Previous Message Raiford 2015-09-18 13:02:16 Re: Unable to access model from EA Server.