> 14.05.2014 18:10, Vlad Khorsun wrote:
>> I'd said it is really because cursor stability. Looks like top-level
>> update ignores update of record
>> with ID = 2, made by trigger.
>
> Not only this. Two new versions of the record were created instead of one
> (because
> update_in_place()
14.05.2014 18:10, Vlad Khorsun wrote:
> I'd said it is really because cursor stability. Looks like top-level
> update ignores update of record
> with ID = 2, made by trigger.
Not only this. Two new versions of the record were created instead of one
(because
update_in_place() wasn't call
> 2.5 result:
>
>> Statement failed, SQLSTATE = 22012
>> arithmetic exception, numeric overflow, or string truncation
>> -Integer divide by zero. The code attempted to divide an integer value by
>> an integer divisor of zero.
>> -At trigger 'DBL_BOOM' line: 7, col: 4
>> After line 17 in file u
14.05.2014 17:44, Vlad Khorsun wrote:
> If you really interested in answer and respect other list members, add
> results of your
> scripts here to not force others to do what you already did.
2.5 result:
> Statement failed, SQLSTATE = 22012
> arithmetic exception, numeric overflow, or st
> Hello, All.
>
> In Firebird 3.0 following script works differently from 2.5. Is it expected
> side-effect
> of cursor stability?
If you really interested in answer and respect other list members, add
results of your
scripts here to not force others to do what you already did.
Rega
>In Firebird 3.0 following script works differently from 2.5. Is it expected
> side-effect of cursor stability?
>
> create table u_dbl(id integer primary key, f integer); create index idx_dbl on
> u_dbl(f); set term ^; create trigger dbl_boom for u_dbl before update as
> declare variable a i
Hello, All.
In Firebird 3.0 following script works differently from 2.5. Is it expected
side-effect
of cursor stability?
create table u_dbl(id integer primary key, f integer);
create index idx_dbl on u_dbl(f);
set term ^;
create trigger dbl_boom for u_dbl before update as
declare variable
