Hi,
(2013/03/19 7:25), Heikki Linnakangas wrote:
> If you SQLPrepare a query, and bind a VARCHAR parameter with column_size
> of exactly 5, and you have BoolsAsChar=1 (which is the default), the
> subsequent SQLExecute will return 0 rows.
>
> With those conditions, HowToPrepareBeforeExec returns shouldExec, which
> means that the query is sent to the server to be parse, in a Parse
> message. PGAPI_Execute() calls HowToPrepareBeforeExec, and calls
> prepareParameters(), which sends the Parse message, and reads the
> resulting ParameterDescription messages from the server. It also creates
> a new QResultClass object, and stores it as the statement's result. Now,
> when PGAPI_Execute() proceeds to execute the statement for real, it
> doesn't clear the dummy result set created by prepareParameters(), but
> just appends the real result set to the statement object's chain of
> results. When SQLExecute() returns, the first result set (the one that
> the application cares about) is the dummy one, with 0 rows.
>
> As a quick fix, but which I believe is quite safe and correct anyway, is
I don't think it's safe.
It's in the middle of handling an array of parameter set and may
go back to next_param_row label.
In addtion, apps may get out of PGAPI_Execute() in the middle of
paramater handling when there are data at execution parameters.
> to always clear any existing result sets in PGAPI_Execute() before
> actually executing the query. Normally, there shouldn't be any result
> sets, so clearing is harmless. In this buggy corner, case it clears the
> dummy result set, fixing the problem.
>
> Attached is a patch to fix that. As usual, this is also present in my
> github repository at https://github.com/hlinnaka/psqlodbc/, as well as a
> test case in the master-with-testcases branch.
>
> - Heikki