[Firebird-devel] [FB-Tracker] Reopened: (CORE-2553) Grants access on generators (gen_id, next value for)

2015-05-31 Thread Pavel Zotov (JIRA)
[ http://tracker.firebirdsql.org/browse/CORE-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Zotov reopened CORE-2553: --- Reopen ticket - see my issue of 09/May/15 09:39 PM. Currently (WI-T3.0.0.31846) its all the same: C:\FBT

[Firebird-devel] [FB-Tracker] Created: (CORE-4822) Force optimizer to consider usage of MERGE JOIN when data sources are joined on USING() or by NATURAL clauses (related to 2.5 only)

2015-05-31 Thread Pavel Zotov (JIRA)
Force optimizer to consider usage of MERGE JOIN when data sources are joined on USING() or by NATURAL clauses (related to 2.5 only) Key: CORE-4

Re: [Firebird-devel] Moving Jaybird auto-commit implementation into Firebird

2015-05-31 Thread Dmitry Yemanov
31.05.2015 12:33, Dimitry Sibiryakov wrote: > Prepared statements are not bound to a transaction, they (and I believe their > existence > locks) exists till explicitly unprepared/freed or connection ends. Existence locks are bound to *both* statement and transaction lifetime. Dmitry

Re: [Firebird-devel] Moving Jaybird auto-commit implementation into Firebird

2015-05-31 Thread Dimitry Sibiryakov
31.05.2015 9:17, Mark Rotteveel wrote: > On 30-5-2015 21:54, Maxim Smyatkin wrote: >> Yes, it makes sence. I was wrong as the procedure still depends on the >> table, so it's the intented behaviour. But what I still can't understand >> is why did it work before? I mean, old tests were using Jaybird

[Firebird-devel] [FB-Tracker] Reopened: (CORE-4618) Rollback doesn`t undo changes when MERGE statement updates the same target rows multiple times and PLAN MERGE is used

2015-05-31 Thread Pavel Zotov (JIRA)
[ http://tracker.firebirdsql.org/browse/CORE-4618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Zotov reopened CORE-4618: --- WI-T3.0.0.31846: result is the same as in my issue of 08/Jan/15 03:01 PM (WI-T3.0.0.31532). Ticket should

Re: [Firebird-devel] Semantics of isc_tpb_autocommit

2015-05-31 Thread Mark Rotteveel
On 30-5-2015 17:13, Vlad Khorsun wrote: >> I'd especially like to know at which point the commit is executed, and >> the impact this has on open resources (cursor, blob, etc). As far as I >> understand commit_retaining is used. What impact does that have on >> visibility of transactions and resourc

Re: [Firebird-devel] Semantics of isc_tpb_autocommit

2015-05-31 Thread Mark Rotteveel
On 30-5-2015 16:48, Dmitry Yemanov wrote: > Autocommit is executed at the end of every execute/fetch DSQL API call > and every start/send/receive/transact BLR API call, and *only* if that > API call modified some data or posted some event. > > As a side effect, this means that a select from a store

Re: [Firebird-devel] Moving Jaybird auto-commit implementation into Firebird

2015-05-31 Thread Mark Rotteveel
On 30-5-2015 21:54, Maxim Smyatkin wrote: > Yes, it makes sence. I was wrong as the procedure still depends on the > table, so it's the intented behaviour. But what I still can't understand > is why did it work before? I mean, old tests were using Jaybird's > AutoCommitTransaction which is just a w