Setting both as PK is more correct, though, from a DB-perspective.
Your join table essentially has a compound primary key. I'd define it
that way in the DB, too. Setting both columns to be PK (it'll help
for the index, too).
Glad to hear it is working for you now.
/dev/mrg
On Mon, May 12, 2008 at 12:52 PM, Daniel Doppmeier
<ddoppme..ebitec.uni-bielefeld.de> wrote:
> Hi
>
> Thanks again. Setting at least one of the attributes as primary key solved
> the problem. As far as I tested, it is not important which of the attributes
> is assigned the primary key, but there has to be at least one PK. The PK
> generation strategy is set to default by the modeller. Any changes to that
> setting do not seem to affect the generated code, so everything seems to
> work just as it should by now.
This archive was generated by hypermail 2.0.0 : Mon May 12 2008 - 13:15:17 EDT