Issue Details (XML | Word | Printable)

Key: CORE-3730
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Jason Wharton
Votes: 0
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Firebird Core

isc_dsql_exec_immed2() loses input parameter value with RETURNING clause

Created: 15/Jan/12 06:01 PM   Updated: 27/Mar/14 12:14 PM
Component/s: Engine
Affects Version/s: 2.1.0, 2.1.1, 2.0.5, 2.1.2, 2.1.3, 3.0 Initial, 2.0.6, 2.5.0, 2.1.4, 2.5.1
Fix Version/s: 2.0.7, 2.1.5, 2.5.2, 3.0 Alpha 1

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive ExecuteImmed2_InsertWithReturningClause.zip (712 kB)

Environment: Any

Planning Status: Unspecified


 Description  « Hide
A value passed in to insert a record is lost when the RETURNING clause is used via the EXECUTE IMMEDIATE api call isc_dsql_exec_immed2().


 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Jason Wharton added a comment - 15/Jan/12 06:03 PM
This is a simple app that will cause the error to manifest.

Jason Wharton added a comment - 16/Jan/12 01:56 AM
I neglected to mention, I have one of the later daily builds of 2.5.2 installed on a 64 bit Win7 machine.

Jason Wharton added a comment - 17/Jan/12 03:49 PM
I would like to BUMP this issue a bit as it is really holding back a lot of customers and creating problems because this is the most efficient way to perform operations my component set needs. I have had others download the sample app and confirm there is indeed a problem in Firebird.

Dmitry Yemanov added a comment - 17/Jan/12 04:55 PM
It has nothing to do with the RETURNING clause per se, it should affect any statement that has both input and output parameters and being executed via isc_dsql_exec_immed2(). And this bug seems to be pretty old (inherited from InterBase). The embedded server should work correctly, BTW, as the bug resides inside the remote server code.

Jason Wharton added a comment - 17/Jan/12 05:02 PM
Interesting. I have had a history of problems with this API call. Hopefully now with your attention drawn to it you can get things tidied up. I have been waiting a LONG time to be able to rely on this API call.

Dmitry Yemanov added a comment - 17/Jan/12 05:27 PM
I have committed a fix into v2.5.2, so please test the next (tomorrow's) snapshot build and report back. Your test case now works without errors, but I'm pretty sure you have other interesting examples to try as well.

Jason Wharton added a comment - 17/Jan/12 05:37 PM
Will do! Thank you.

Jason Wharton added a comment - 18/Jan/12 06:33 PM
I tested this and it indeed appears to be resolved. THANK YOU!