Issue Details (XML | Word | Printable)

Key: CORE-2154
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Thiago Borges
Votes: 0
Watchers: 1
Operations

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

"request synchronization error" when calling isc_dsql_sql_info with isc_info_sql_records parameter after last record fetched with "execute procedure"

Created: 27/Oct/08 04:17 PM   Updated: 08/Nov/09 08:27 PM
Component/s: API / Client Library
Affects Version/s: 2.5 Alpha 1, 2.1.1
Fix Version/s: 2.5 Beta 1

Time Tracking:
Not Specified

File Attachments: 1. Text File testit.cpp (3 kB)

Environment: Windows/VC++ 8


 Description  « Hide
I got "request syncronization error" when calling isc_dsql_sql_info after EOF was reached.

This error appear in CORE-1310, and was solved in 2.1 Beta 1 for "select * from table".
But I getting the error now running "execute procedure X(P)"

With fbclient.dll 2.0.4.13130 all seems ok.

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Thiago Borges added a comment - 27/Oct/08 04:19 PM - edited
I modified the example provided in CORE-1310 to use "execute procedure" and the error reappear.

Vlad Khorsun added a comment - 27/Oct/08 04:54 PM
> I got "request syncronization error" when calling isc_dsql_sql_info after EOF was reached.

And this is perfectly valid. What else you expected ?

Vlad Khorsun added a comment - 27/Oct/08 05:04 PM
Hmm... your test case is not correct as you must not fetch from "execute procedure" request.
Instead you must use isc_dsql_execute2 and get result row (output parameters) there

Thiago Borges added a comment - 27/Oct/08 05:09 PM
Sorry, I try to say:

The SQL command return 1 row.

The first call to isc_dsql_fetch return 0
The second returns 335544364, and not 100L. This is ok?

Vlad Khorsun added a comment - 27/Oct/08 05:19 PM
You should read at least documentation for IB6 to understand statement type and how statements of different types must be prepared and executed.
Read "Working with Dynamic SQL"\"DSQL programming methods" chapter
From this POV your code is not correct.

From another POV we may return EOF on second fetch and only after it isc_req_sync for such scenario.
I'll look for behavior of fbclient before 2.1 and came back with my conclusion

Vlad Khorsun added a comment - 28/Oct/08 07:20 AM
Conclusion is : when engine executed non-select statement, i.e. statement which have no cursor, it must disallow fetch from such statement handle.

This check will be implemented in 2.5 engine only to allow bad application work untouched with current Firebird versions.




> From another POV we may return EOF on second fetch and only after it isc_req_sync for such scenario.
Engine can't return EOF in this case as there is no cursor open

> I'll look for behavior of fbclient before 2.1 and came back with my conclusion
Before v2.1 client silently ignore isc_req_sync error if after first fetch there was no second fetch call. I consider it as a bug, fixed in v2.1.