Tony Whyman wrote 26.11.2021 18:01:
Note that only if FGoToFirstRecordOnExecute is true will the returned values be
available immediately.
Which (accidentally) is default and has no sense to be changed ever.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
That code is very legacy and dates from a time when Update..Returning
did not exist.
Actually, it works the same as the modern version. My point was about
what the user expects. If you execute an Update...Returning with the
code you pasted in below, with Firebird 4.0.0 it drops through the
On 26-11-2021 17:13, Tony Whyman wrote:
On 26/11/2021 15:43, Dimitry Sibiryakov wrote:
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
Tony Whyman wrote 26.11.2021 17:13:
Legacy code can often appear "insane" with the benefit of hindsight. The problem
is that it exists and it is your starting point. You don't break it without good
reason.
Ok, here is legacy code from TIBSQL.ExecQuery:
case FSQLType of
SQLSelect:
26.11.2021 17:47, Tony Whyman wrote:
3. IBX tries to be general purpose and so prepares a statement, then
checks the statement type, and then calls the appropriate IStatement
method.
Then it shouldn't be broken. It gets isc_info_sql_stmt_select, calls
openCursor() and everything works as
On 26/11/2021 15:43, Dimitry Sibiryakov wrote:
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...
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
On 26-11-2021 16:32, Tony Whyman wrote:
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...
The change was done in a way that code looking at
On 26-11-2021 10:10, Dmitry Yemanov wrote:
Mark et al,
Yes, I think that is perfectly acceptable for an initial version.
Scrollable cursors are a bit of an oddity anyway, but having
scrollable cursors in embedded access, but not in remote access is
IMHO less acceptable than bad performance.
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.
Dimitry Sibiryakov wrote 26.11.2021 16:01:
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
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
On 11/26/21 5:47 PM, Tony Whyman wrote:
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
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
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
On 26/11/2021 14:16, Dimitry Sibiryakov wrote:
Tony Whyman wrote 26.11.2021 15:10:
This caused an error message to be generated because only a singleton
row was expected and not a cursor.
Well, all I can say is that "existing connectivity drivers do not
support this feature automagically".
Tony Whyman wrote 26.11.2021 15:10:
This caused an error message to be generated because only a singleton row was
expected and not a cursor.
Well, all I can say is that "existing connectivity drivers do not support this
feature automagically". Is it really then intended behaviour for
When testing out Dimtry's recent fix for scrollable cursors (adding
support for the remote protocol), I ran the full IBX test suite on the
current "master" branch. This flagged up a backwards compatibility issue
with "Update...Returning".
When the statement:
'Update Employee Set Hire_Date =
26.11.2021 14:51, Tony Whyman wrote:
Just compiled the updated master branch and tested with IBX. All looks
good with the test suite returning the same set of results for bot
remote and local databases.
Many thanks for the good work.
And my thanks to you for testing ;-)
I've noticed that
Dimtry,
Just compiled the updated master branch and tested with IBX. All looks
good with the test suite returning the same set of results for bot
remote and local databases.
Many thanks for the good work.
I've noticed that the ODS is now 13.1 compared with 13.0 for Firebird
4.0.0. Is this
Mark et al,
Yes, I think that is perfectly acceptable for an initial version.
Scrollable cursors are a bit of an oddity anyway, but having scrollable
cursors in embedded access, but not in remote access is IMHO less
acceptable than bad performance. As long as the performance behaviour is
21 matches
Mail list logo
