Generator is reversing a relationship for unknown reason

Mar 28, 2011 at 2:57 AM

The model contains the tables shown in the graph below.  The DEVICE table has two one-to-many relationships:

DEVICE -> INSTRUMENT
DEVICE -> DEVICEPART

                  DEVICE           PART
                 |          |              |
                ^         ^            ^
INSTRUMENT        DEVICEPART

 

The DEVICE->INSTRUMENT generates DEVICE.INSTRUMENTLIST as it should.  However, it is treating the DEVICE->DEVICEPART relationship backwards and is generating a DEVICE.DEVICEPARTITEM member instead of DEVICE.DEVICEPARTLIST.  I have double-checked the relationship definitions and they look correct. Also the graph generated by SQLServer is correct so it got informed of the correct relationships.

As additional info in case it helps…the DEVICEPART table used to be set as an Associative Table but I subsequently turned that off as I need to reference that actual DevicePartId to another table and associative was just not going to work for me.  I of course re-generated and re-built and re-upgraded the database after that change.

Using VS2008 NHDAL

I have forwarded the model to feedback@nhydrate.org so you should have it if needed. Thanks for your continued help.

Coordinator
Mar 29, 2011 at 3:40 AM

Ok there are a few possibilities to correct this issue. First this is the proper behavior because you FK, DEVICEPART.FK_DeviceId is marked as unique and as such there will never be more than one related object in this table to the one object by PK in the parent table. So I am assuming this is a mistake and that you did not mean to mark this field unique. Simple set this property to false on the FK field and the single item will be generated as a list.

That said I do not think this is what you are trying to do. I think you have an associative table between Device and Part. In other words a device can have many parts and a part can have many devices. Is this right? Is so you do not care about the middle table right? If this is true mark the table as Associative. Then make both of your field FK_DeviceId and FK_PartId as primary keys of that table. Then remove what I think is a surragate key "DevicePartId" in that table since you do not need it. If you do this your code will look like this. You will not see the intermediary table.

device.PARTList
part.DEVICEList

Mar 29, 2011 at 4:35 AM

You are correct that the UNIQUE setting was a mistake. Thank you I would have never caught that as the cause of this issue.  To the second part of your reply...I have a third table which needs to hang off of the "associative" table. This is why I went with the regular table having its own PriKey. Basically, a DEVICEPART could be in for any number of REPAIRS and need to be included in REPAIRPART with the appropriate DateTime and comments, etc.  If there is a more efficient way of modeling this I am certainly open to suggestion.

DEVICE -> INSTRUMENT
DEVICE -> DEVICEPART
DEVICEPART->REPAIRS

                  DEVICE           PART
                 |          |              |
                ^         ^            ^
INSTRUMENT        DEVICEPART       REPAIR
                                   |                     |
                                  ^                    ^
                                  ---REPAIRPART--