Subject | Re: [firebird-support] problems creating constraints |
---|---|
Author | Helen Borrie |
Post date | 2004-02-17T06:19:16Z |
At 04:23 AM 17/02/2004 +0000, you wrote:
have to refer to an object that exists *in the database*.
This aint MySQL, so the course of events when changing something is always
start a transaction
do something
commit it to make it happen
What tool are you using? if it is one that lets you inspect metadata, and
you are actually inspecting metadata; or if you are inspecting the table
itself...these are both ways that the object is in use.
You'll get to know and love transactions. :-)
/heLen
>I have tried doing this a few times, each attempt has forced me toI don't see the word "Commit" anywhere there...to create a foreign key, you
>completely remove the entire database and start from scratch.
>
>(i'm migrating from the hell that is mysql so bear with me)
>
>heres what I have
>
>create table users (
> uid integer not null,
> username varchar(32) not null
>);
>
>create table info (
> uid integer not null,
> name integer not null
>);
>
>I add an index and a constraint...
>alter table users add constraint uid primary key (uid);
>create unique index username on users(username);
>
>heres where the problem kicks in:
>
>alter table info add constraint KEY_UID foreign key (uid) references
>users(uid) on update cascade on delete cascade;
>
>unsuccessful metadata update
>-object USERS is in use
>
>Anyone know how could this be? I have no data in the table users, I
>have tried restarting the database server (its built as superserver),
>and i've tried to delete/deactivate my constraints I have put in to
>try and get rid of the problem.
>
>alter index key_uid inactive;
>Statement failed, SQLCODE = -607
>
>unsuccessful metadata update
>-MODIFY RDB$INDICESS failed
>-action cancelled by trigger (3) to preserve data integrity
>-Cannot deactivate primary index
>
>This is very very frusterating, I can't even build a simple db, I
>never have seen these sorts of problems even with postgres.
have to refer to an object that exists *in the database*.
This aint MySQL, so the course of events when changing something is always
start a transaction
do something
commit it to make it happen
What tool are you using? if it is one that lets you inspect metadata, and
you are actually inspecting metadata; or if you are inspecting the table
itself...these are both ways that the object is in use.
You'll get to know and love transactions. :-)
/heLen