1

Topic: Renaming of a field in the presence of the dependent trigger (in one transaction).

It is impossible. It is necessary to split up on two transactions. In the first the dependent trigger is deleted, into the second we rename a field and we create the trigger anew.
On renaming there was an error and the table it appeared without the trigger.

2

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Hommer;
And not only at "presence of the dependent trigger"
. It was better  a trigger body, instead of to delete it

3

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Inconveniently that there is such not intuitive behavior.
At commenting too it is necessary to break on two transactions.

4

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Hommer wrote:

it is inconvenient that there is such not intuitive behavior.

It is a reality given to us in sensations. Or reconcile, or...

5

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Dimitry Sibiryakov wrote:

it is passed...
It is a reality given to us in sensations. Or reconcile, or...

It is possible to create the trigger using a field and at once this field to rename, the error will not be. The error arises only at .
And in my case the error happens on renaming though  for certain would transit truly, after all dependences any more will not be. Very similar that there simply error in handling of such cases.

6

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Hommer wrote:

it is very similar that there simply error in handling of such cases.

There is no there an error. Simply someone did not complete postponed  objects of a DB, having restricted
Field in system tables "that was as at the Oracle".

7

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Dimitry Sibiryakov wrote:

it is passed...
There is no there an error. Simply someone did not complete postponed  objects of a DB, having restricted
Field in system tables "that was as at the Oracle".

In one transaction it is deleted all foreign keys referring to the table and then the table. Works.
In one transaction it is deleted all foreign keys across the field and then  a field. Works.
In one transaction it is deleted all triggers using a field and it is then deleted a field. Works.
In one transaction it is deleted all triggers using a field and then we rename a field. Does not work.
I see that in other cases  goes in process of performance. And at renaming, with previous it  the trigger, something goes not as usual.

8

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Hommer;
Column renaming is one of data format changes. Which demands . Then only it is possible to address to the changed meta data.
That is,  change of structure of the table demands. Triggers and  to table structure (and to a writing format) have no relation.

9

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

kdv wrote:

Hommer;
Column renaming is one of data format changes. Which demands . Then only it is possible to address to the changed meta data.
That is,  change of structure of the table demands. Triggers and  to table structure (and to a writing format) have no relation.

If a column not to rename, and to delete, the error is not present.
It is a bug to all signs.

10

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Hommer wrote:

In one transaction it is deleted all triggers using a field and then we rename a field. Does not work.

within the limits of one transaction it is possible:
*  the trigger using an old field;
* To add a new field (it appears in "tail" of structure of the table);
* To delete an old field;
* To cause alter field position <N>, where N = to that position among remaining fields where it is necessary to place the field added just;
* To create the trigger with the new code, in which  reversal to a new field.
Simply enough  set autoddl off. [spoiler]

recreate table test (
mio int - will be "renamed" to: "rio", position will be the same
,foo int - will be "renamed" to: "bar", position will be the same
,mau int - will be "renamed" to: "waw", position will be the same
,bee int - will be "renamed" to: "aaa", position will be the same
);
set term ^;
create or alter trigger trg_test_bi for test before insert as
begin
new.bee = coalesce (new.bee, new.foo - new.mau + new.mio);
end
^
set term; ^
commit;
----- test-a: alter fields + change trigger + rollback ==> check that DDL was not changed---
set autoddl off;
drop trigger trg_test_bi;
alter table test
add aaa int
,drop bee
,alter aaa position 4
,add bar int
,drop foo
,alter bar position 2
,add rio int
,drop mio
,alter rio position 1
,add waw int
,drop mau
,alter waw position 3
;
set term ^;
create or alter trigger trg_test_bi for test before insert as
begin
new.aaa = new.bar / nullif (new.rio + new.waw, 0);
end
^
set term; ^
rollback;
show table test;
show trigger trg_test_bi;
commit;
----- test-b: alter fields + change trigger + commit ==> check that DDL was altered---
set autoddl off;
drop trigger trg_test_bi;
alter table test
add aaa int
,drop bee
,alter aaa position 4
,add bar int
,drop foo
,alter bar position 2
,add rio int
,drop mio
,alter rio position 1
,add waw int
,drop mau
,alter waw position 3
;
set term ^;
create or alter trigger trg_test_bi for test before insert as
begin
new.aaa = new.bar / nullif (new.rio + new.waw, 0);
end
^
set term; ^
commit;
show table test;
show trigger trg_test_bi;

Output:

MIO INTEGER Nullable
FOO INTEGER Nullable
MAU INTEGER Nullable
BEE INTEGER Nullable
Triggers on Table TEST:
TRG_TEST_BI, Sequence: 0, Type: BEFORE INSERT, Active
Triggers on Table TEST:
TRG_TEST_BI, Sequence: 0, Type: BEFORE INSERT, Active
as
begin
new.bee = coalesce (new.bee, new.foo - new.mau + new.mio);
end
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RIO INTEGER Nullable
BAR INTEGER Nullable
WAW INTEGER Nullable
AAA INTEGER Nullable
Triggers on Table TEST:
TRG_TEST_BI, Sequence: 0, Type: BEFORE INSERT, Active
Triggers on Table TEST:
TRG_TEST_BI, Sequence: 0, Type: BEFORE INSERT, Active
as
begin
new.aaa = new.bar / nullif (new.rio + new.waw, 0);
end
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[/spoiler]

11

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Susanjan wrote:

is passed...
Within the limits of one transaction it is possible:
*  the trigger using an old field;
* To add a new field (it appears in "tail" of structure of the table);
* To delete an old field;
* To cause alter field position <N>, where N = to that position among remaining fields where it is necessary to place the field added just;
* To create the trigger with the new code, in which  reversal to a new field.
Simply enough  set autoddl off. [spoiler]

recreate table test (
mio int - will be "renamed" to: "rio", position will be the same
,foo int - will be "renamed" to: "bar", position will be the same
,mau int - will be "renamed" to: "waw", position will be the same
,bee int - will be "renamed" to: "aaa", position will be the same
);
set term ^;
create or alter trigger trg_test_bi for test before insert as
begin
new.bee = coalesce (new.bee, new.foo - new.mau + new.mio);
end
^
set term; ^
commit;
----- test-a: alter fields + change trigger + rollback ==> check that DDL was not changed---
set autoddl off;
drop trigger trg_test_bi;
alter table test
add aaa int
,drop bee
,alter aaa position 4
,add bar int
,drop foo
,alter bar position 2
,add rio int
,drop mio
,alter rio position 1
,add waw int
,drop mau
,alter waw position 3
;
set term ^;
create or alter trigger trg_test_bi for test before insert as
begin
new.aaa = new.bar / nullif (new.rio + new.waw, 0);
end
^
set term; ^
rollback;
show table test;
show trigger trg_test_bi;
commit;
----- test-b: alter fields + change trigger + commit ==> check that DDL was altered---
set autoddl off;
drop trigger trg_test_bi;
alter table test
add aaa int
,drop bee
,alter aaa position 4
,add bar int
,drop foo
,alter bar position 2
,add rio int
,drop mio
,alter rio position 1
,add waw int
,drop mau
,alter waw position 3
;
set term ^;
create or alter trigger trg_test_bi for test before insert as
begin
new.aaa = new.bar / nullif (new.rio + new.waw, 0);
end
^
set term; ^
commit;
show table test;
show trigger trg_test_bi;

Output:

MIO INTEGER Nullable
FOO INTEGER Nullable
MAU INTEGER Nullable
BEE INTEGER Nullable
Triggers on Table TEST:
TRG_TEST_BI, Sequence: 0, Type: BEFORE INSERT, Active
Triggers on Table TEST:
TRG_TEST_BI, Sequence: 0, Type: BEFORE INSERT, Active
as
begin
new.bee = coalesce (new.bee, new.foo - new.mau + new.mio);
end
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
RIO INTEGER Nullable
BAR INTEGER Nullable
WAW INTEGER Nullable
AAA INTEGER Nullable
Triggers on Table TEST:
TRG_TEST_BI, Sequence: 0, Type: BEFORE INSERT, Active
Triggers on Table TEST:
TRG_TEST_BI, Sequence: 0, Type: BEFORE INSERT, Active
as
begin
new.aaa = new.bar / nullif (new.rio + new.waw, 0);
end
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

[/spoiler]

After renaming the data should be saved. At you they are lost.

12

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

http://tracker.firebirdsql.org/browse/CORE-5763

13

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Almost seven years ago: http://tracker.firebirdsql.org/browse/CORE-3458
anybody did not come across any more impossibility of renaming of a field with preliminary  dependent triggers and their subsequent creation by one transaction?

14

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

At everything, obviously, the field from the first attempt turns out to name correct.

15

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Dimitry Sibiryakov;
Not mandatory. Simply use  for DDL

16

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

Denis wrote:

Dimitry Sibiryakov;
Not mandatory. Simply use  for DDL

Or use  after each change of meta data which can affect others  in this transaction.

17

Re: Renaming of a field in the presence of the dependent trigger (in one transaction).

[quote = _ Hommer] Almost seven years ago: http://tracker.firebirdsql.org/browse/CORE-3458
anybody did not come across any more impossibility of renaming of a field with preliminary  dependent triggers and their subsequent creation by one transaction?

This possibility is necessary to nobody. Changes of meta data should be rare to be fulfilled exclusively. In an ideal, of course, but better to it to aspire, than to try to make the bad decision, overcoming difficulties.