ALTER statement allows me to change a computed by field with a new formula referencing a field that is positioned higher than the computed by field, but when you extract the table metadata and try to run it, it crashes with "Column unknown." error.
To reproduce:
Step 1)
create table a
( field2 numeric (9,2),
field1 computed by (field2 * 0.5));
Step 2)
alter table a add field3 numeric (9,2);
Step 3)
alter table a alter field1 computed by (field3 * 0.5); -- This works fine!!!
Step 3 works fine, but when you extract the DDL of the table and try to run it, it will
crash, since it will be extracted like:
CREATE TABLE A (
FIELD2 NUMERIC(9,2),
FIELD1 COMPUTED BY (field3 * 0.5),
FIELD3 NUMERIC(9,2)
);
This means that you may have a "good" database, but when you extract its metadata into a script to create another empty database, it will crash :-(
IMHO, the behavior should be consistent in the two scenarios so, or the table creation should succeed, or the ALTER should had failed.
Submitted by: @WarmBooter
ALTER statement allows me to change a computed by field with a new formula referencing a field that is positioned higher than the computed by field, but when you extract the table metadata and try to run it, it crashes with "Column unknown." error.
To reproduce:
Step 1)
create table a ( field2 numeric (9,2), field1 computed by (field2 * 0.5));
Step 2)
alter table a add field3 numeric (9,2);
Step 3)
alter table a alter field1 computed by (field3 * 0.5); -- This works fine!!!
Step 3 works fine, but when you extract the DDL of the table and try to run it, it will crash, since it will be extracted like:
CREATE TABLE A ( FIELD2 NUMERIC(9,2), FIELD1 COMPUTED BY (field3 * 0.5), FIELD3 NUMERIC(9,2) );
This means that you may have a "good" database, but when you extract its metadata into a script to create another empty database, it will crash :-(
IMHO, the behavior should be consistent in the two scenarios so, or the table creation should succeed, or the ALTER should had failed.