Subject | Re: [firebird-support] Problems with primary key not working |
---|---|
Author | Helen Borrie |
Post date | 2006-03-27T22:50:37Z |
At 11:58 PM 27/03/2006, you wrote:
what I can find out from ISQL about a table named MEMBER in a
database I work with:
SQL> show table member;
MEMBER_SER_NUM (D_IDENTIFIER) INTEGER Not Null
MEMBER_ID (ID_TYPE) VARCHAR(10) Not Null
PERSON_ID (D_IDENTIFIER) INTEGER Not Null
MEMBER_STATUS (ID_TYPE) VARCHAR(10) Nullable
GROUP_ID CHAR(2) Nullable
PAYMENT_STATUS (ID_TYPE) VARCHAR(10) Nullable
JOIN_DATE DATE Not Null DEFAULT 'TODAY'
RENEWAL_DATE DATE Nullable
TERMINAL_DATE DATE Nullable
RATING_REVIEW_DATE (RATING_PERIOD_TYPE) DATE Nullable
RATING_VALUE INTEGER Nullable
DATE_CREATED TIMESTAMP Nullable
CONSTRAINT FK_MEMBER_PERSON:
Foreign key (PERSON_ID) References PERSON (PERSON_ID)
CONSTRAINT PK_MEMBER:
Primary key (MEMBER_SER_NUM)
CONSTRAINT UQ_PERSON_ID:
Unique key (PERSON_ID)
Triggers on Table MEMBER:
BI_MEMBER, Sequence: 0, Type: BEFORE INSERT, Active
SQL>
Also, OBJECTNUMBER (provided it is unique and protected) would be a
more suitable primary key for your table than OBJECTNAME, which
carries too much "baggage" (it carries semantic meaning, plus it has
non-default character set attributes). You can place a unique index
or a UNIQUE constraint on OBJECTNAME in order to forbid duplications,
but it should not be the PK.
./heLen
>I'm using Firebird 1.5 and have a table desclared as follows:Then the primary key constraint does not exist.
>CREATE TABLE OBJECTS (
> OBJECTNAME VARCHAR (30) CHARACTER SET ISO8859_1 NOT NULL COLLATE
>ISO8859_1,
> ID INTEGER NOT NULL,
> OBJECTNUMBER INTEGER NOT NULL,
> ENABLED INTEGER NOT NULL);
>
>
>
>/* Primary keys definition */
>
>ALTER TABLE OBJECTS ADD PRIMARY KEY (OBJECTNAME);
>
>
>/* Foreign keys definition */
>
>ALTER TABLE OBJECTS ADD FOREIGN KEY (ID) REFERENCES OBJECTGROUPS
>(GROUPID) ON UPDATE CASCADE;
>
>My problem:
>It is possible to add more than one record with the same OBJECTNAME
>and futhermore changing GROUPID in table OBJECTGROUPS doesn't changeThen the foreign key constraint does not exist.
>ID in table OBJECTS.
>What is wrong? Is the database corruptedIf you can perform DML operations on it, then it's not corrupted.
> and if so what could I do to fix this?Use ISQL or another tool to inspect the constraints, e.g., here's
what I can find out from ISQL about a table named MEMBER in a
database I work with:
SQL> show table member;
MEMBER_SER_NUM (D_IDENTIFIER) INTEGER Not Null
MEMBER_ID (ID_TYPE) VARCHAR(10) Not Null
PERSON_ID (D_IDENTIFIER) INTEGER Not Null
MEMBER_STATUS (ID_TYPE) VARCHAR(10) Nullable
GROUP_ID CHAR(2) Nullable
PAYMENT_STATUS (ID_TYPE) VARCHAR(10) Nullable
JOIN_DATE DATE Not Null DEFAULT 'TODAY'
RENEWAL_DATE DATE Nullable
TERMINAL_DATE DATE Nullable
RATING_REVIEW_DATE (RATING_PERIOD_TYPE) DATE Nullable
RATING_VALUE INTEGER Nullable
DATE_CREATED TIMESTAMP Nullable
CONSTRAINT FK_MEMBER_PERSON:
Foreign key (PERSON_ID) References PERSON (PERSON_ID)
CONSTRAINT PK_MEMBER:
Primary key (MEMBER_SER_NUM)
CONSTRAINT UQ_PERSON_ID:
Unique key (PERSON_ID)
Triggers on Table MEMBER:
BI_MEMBER, Sequence: 0, Type: BEFORE INSERT, Active
SQL>
Also, OBJECTNUMBER (provided it is unique and protected) would be a
more suitable primary key for your table than OBJECTNAME, which
carries too much "baggage" (it carries semantic meaning, plus it has
non-default character set attributes). You can place a unique index
or a UNIQUE constraint on OBJECTNAME in order to forbid duplications,
but it should not be the PK.
./heLen