Tony Whyman wrote 26.11.2021 16:32:
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...
Correction: any sane code.
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.
This behavior can be maintained exactly as it has been done: if statement
type is isc_info_sql_stmt_exec_procedure - single row is expected, if statement
type is isc_info_sql_stmt_select - multiple rows are expected. And IIRC TIBSQL's
code was written exactly like this.
No, openCursor() must be called here, not execute().
Which is, of course, new behaviour.
No, it is the old behavior. If statement type is described as select - open
cursor. If it is procedure call - get singleton.
And once again: execute() should work as well as long as UPDATE is changing
exactly one record.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
