What you appear to be saying is that you have changed/expanded the
semantic of Update...Returning, changed the SQL Statement type returned
and then not expected the change to break any existing code...
On 26/11/2021 15:01, Dimitry Sibiryakov wrote:
Tony Whyman wrote 26.11.2021 15:28:
3. Prior to calling IStatement.Execute, the statement type is
checked. The current (IBX) code raises an exception if the sql
statement type is isc_info_sql_stmt_select in order to stop the wrong
IStatement method being called.
So it is actually the test suite that makes (now wrong) assumption
that UPDATE...RETURNING has to be described as
isc_info_sql_stmt_exec_procedure is wrong.
But it used to be the correct assumption.
3. IBX tries to be general purpose and so prepares a statement, then
checks the statement type, and then calls the appropriate IStatement
method. Changing the statement type semantics broke the logic used to
determine which method to call.
That's why the change. IBX should check the statement type (which
now is isc_info_sql_stmt_select) and call appropriate method i.e.
openCursor(). What's wrong?
The problem is in TIBSQL. This is a class that goes all the way back to
Borland days. It has a common method "ExecQuery" that is called
regardless of the statement type. If it is used to open a cursor, then
the user either has to set the GoToFirstRecordOnExecute property to
ensure that the cursor is automatically positioned on the first row, or
explicitly call "Next". If a singleton row is expected then there is no
need to do either of the above. Right now, I am not sure how this
behaviour can be maintained (and not get inundated by users complaining
that their code is broken) without being able to tell the difference
between an Update...Returning that returns a singleton row from one that
returns a cursor.
4. With reference to item 1 above, if "Update..Returning" returns a
statement type of isc_info_sql_stmt_select then you _do_ have to also
parse the statement in IBX so that you know its an UPDATE and
IStatement.execute has to be called instead of IStatement.openCursor.
No, openCursor() must be called here, not execute().
Which is, of course, new behaviour.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
