Subject | RE: [IBO] Cascade |
---|---|
Author | Dion |
Post date | 2002-01-15T04:09:55Z |
Hi,
Your assumptions are corect, Geoff. I thought that making an ID number the
primary key made sense, as it is unique(should be, anyway), and is not
changed often at all. The error I get is
"violation of foreign key constraint on 'COVEREDMEM'"
Will the constraint take care of the Cascade? I have not declared any
triggers to do this. Are no other settings on the dataset necessary to cause
the cascade?
I agree that declaring a 'dummy' primary key would solve all problems, but
something reminds me that the previous is the better way of doing
things(guess I'm a sucker for punishment).
Regards,
Dion.
-----Original Message-----
From: Geoff Worboys (TeamIBO) [mailto:geoff@...]
Sent: Monday, January 14, 2002 1:49 PM
To: Dion
Subject: Re: [IBO] Cascade
If the error occurs after an edit, it sounds like you are altering the
primary key (MEMBERID) on the main dataset and so causing a cascaded
update. You can avoid such overheads by using surrogate (generated)
key values on tables so that they never need to be updated.
Run the IB_Monitor to see what is actually happening when you post the
changes and then check the triggers etc on your tables to ensure that
there are no side-effects which may be causing the problem.
--
Geoff Worboys - TeamIBO
Telesis Computing
___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Your assumptions are corect, Geoff. I thought that making an ID number the
primary key made sense, as it is unique(should be, anyway), and is not
changed often at all. The error I get is
"violation of foreign key constraint on 'COVEREDMEM'"
Will the constraint take care of the Cascade? I have not declared any
triggers to do this. Are no other settings on the dataset necessary to cause
the cascade?
I agree that declaring a 'dummy' primary key would solve all problems, but
something reminds me that the previous is the better way of doing
things(guess I'm a sucker for punishment).
Regards,
Dion.
-----Original Message-----
From: Geoff Worboys (TeamIBO) [mailto:geoff@...]
Sent: Monday, January 14, 2002 1:49 PM
To: Dion
Subject: Re: [IBO] Cascade
> I have the following constraint declared:-What error do you get?
> ALTER TABLE "COVEREDMEM" ADD FOREIGN KEY ("MEMBERID") REFERENCES
> MEMBER ("MEMBERID") ON UPDATE CASCADE;
> When I edit and post on the MEMBER table, I get an integrity error.
> Are there other settings which need to be made on the TIB_Query
> object(ie do I have to set an EditSQL value?).
If the error occurs after an edit, it sounds like you are altering the
primary key (MEMBERID) on the main dataset and so causing a cascaded
update. You can avoid such overheads by using surrogate (generated)
key values on tables so that they never need to be updated.
Run the IB_Monitor to see what is actually happening when you post the
changes and then check the triggers etc on your tables to ensure that
there are no side-effects which may be causing the problem.
--
Geoff Worboys - TeamIBO
Telesis Computing
___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/