Howdy everyone:

I have an address design that factors out the actual address information into a separate table (CCAddress) and links this address to the appropriate entity (either a Company or a Salesman) via a foreign key relationship.  In essence the following

CCCompany.comp_pk

                                  CCAddrLink.adlk_comp_pk

                                  CCAddrLink.adlk_addr_pk                   CCAddress.addr_pk

                                  CCAddrLink.adlk_agnt_pk

CCSalesAgent.agnt_pk

The parent child relationship setup at design time is as follows:

CCSalesAgent.agnt_pk -> CCAddrLink.adlk_agnt_pk and when it runs CCSalesAgent is the parent business object of CCAddrLink

The default values for CCAddrLink.adlk_agnt_pk and CCAddrLink.adlk_comp_pk is set to null through the use of a nullable type (set in the BOMapper).  When a new record is added I simply set these to properties to NULL.  This is necessary since either one or the other FK must be null (only one address can apply to another entity, not two ... the null value in the unused FK field prevents the DRI from triggering).

The question is this, when I call the oAddressLink.Save() method the framework should automatically link the parent and the PushDataToChildren() method in the business layer, unfortunately, this is not happening and I was forced to manually update the links and wrap it all in a transaction ... not a big deal but I'd prefer not to do that.

My question is this, does prepopulating the foreign keys with null values prior to calling the save stop the framework from pushing primary keys to children ... I don't think it should but does it?

Thanks,

CT

Charles T. Blankenship
Senior Consultant
Novant Consulting, Inc.
704.975.7152
http://www.novantconsulting.com

The only reason that this would not work like any other BO is if the ParentBusinessObject property is not set and a parent relationship not defined.  As you know, the BO will propagate the parent's newly created PK to the children....BUT, if you are pre-populating the child records with a NULL value, then the parent doesn't know what the child record would be.  For example, if you setup the ParentBusinessObject property and create a new child record, the child will immediately (upon creation of the new record) update that relationship field with the value of the parent foreign key.  In this instance, when the save occurs the parent knows how to update the child record with the new "official" primary key since it knew what the temp PK was within the BO.  But if you override this with NULLs then the parent will not be able to sync back with the child records.