Hi Frank,
A couple of comments. Generally, the primary key for the many to
many relationship is the combination of the two primary keys that the
table is linking together. It may be possible for it to work without
it set up like that, but I've never done it. Secondly, there are
usually six key relationships in many-to-many relationships. In your
case, RB and RA should have "nullify" as their delete rule. The
cardinality should be "to one" and the optionality should be
"mandatory." The next two relationships are the inverse ones: BR and
AR. They should be to-many and optional. They should have "cascade"
as their delete rule. None of those four relationships need to be
class properties. The last two relationships are the actually to-
many relationships that are defined as BR.RA or AR.RB. Those are the
only relationships that you should have to work with (unless the link
table has specific info you want to get).
Is that what your setup looks like? If so, and it still doesn't
work, then you may have to dig deeper. I've been stumped by nearly
every type of frustrating relationship imaginable and it almost
always comes down to me swearing that my model is right, but finding
out that I am wrong. Even if it is "right" by normal human logic, EO
have very little tolerance for other opinions of what is right and
wrong and won't work if it isn't the way it wants it.
John
On Aug 9, 2007, at 6:52 AM, Frank Stock wrote:
Hello,
I have a table A and B and a many to many relation R between A en B.
The relation-table R has a primairy key and the relation RA to A
and RB to B. (RA and RB can't be null)
I see that there are a few rows in R where RB is 0 or RA is 0 or
(RA and RB are 0), a few have a RB with no link to B, so if we
delete A, we get an error.
The EOmodel is OK so, if we delete B, the cascade is working to
delete related R's.
How can RA or RB get 0? Where do I have to look??
We have about 1% errors.
Thanks for advice.
Frank Stock
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/the_larsons%
40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
