Re: SQLExecute returns 0 rows with BoolsAsChar=1

(2013/03/20 22:04), Heikki Linnakangas wrote:
> 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.

The statement may be executed many (at most parameter set array size)
times in the current implementation.

> 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.