Issue Details (XML | Word | Printable)

Key: CORE-3315
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Vlad Khorsun
Reporter: Anderson Farias
Votes: 0
Watchers: 0

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

Audit plugin records a sencond *FAILED* EXECUTE_STATEMENT_FINISH after a "normal" one

Created: 21/Jan/11 03:43 PM   Updated: 18/Jan/16 05:08 PM
Component/s: Engine
Affects Version/s: 2.5.0
Fix Version/s: 2.5.1, 3.0 Alpha 1

File Attachments: 1. Zip Archive (81 kB)

Environment: Firebird 2.5 RC3 32bits SC on Windows Server 2003, Firebird 2.5.0 Final 64bits SC on Windows 7

QA Status: No test

 Description  « Hide
Got an ancient database from fb 1.5 and converted to 2.5.

When testing it I've found "duplicated" EXECUTE_STATEMENT_FINISH being the second one a FAILED.

Than I discovered later the "duplicated" it's not duplicated at all, it happens after fetching [all] records. The thing is, there's no EXCEPTION or ERROR at all, nor executing the statement neither fetching records. The tables and data seems to be just fine.

So, why the "failed" message?

I've created a new database with only one table with the same structure and data of one of the "troubled" tables and I'm attaching so you can reproduce this behavior.


1) download the attached zip and extract the db file
2) create an alias pointing to the db file and setup audit on it on you fbtrace.conf file
3) attach to the alias using a preffered client (I've tested using ISQL and FlameRobin)
4) execute a simple "SELECT * FROM CONFIGURACOES_SIG"
5) make sure you FETCH ALL records and commit
6) look at your audit log file

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 28/Jan/11 09:28 AM
The cause of "FAILED EXECUTE_STATEMENT_FINISH" event is batching logic built-into network client.
Client asks server for a next batch of records before it (client) fully processed current batch. This is pre-fetch feature.
Therefore it is possible that next batch will be asked despite of End-Of-Stream marker alredy present in current batch.
Network server tried to fetch record, engine returns isc_sync error and this is the reason for trace to generate "FAILED EXECUTE_STATEMENT_FINISH" event.
Note, network client aware of this logic and corresponding isc_sync errors not shown to the application.

Vlad Khorsun added a comment - 28/Jan/11 10:29 AM
Fix is frontported into v3

Anderson Farias added a comment - 28/Jan/11 11:50 AM
Great! THANKS Vlad. BTW, this feature -- audit and trace -- is fantastic!! I don't know how we lived without it! ;)