Problem with establishing connect using client 3.0.2.32708 to server 4.0.0.572
--
Key: CORE-5508
URL: http://tracker.firebirdsql.org/browse/CORE-5508
Project: Firebird Core
Being still on Fb 2.5, my voice is rather error-prone, but I'm definitely
outside the development team.
It would confuse me if things worked like Vlad expects. Suppose the query
was "select * from t where ID between 1 and 2", then I would ask myself why
record 1 changed value when record 2
On 24/03/17 08:50, Svein Erling Tysvær wrote:
> I would expect changing defaults for fields that didn't have a default
> when records were inserted and that haven't explicitly received any
> value since, to be something that isn't all too common. Normally, I
> would expect running an "update T set
24.03.2017 02:29, Mark Rotteveel wrote:
> To me the behavior described under "actual" intuitively sounds like the
> correct behavior. Why do you expect that the column value would change
> to 'ABC'?
This is really a tricky case. The "replace non-existing value with the
default one" hack is a
24.03.2017 7:53, Vlad Khorsun wrote:
> 24.03.2017 1:29, Mark Rotteveel wrote:
...
>> The column was created with a default, which means that existing rows will
>> get that value,
>
>Engine doesn't assing values to a new field, i.e. there is no implicit
> UPDATE of
> the existing records.
On 03/24/17 06:25, Adriano dos Santos Fernandes wrote:
> Em 23/03/2017 20:29, Mark Rotteveel escreveu:
>> To me the behavior described under "actual" intuitively sounds like the
>> correct behavior. Why do you expect that the column value would change
>> to 'ABC'?
>>
>> The column was created with
24.03.2017 09:33, Vlad Khorsun wrote:
>
>> Firebird is known to upgrade the record format while reading. "Upgrade"
>> here means using the latest (aka current) format. The current format is
>> the one that can be seen in RDB$RELATION_FIELDS. So one may expect that
>> the default value to be used
Hi!
I expect form the FB engine to return the default value at INSERT/UPDATE
TIME, not the current default value. So default values should be kept in
the rdb$format table, because versioning is needed.
On 2017.03.24. 8:18, Dmitry Yemanov wrote:
> 24.03.2017 09:33, Vlad Khorsun wrote:
>>>
24.03.2017 6:53, Vlad Khorsun wrote:
>Engine doesn't assing values to a new field, i.e. there is no implicit
> UPDATE of
> the existing records. This is strong point of the engine, btw.
Is it possible that in your testcase sweep performed implicit update between
DDLs?
--
WBR, SD.
24.03.2017 10:50, Svein Erling Tysvær wrote:
> Being still on Fb 2.5, my voice is rather error-prone, but I'm definitely
> outside the development team.
Being long-time Firebird user your voice is very important for us
> It would confuse me if things worked like Vlad expects. Suppose the
24.03.2017 12:28, Dimitry Sibiryakov wrote:
> 24.03.2017 10:29, Vlad Khorsun wrote:
>>Not sure i understand what you mean but sweep never updates records.
>
>My knowledge of Firebird is overestimated, you know. Isn't there an
> internal routine
> that converts records into the latest
24.03.2017 10:29, Vlad Khorsun wrote:
>Not sure i understand what you mean but sweep never updates records.
My knowledge of Firebird is overestimated, you know. Isn't there an internal
routine
that converts records into the latest format whenever it reads them?
--
WBR, SD.
It's been a long time, but I think that's an ancient behavior that Jim and I
argued about many years ago. Maybe even in Rdb$ELN, InterBase's ancestor.
Unless my memory fails me (again) the internal format rectifier doesn't go
through all intermediate formats, it just converts from the stored
Em 23/03/2017 20:29, Mark Rotteveel escreveu:
>
> actual
>
> ID DESCRF1
>
>1 No F1 field XYZ
>2 F1 field, default XYZXYZ
>3
Em 24/03/2017 03:33, Vlad Khorsun escreveu:
>
>Another example - i add not null column with wrong default value and
> going to correct this wrong default value. Should i update whole table
> to do it ?
>
Drop the column and recreate it, fixing your error.
>> From another side, storing
gbak: ERROR:table id is not defined
-
Key: CORE-5509
URL: http://tracker.firebirdsql.org/browse/CORE-5509
Project: Firebird Core
Issue Type: Bug
Components: GBAK
Affects
24.03.2017 15:58, Adriano dos Santos Fernandes пишет:
> Em 23/03/2017 20:29, Mark Rotteveel escreveu:
>
>>
>> actual
>>
>> ID DESCRF1
>>
>>1 No F1 field XYZ
>>
Em 24/03/2017 04:18, Dmitry Yemanov escreveu:
>
> Also, lets consider this:
>
> SQL> create table t (col1 int);
> SQL> insert into t values (1);
> SQL> commit;
> SQL> alter table t add col2 int default 123 not null;
> SQL> select * from t;
>
> COL1 COL2
>
24.03.2017 17:57, Alex Peshkoff wrote:
> On 03/24/17 17:53, Vlad Khorsun wrote:
>
>> So far we have no agreement on what is "correct result". Current
>> implementation
>> changed well known old behaviour not claiming it as a bug. I'd say it looks
>> like
>> a bug itself.
>
> Vlad, looking at
24.03.2017 17:12, Adriano dos Santos Fernandes wrote:
...
> Looks like you do not understand how it works. Re-read thread "Adding
> NOT NULL fields with DEFAULT" from 2009.
That thread contains more details, thanks for recall it.
>>> Correct result is priority, and current implementation
24.03.2017 19:39, Alex Peshkoff wrote:
> On 03/24/17 20:26, Vlad Khorsun wrote:
>> 24.03.2017 17:57, Alex Peshkoff wrote:
>>> On 03/24/17 17:53, Vlad Khorsun wrote:
>>>
So far we have no agreement on what is "correct result". Current
implementation
changed well known old
24.03.2017 17:08, Adriano dos Santos Fernandes wrote:
> Em 24/03/2017 11:58, Vlad Khorsun escreveu:
>>> Well, actually seems we do not known why you started this topic mixing
>>> implementation details with users behaviour.
>>
>>Because you left blr filter for rdb$format broken and i going to
24.03.2017 14:02, Ann Harrison wrote:
> It's been a long time, but I think that's an ancient behavior that Jim and I
> argued about many years ago.
> Maybe even in Rdb$ELN, InterBase's ancestor.
>
> Unless my memory fails me (again) the internal format rectifier doesn't go
> through all
On 03/24/17 20:26, Vlad Khorsun wrote:
> 24.03.2017 17:57, Alex Peshkoff wrote:
>> On 03/24/17 17:53, Vlad Khorsun wrote:
>>
>>> So far we have no agreement on what is "correct result". Current
>>> implementation
>>> changed well known old behaviour not claiming it as a bug. I'd say it looks
On 2017-03-24 07:26, Vlad Khorsun wrote:
> 24.03.2017 7:53, Vlad Khorsun wrote:
>> 24.03.2017 1:29, Mark Rotteveel wrote:
> ...
>>> The column was created with a default, which means that existing rows
>>> will get that value,
>>
>>Engine doesn't assing values to a new field, i.e. there is
24.03.2017 21:36, Lester Caine wrote:
> On 24/03/17 17:57, Vlad Khorsun wrote:
>>> What must be done is specified exactly. And we should suppose that in
>>> all other aspects data stored in database should not be changed -
>>What data is *stored* ?
>
> For any field, the data that is loaded
On 24/03/17 17:57, Vlad Khorsun wrote:
>> What must be done is specified exactly. And we should suppose that in
>> all other aspects data stored in database should not be changed -
>What data is *stored* ?
For any field, the data that is loaded initially or later modified. And
I REPEAT ... if
On 2017-03-24 21:14, Mark Rotteveel wrote:
> To me 2ii) means that the behaviour should be that the newly added
> column **has** the value of the default clause, this can also be
> inferred from 11.5 .
>
> And I think clause 4 is relevant:
>
> """
> 4) In all other respects, the specification of
On 24/03/17 21:42, Vlad Khorsun wrote:
> 24.03.2017 21:36, Lester Caine wrote:
>> On 24/03/17 17:57, Vlad Khorsun wrote:
What must be done is specified exactly. And we should suppose that in
all other aspects data stored in database should not be changed -
>>>What data is *stored* ?
On 24/03/17 15:12, Adriano dos Santos Fernandes wrote:
>> Current implementation
>> changed well known old behaviour not claiming it as a bug. I'd say it looks
>> like
>> a bug itself.
>>
> Changed a bugged design/implementation since 2009. Looks a bit late to
> say this.
I'm still running FB1.5
On 03/24/17 17:53, Vlad Khorsun wrote:
> So far we have no agreement on what is "correct result". Current
> implementation
> changed well known old behaviour not claiming it as a bug. I'd say it looks
> like
> a bug itself.
Vlad, looking at sql2008 (part2, foundation, 11.10 - alter table
Em 24/03/2017 11:15, Vlad Khorsun escreveu:
> 24.03.2017 15:58, Adriano dos Santos Fernandes пишет:
>> Em 23/03/2017 20:29, Mark Rotteveel escreveu:
>>
>>>
>>> actual
>>>
>>> ID DESCRF1
>>>
>>>
Em 24/03/2017 11:53, Vlad Khorsun escreveu:
> 24.03.2017 16:31, Adriano dos Santos Fernandes wrote:
>
>> Or better, increase the record format count, which seems as a stupid limit.
>
>It is really better. Are you have smart idea ?
>
>> From another side, storing the default value
Em 24/03/2017 11:19, Vlad Khorsun escreveu:
> 24.03.2017 16:03, Adriano dos Santos Fernandes wrote:
>> Em 24/03/2017 03:33, Vlad Khorsun escreveu:
>>
>>>
>>>Another example - i add not null column with wrong default value and
>>> going to correct this wrong default value. Should i update whole
Em 24/03/2017 06:44, Vlad Khorsun escreveu:
>
>I prefer to see it works this way. Probably read-committed tx could return
> new default value.
>
Not only it is in no way intuitive, it would be impossible to use indexes.
Adriano
PS: still trying to understand why you want to change a
Em 24/03/2017 11:58, Vlad Khorsun escreveu:
>> Well, actually seems we do not known why you started this topic mixing
>> implementation details with users behaviour.
>Because you left blr filter for rdb$format broken and i going to fix it
> and start palying with default values.
>
Where is
Hello Ann,
On first sight, I'd say your first list of records is a list with the
correct values. But, given that the new 'default value' isn't stored, but
applied on reading the record, this fails when the default is modified,
right?
Would it be correct to say that when adding a new non-null
24.03.2017 16:03, Adriano dos Santos Fernandes wrote:
> Em 24/03/2017 03:33, Vlad Khorsun escreveu:
>
>>
>>Another example - i add not null column with wrong default value and
>> going to correct this wrong default value. Should i update whole table
>> to do it ?
>>
>
> Drop the column and
24.03.2017 16:31, Adriano dos Santos Fernandes wrote:
> Or better, increase the record format count, which seems as a stupid limit.
It is really better. Are you have smart idea ?
> From another side, storing the default value inside the format is a
> smart hack that allows to avoid
>
> Note value of the field F1 at the first record: it is expected that is should
> be the same as latest DEFAULT value.
> Also note that 2nd and 3rd INSERTs assigns correct value to the omitted field
> - same as latest DEFAULT value.
If you re-read thread "Adding NOT NULL fields with DEFAULT"
24.03.2017 16:37, Adriano dos Santos Fernandes wrote:
> Em 24/03/2017 11:15, Vlad Khorsun escreveu:
>> 24.03.2017 15:58, Adriano dos Santos Fernandes пишет:
>>> Em 23/03/2017 20:29, Mark Rotteveel escreveu:
>>>
actual
ID DESCRF1
24.03.2017 16:34, Adriano dos Santos Fernandes wrote:
> Em 24/03/2017 06:44, Vlad Khorsun escreveu:
>
>>
>>I prefer to see it works this way. Probably read-committed tx could
>> return new default value.
>>
>
> Not only it is in no way intuitive, it would be impossible to use indexes.
42 matches
Mail list logo