1) Create the referenced table

create table t1
(
 pkey integer not null,
 constraint pk_t1 primary key (pkey)
)

2) Create the referencing table

create table t2
(
 pkey integer not null,
 fkey integer,
 constraint pk_t2 primary key (pkey),
 constraint fk_t2 foreign key (fkey) references t1 (pkey)
)

3) Delete the referencing table

drop table t2

Error:
ElevateDB Error #201 The Table t2 cannot be dropped because it is still
referenced by the primary key constraint pk_t1

This error condition doesn't seem valid. Table t2 is *referencing* table t1,
not the other way around. There are no dependencies on table t2, hence the
DROP statement should execute without an error.

On the other hand, table t1 can't be dropped as long as table t2 is
referencing it. The normal sequence for dropping tables with RI would be:

drop table t2; -- drop the referencing table first
drop table t1; -- drop the referenced table last

I tried the following steps, but ran into additional problems:

4) Delete the foreign key

alter table t2
drop constraint fk_t2

5) Delete table t2

drop table t2

Error:
ElevateDB Error #400 The table t1 already exists

When closing EDB Manager, I got the following Windows error message:

ElevateDB Manager has encountered a problem and needs to close.

And then the following error:

Runtime error 217 at 00541AD2

Ole Willy Tuv

Ole,

<< This error condition doesn't seem valid. Table t2 is *referencing* table
t1, not the other way around. There are no dependencies on table t2, hence
the DROP statement should execute without an error. >>

The dependency is that T1 is referencing T2 still, hence T2 cannot be
dropped.  You cannot drop a table that is the target of a foreign key
constraint without first dropping the foreign key constraint first.

<< Error:
ElevateDB Error #400 The table t1 already exists

When closing EDB Manager, I got the following Windows error message:

ElevateDB Manager has encountered a problem and needs to close.

And then the following error:

Runtime error 217 at 00541AD2 >>

Got it.  It's fixed.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< The dependency is that T1 is referencing T2 still, hence T2 cannot be
dropped. >>

It's the other way around - T2 is referencing T1, hence the dependency
exists on T1. There are no dependencies on T2.

<< You cannot drop a table that is the target of a foreign key constraint
without first dropping the foreign key constraint first. >>

The target of the fk constraint is T1. I was dropping T2!

Ole Willy Tuv

Ole,

<< It's the other way around - T2 is referencing T1, hence the dependency
exists on T1. There are no dependencies on T2. >>

There are internally in the catalog, which is why EDB is complaining.  It's
something that will be addressed, for now you have to drop the FK first.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<< There are internally in the catalog, which is why EDB is complaining.
It's something that will be addressed, for now you have to drop the FK
first. >>

OK, thanks for confirming the issue.

Ole Willy Tuv

Tim,

<<< It's the other way around - T2 is referencing T1, hence the dependency
exists on T1. There are no dependencies on T2. >>>

<< There are internally in the catalog, which is why EDB is complaining.
It's something that will be addressed, for now you have to drop the FK
first. >>

AFAICS, the issue is not addressed in 1.02 build 1.

I hope you still have it on your list ?

Ole Willy Tuv

Ole,

<< AFAICS, the issue is not addressed in 1.02 build 1. >>

I keep everything that you post and will address it when I can, even the
stuff that I don't agree with initially.

The main thrust now is to stabilize everything within the current feature
set.

--
Tim Young
Elevate Software
www.elevatesoft.com