|
If you were logged in you would be able to see more operations.
|
|
|
|
File Attachments:
|
1.
AUDITFAIL.zip (81 kB)
|
|
Environment:
|
Firebird 2.5 RC3 32bits SC on Windows Server 2003, Firebird 2.5.0 Final 64bits SC on Windows 7
|
|
| Planning Status: |
Unspecified
|
|
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.
STEPS TO REPRODUCE:
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
|
|
Description
|
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.
STEPS TO REPRODUCE:
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
|
Show » |
|
Bug
Closed
Minor
Audit plugin records a sencond *FAILED* EXECUTE_STATEMENT_FINISH after a "normal" one
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.