Primary and Candidate key are completly a different beast than a unique index. The first 2 ensure that no dupes get in. The unique index only include in it's index the first dupe and should never be used.

I don't want to be a database police, but having a table that can't use a primary key mean that it is not relational. This could mean big trouble in the end in data consistency. Many developper (including me) are using surrogate keys just to act as a primary key. This is a field (usually Integer type) that the user never see and is incremented automatically by the system when a new record is added.

Many-to-many relationship need to be break apart. Create a third table that act as an intermediate between the first two. This table will contain the primary key of each table. That way, table A will connect to this table to get all matching record in table B and table B will connect to this table to get all matching records in table A.

HTH

>So, I can not use the Database Designer because I "have" to use a Regular Index instead of Primary or Candidate Index? I need the DUPE records in both tables. I was told to NEVER, NEVER, NEVER use Unique Index ;) Oh oh oh, I realize something now, I think I need many-to-many relationship, I see. I have never used that so I dont know how that works. Can sxomeone shed light on many-to-many relationships?