On 20.03.2013 10:56, Hiroshi Inoue wrote:
> 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.
Ah, I see.
> In addtion, apps may get out of PGAPI_Execute() in the middle of
> paramater handling when there are data at execution parameters.
Hmm, I don't think that's a problem. Even with data-at-execution
parameters, the statement is only really going to be executed once.
Until all data-at-execution parameters have filled in by the
application, PGAPI_Execute() won't actually execute the statement, it
will just return SQL_NEED_DATA. It's OK to reset the result set between
those PGAPI_Execute() calls - there shouldn't be any results yet. The
last PGAPI_Execute() call produces all the result sets.
I think we're OK if we just move the SC_set_Result call to before the
next_param_row label. Does the attached look right to you?
- Heikki
