Re: SQLExecute returns 0 rows with BoolsAsChar=1
От | Heikki Linnakangas |
---|---|
Тема | Re: SQLExecute returns 0 rows with BoolsAsChar=1 |
Дата | |
Msg-id | 5149B3C7.5030109@vmware.com обсуждение исходный текст |
Ответ на | Re: SQLExecute returns 0 rows with BoolsAsChar=1 (Hiroshi Inoue <inoue@tpf.co.jp>) |
Ответы |
Re: SQLExecute returns 0 rows with BoolsAsChar=1
|
Список | pgsql-odbc |
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
Вложения
В списке pgsql-odbc по дате отправления: