Glad I could help

Great, that method was exactly what I was looking for.  I've never seen mention of it before now.  That will really help. 

When you have multiple relationships like that, your best bet is to probably handle the relationships manually.  If you are saving on a transaction, then you will want to make sure that you either only call Save() on the bottom of the relationship tree so that the call gets cascaded up, or set the ParentBusinessObject to Nothing on your business objects before saving them and then set them back. 

Now, when you have a relationship that isn't automatically managed by the ParentBusinessObject/ParentRelationship properties, you can use the GetPostSavePrimaryKeyValue() method on the business object.  After each save of a business object, that method internally stores a dictionary of the pre/post save primary key values, so it might have (-1, 1480) and (-2, 1481) where the 1480 and 1481 were assigned by the server for the two records that had -1 and -2 in the BO respectively.  After the save, if you pass -1 to the GetPostSavePrimaryKeyValue(), it will return to you the 1480 for you to use anywhere you need.  The dictionary only contains the values for the last Save() call, so make sure that you get the values you need before calling Save() on the business object again.

I assigned foreign keys manually. I have two nullable fields on a business object. One is a foreign key to a person/contact and the other is a foreign key to a supplier/company. When I go to save the address, before i actually call the Save method on the address object, I assign the ID from the correct parent (the ID of the current record in the parent object) in the code, then call save and send it the transactional flag and the key.



Basically, you have to save things one object at a time. I found it best to start at the top of my hierarchy and work my way down. For example, when I finished all the things I needed to do on the supplier/company, I'd save to the transaction. Then I started on the address object. Once you do the transactional save on the parent, you have your unique ID assigned and you can pull it for use in saving to your child object.



One thing I can recommend is not using the Business Layer Link Manager object to manage M2M relationships for this situation. I use it, but only when I'm in a view state. When it comes to saving/updating such complex relationships, the BLLM actually got in the way and made things very difficult because of events firing at various points.



Hope this helps...



Regards,

Peter

Ok, I'm going to give a scenario and would like some feedback on the best way to accomplish this. 

I have a transaction which uses something like 10 business objects and needs to save them all out at the end of a bunch of processing.  There are parent/child relationships with almost all of these BO's.  However, one BO may be involved in a few parent child relationships.  This means in one case it may have a certain parent where in another case it would have a different parent.  Whether this is good design or not, that's what I have to work with...

Now, I know that there are issues when mixing the parent/child relationships and transactions on BOs.  Should I just assign the foreign keys manually in these cases?  If so, how do I do this correctly?  At the time I need to assign the foreign key the primary key on the parent hasn't been saved so it has a negative value in it still.  What is the best way to approach a situation like this?  I feel like I keep running into dead-ends.