Hi Trent,

Thanks a lot for the ideas.

I took another approach by passing the NoteType and ParentPK values as a parameter to the Note Manager form and then created a method [FillByTypeAndPK(pFK_NoteType, pFK_ParentRecord)] in the the BO to get the correct note records.

Then in the parent form I have this code to call the Note Management form:

 

Edhy Rijo

No, just the primary key value (i.e. BigInt, Guid, etc.)  Then you will have a type field which is an integer and you will create an Enum for within your application and assign to this as a Custom Data Type in the BO Mapper.  This is how you will identify to which table the record belongs.  You will not want to use a string and the table name as this will be much slower on queries and it prevents you from changing table names, etc. if the need arises.

You can automatically manage this on your manager class.  You will create two properties on your class.

ParentBusinessObject As BusinessLayer - The Parent table reference
BusinessObject As BusinessLayer - The Notes table

You will also have a property of the enum value that you create that identifies the parent table:

ParentType As MyNotesEnum

This will tell you how to treat the ParentBusinessObject property and pull the PK.  You could do this by using the PrimarykeyField property on the BO as well, but you will still need the enum property so that you can set this value on the NoteItems record when created so you know how to get it back out of the database.

Hi Trent,

I am creating a Note Management form that may benefic from your Phone Management approach. I have a couple of questions:

• Does the Phone type table have a field to hold the Parent Table Name which will be used to relate the Parent PK?
• The Parent PK field, is this field automatically related to the Parent Table in the BO or is this handle manually whenever you add a phone from each particular form?

Basically what I would like to do is have one single Note tables to handle Notes for several tables, which is what you are doing with the PhoneNumbers manager.

Edhy Rijo

Edhy...you misunderstood what I was getting at.  You could create a common table if you wanted.  But I would be more inclined to create a common control (user control) that gets dropped on unique forms.  That is a much more normalized environment...but you can go any way you want.  If you want to have one form with a lot of BOs on it, then just programatically create the BO translations.

Hummm, I don't have a common address table, all tables have their own address fields, I was thinking on just using a common Address Form manager to handle the address entry, is this still possible possible? if not then I could change my structure to use a common address table as you do with your PhoneNumbers manager.

Edhy Rijo

You can programmatically add a BO translation.  I do this quite a bit.  If you want to know what the object looks like, just open the designer file on a form that you have defined a translation.  Just remember that you will define the _BoName instead of the BoName.  The field is what gets reflected and translated not the component object.

This is up to you.  We have a PhoneNumbers manager in our medical application with a common PhoneNumbers table that is used anywhere that we have a phone number with a type indicator that determines to which table and then a parent PK for the direct identification of the parent.  You need both (type and parent PK) to create a unique record.

I have a several tables which has the same Address fields (Street, City, State, ZipCode), I would like to have use a generic ChildFormDialog to allow end user to enter the data for each table based on the calling form. 

Can this be done with the ChildFormDialog? if so:

• How to programmatically update the CFD properties to use the correct BO to be translated.
• Should I create a generic BO with the Address fields to be used in the ChildForm and then translate this BO with all other BO?

Edhy Rijo