#15 Manual n:n relationship weirdness

[AndyGett]

Add new table | Del PK | use 1:n relationship from 2 tables (I realize now I should have used "n:n relationship") | add step (int) column) | make these 3 fields PK | add ModuleInstanceId (int) | del PK (again, but PRIMARY index does not go away from indices list) | make ModuleInstanceId PK
- now there are two Indices named PRIMARY
- deleting either of them removes ModuleInstanceId as the PK, not the 3-col PK which is what is desired
- invoking Create SQL removed the offending one

[Joao Paulo Schwarz Schuler]

Logged In: YES
user_id=187362
Originator: NO

I am not sure if I have understood you. Can you send me your model? I think it will be easier to me understand you.
Thank's for testing.

[gmckone]

Logged In: YES
user_id=1119014
Originator: NO

I am having a similar possibly related problem with strange behaviour concerning Primary Keys.

I create a table "Contacts" with a PK of "ContactID" I relate it to a table "Internationalization" with a PK of "CountryID".

Step 1
When I look at the Contact table I see that ContactID is now sharing the primary key index (the key icon) with Country ID which interestingly enough is marked with (FK).

Step 2
Sure enough when I open the table to edit its properties, at the bottom under the indexes section there is the index "Primary" and there are the two fields. "ContactID" and "CountryID" (to clarify I only need or expect ContactID to be PK) So I highlight the "CountryID" field in this window and click the eraser icon to delete it from the PK... It deletes, I click the checkmark at the bottom of the screen, the screen closes and I'm returned to the model which shows...

ContactID is now sharing the primary key index (the key icon) with Country ID which interestingly enough is marked with (FK).

Goto Step 2 repeat forever...

This appears to be broken and needs attention if the visual designer is going to produce valid code.

[gmckone]

Logged In: YES
user_id=1119014
Originator: NO

Sorry.

I am sorry I was choosing "identifying relationship" not "non-identifying relationship" and that seems to fix the issue I had. I don't understand the difference between 1-N identifying and 1-N non-identifying.

My mistake, Does the application provide internal help to explain this terminology?

Greg

[Joao Paulo Schwarz Schuler]

Logged In: YES
user_id=187362
Originator: NO

"identifying relationship" = "PK propagation".
"non-identifying relationship" = "non PK propagation".

If you think I am wrong, you may reopen that BUG.