Subject | Re: How to delete firebird2 table field used as primary index? |
---|---|
Author | Adam |
Post date | 2006-11-08T04:16:02Z |
--- In firebird-support@yahoogroups.com, "mariofb123" <mariofb123@...>
wrote:
such as foreign key constraints if applicable.
You then need to drop the primary key constraint. This is a bit more
tricky because you did not name it when you created it, so it will
have a silly autogenerated name.
SELECT RDB$CONSTRAINT_NAME
FROM RDB$RELATION_CONSTRAINTS
WHERE RDB$RELATION_NAME = 'GH'
AND RDB$CONSTRAINT_TYPE = 'PRIMARY KEY'
That will return to you the name, so you can then use
ALTER TABLE GH DROP CONSTRAINT <from above>;
Then you can redeclare the primary key providing that the new fields
meet the criteria (not null and guaranteed unique for every record).
Just a tip for the future, don't use superkeys as primary keys. Create
a surrogate value that you fill with a generator, and you avoid a lot
of issues.
Adam
wrote:
>You will first need to drop any items that depend on the primary key,
> The table consists of 3 fields: EVENTDATE, EVENTTYPE, EVENTKEY. All 3
> fields are used in the combined primary table index.
> I am trying to delete the EVENTTYPE field, however Firebird does not
> allow for this. How to get rid of this field and change the primary
> index to consist of the two remaing fields only ? I cannot delete and
> recreate the table, as it already contains data.
>
> note: the original command to create the primary index was:
> ALTER TABLE GH ADD PRIMARY KEY (EVENTDATE, EVENTTYPE, EVENTKEY);
>
such as foreign key constraints if applicable.
You then need to drop the primary key constraint. This is a bit more
tricky because you did not name it when you created it, so it will
have a silly autogenerated name.
SELECT RDB$CONSTRAINT_NAME
FROM RDB$RELATION_CONSTRAINTS
WHERE RDB$RELATION_NAME = 'GH'
AND RDB$CONSTRAINT_TYPE = 'PRIMARY KEY'
That will return to you the name, so you can then use
ALTER TABLE GH DROP CONSTRAINT <from above>;
Then you can redeclare the primary key providing that the new fields
meet the criteria (not null and guaranteed unique for every record).
Just a tip for the future, don't use superkeys as primary keys. Create
a surrogate value that you fill with a generator, and you avoid a lot
of issues.
Adam