Re: [Firebird-devel] Different collation ID for alteredcomputedcolumn

2015-09-14 Thread Jiří Činčura
> If a tool has a problem with that, tell the author to enhance it. The Where can I ask for isql to be fixed - either disallowing generated domains or showing proper output? ;) This is definitely interesting edge case, so I just thought I'll share it. I does not corrupt database do it's not crit

[Firebird-devel] [FB-Tracker] Created: (CORE-4934) Different collation ID for altered computed column

2015-09-14 Thread Jiri Cincura (JIRA)
Different collation ID for altered computed column -- Key: CORE-4934 URL: http://tracker.firebirdsql.org/browse/CORE-4934 Project: Firebird Core Issue Type: Bug Affects Versions: 2.5.4

[Firebird-devel] [FB-Tracker] Created: (CORE-4933) Add better transaction control to isql

2015-09-14 Thread Helen Borrie (JIRA)
Add better transaction control to isql -- Key: CORE-4933 URL: http://tracker.firebirdsql.org/browse/CORE-4933 Project: Firebird Core Issue Type: New Feature Components: ISQL Environment:

Re: [Firebird-devel] SET TRANSACTION in isql

2015-09-14 Thread Claudio Valderrama C.
> -Original Message- > From: Mark Rotteveel [mailto:m...@lawinegevaar.nl] > Sent: Lunes, 14 de Septiembre de 2015 16:54 > > Personally, I'd expect the previously used transaction > options to be used until a new explicit set transaction is executed. I think there's a confusion between S

Re: [Firebird-devel] SET TRANSACTION in isql

2015-09-14 Thread Mark Rotteveel
IIRC, set transaction is local to isql, and is parsed to determine the actual tpb to use. He uses set transaction , which starts the transaction with the specified options. If you then commit and execute another query, then a new transaction is started implicitly. This transaction - apparently -

Re: [Firebird-devel] SET TRANSACTION in isql

2015-09-14 Thread Dimitry Sibiryakov
14.09.2015 21:22, Helen Borrie wrote: > Could some isql boffin confirm, or explain? isql does not start transaction itself. It just send SET TRANSACTION query to server as is. Server don't use any kind of "history of session", so it can use only these flags that are set in command itself. T

[Firebird-devel] SET TRANSACTION in isql

2015-09-14 Thread Helen Borrie
A series of questions from a newbie in firebird-support prompted me to try and reproduce his results. He is trying to chart the effects of READ WRITE READ COMMITTED transactions in two simultaneous isql sessions, with and without WAIT and RECORD_VERSION. His theory was that using SET TRANSACTIO

Re: [Firebird-devel] Different collation ID for alteredcomputedcolumn

2015-09-14 Thread Claudio Valderrama C.
> -Original Message- > From: Jirí Cincura [mailto:j...@cincura.net] > Sent: Lunes, 14 de Septiembre de 2015 11:30 > > The resulting "show domain" produces different results. Which is at > least confusing. You never do show domain under normal circumstances. You do show domain or show

Re: [Firebird-devel] Different collation ID for altered computedcolumn

2015-09-14 Thread Jiří Činčura
On Mon, Sep 14, 2015, at 16:17, Claudio Valderrama C. wrote: > Ok, then I'm interested in the final effect: can you show a bug that > appears > because the value is stored in both the table's field and the domain? > There > may be such a bug after all. Not bug exactly, but have a look: SQL> CREAT

Re: [Firebird-devel] Different collation ID for altered computedcolumn

2015-09-14 Thread Claudio Valderrama C.
> -Original Message- > From: Jirí Cincura [mailto:j...@cincura.net] > Sent: Lunes, 14 de Septiembre de 2015 1:45 > > I'm not interested in actual value. I'm just wondering why the two > values differ after alter, given the alter changed nothing. You were looking in the wrong place, remem

Re: [Firebird-devel] [NO] RECORD_VERSION

2015-09-14 Thread Helen Borrie
At 08:28 p.m. 14/09/2015, Vlad Khorsun wrote: > NO RECORD_VERSION is the default for READ COMMITTED and it was not changed > since FB 0.x times. >I.e. if TPB containts "isc_tpb_read_committed" tag and contains nor >isc_tpb_rec_version, nor >isc_tpb_no_rec_version, engine will create READ COMMI

Re: [Firebird-devel] [NO] RECORD_VERSION

2015-09-14 Thread Jiří Činčura
On Mon, Sep 14, 2015, at 10:28, Vlad Khorsun wrote: > PS Some client access components/drivers have its own defaults. That was Dmitry Kuzmenko's wild ride 3-4 years back. ;) -- Mgr. Jiří Činčura Independent IT Specialist -

Re: [Firebird-devel] [NO] RECORD_VERSION

2015-09-14 Thread Vlad Khorsun
14.09.2015 11:00, Helen Borrie wrote: > According to both editions of The Firebird Book, for read/write read > committed transactions, RECORD_VERSION is the default. > According to the Firebird 2.5 Language Reference, NO RECORD_VERSION is the > default. > > So - which is it? Did it change at s

[Firebird-devel] ADO.NET provider 4.8.0.0

2015-09-14 Thread Jiří Činčura
More info http://blog.cincura.net/233530-ado-net-provider-4-8-0-0-for-firebird-is-ready/ . -- Mgr. Jiří Činčura Independent IT Specialist -- Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/li

Re: [Firebird-devel] [NO] RECORD_VERSION

2015-09-14 Thread Mark Rotteveel
On 14-9-2015 10:00, Helen Borrie wrote: > According to both editions of The Firebird Book, for read/write read > committed transactions, RECORD_VERSION is the default. According to the > Firebird 2.5 Language Reference, NO RECORD_VERSION is the default. > > So - which is it? Did it change at so

[Firebird-devel] [NO] RECORD_VERSION

2015-09-14 Thread Helen Borrie
According to both editions of The Firebird Book, for read/write read committed transactions, RECORD_VERSION is the default. According to the Firebird 2.5 Language Reference, NO RECORD_VERSION is the default. So - which is it? Did it change at some point? If so, at which release/sub-release?