On 26/11/2021 14:32, Dmitry Yemanov wrote:
26.11.2021 17:28, Tony Whyman wrote:
1. IAttachment.prepare is used to parse 'Update Employee Set
Hire_Date = ? Where EMP_NO = ? Returning LAST_NAME'
2. IStatement.getType is then used to determine the statement type.
OK so far.
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.
Why? How is it different from SELECT returning
isc_info_sql_stmt_select? They should work the same way. Is the SQL
text also parsed to detect UPDATE and that conflicts with the returned
statement type?
Dmitry
1. This is not a backwards compatible change. If "Update...Returning"
had always been given a statement type of isc_info_sql_stmt_select then
the IBX code would have been written to support this. As it happens, it
was not and so changing the statement type immediately introduces a
backwards compatibility issue. Do you have a good reason to make this
change?
2. IStatement has different methods "execute" and "openCursor". You need
to know in advance which one to call. The former is called when you
expect a singleton row (or no output) and the latter when you expect a
cursor.
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.
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.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
