Subject RE: [IBO] Cascade
Author Dion

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).


-----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:-


> 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?).

What error do you get?

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.
___________________________________________________________________________ - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !

Your use of Yahoo! Groups is subject to