I set out to prove my point from earlier posts on the topic "Foreign Key relationships and DDL reverse engineer", and it turned out that the problem is not the what I thought it was...
I apologize a thousand times for just assuming that my problem was the same as the others and not verifying this myself (but on the other hand, the problem may have been the same in build 644) I just noticed that my data model got more and more messed up after each synchronization.
There is a definite problem, but it has to do with not discovering dropped columns/fks. Here is how to reproduce it:
-- cleanup
--drop table t1 cascade constraints;
--drop table t2 cascade constraints;
--drop table t3 cascade constraints;
-- begin by running these statements to create the first version of the schema
create table t1 (t1id integer not null, t2id integer, t3id integer,
constraint t1pk primary key (t1id));
create table t2 (t2id integer not null, constraint t2pk primary key (t2id));
create table t3 (t3id integer not null, constraint t3pk primary key (t3id));
alter table t1 add constraint fk_t1t2 foreign key (t2id) references t2 (t2id);
alter table t1 add constraint fk_t1t3 foreign key (t3id) references t3 (t3id);
-- then comment out the above and run these statements to create the second version of the schema
--create table t1 (t1id integer not null, t2id1 integer, t2id2 integer, t3id1 integer, t3id2 integer,
-- constraint t1pk primary key (t1id));
--create table t2 (t2id1 integer not null, t2id2 integer not null, constraint t2pk primary key (t2id1, t2id2));
--create table t3 (t3id1 integer not null, t3id2 integer not null, constraint t3pk primary key (t3id1, t3id2));
--alter table t1 add constraint fk_t1t2 foreign key (t2id1, t2id2) references t2 (t2id1, t2id2);
--alter table t1 add constraint fk_t1t3 foreign key (t3id1, t3id2) references t3 (t3id1, t3id2);
commit;
This will leave t1 with t1id, t2id and their foreign key relationships still there.
Thanks in advance for fixing it, and apologies again!
/Ola
