Hi Trent,

I have the following tables:
  1. Company (Parent)
  2. MemberInfo (Parent)
  3. Address Mem(Child to 1 and 2 above)

In the AddressMemBO I have a relationship define for the MemberInfo (put the relation info here) I have a form where I want to use AddressMemBO related to Company so the correct AddressMemBO.Company_FK) can be updated automatically, I am trying to use the BO.RegisterForeingKey method to archive this with the following code:

The above code is not working, the BO.FillByParentPrimaryKey() is not returning any record, where I am sure there are related records in the database, also when adding a new AddressMem record, the Company_FK is not being updated.

Now if I change in the AddressMemBO class relationship via the class to it will be with Company table instead of MemberInfo, it will work just fine. (One relation at the time).

So what am I missing in the use of BO.RegisterForeingKey?

Thanks,

Doron

The 

The RegisterForeignKey is used for updates, not queries.  In order to rely on the FIllByParentPrimaryKey method, you must define the relationship thorugh the ParentRelationship property.  If this is already defined elsewhere, then just create a Fill method that accepts two parms: foreignKeyPk and the AddressType (i.e. company, customer, etc.).  Generally we will create an enum for a type field.  An example of this in our medical software is phone numbers.  We have a single PhoneNumbers table that is used for every entity in the applicaiton that may need a phone number (i.e. patients, insurance carriers, doctors, etc.).  So we have a fill method that looks something like this on the PhoneNumbersBO:

Hi Trent,

Your suggestion worked just fine. But it will be nice if I can use the wizard to add un limited relations instead of adding the relation by code. Is that on the work for the next version?  In a way this is like small DD where the relation is defined and it is easier to see or manage all relations with this little graphical interface.

Thanks,

Doron

That may be a possibility.  But one reason that we will always have the code mechanism is because it allows you to setup temp relationships, etc. that may not be permamnent or necessary most of the time.  But I understand your point.

Hi Trent,

I hope you will get to it sometimes soon.

Regards,

Doron