Have a scenario where I need to enforce a parent/child relationship using a calculated field (Actually determined through another business object, so using database lookups etc).



It's actually an unchangeable parent, then a "linking" child, then the "real" child (Header goes to 0..1 linkers goes to 0..1 data elements)



Header has 2 pieces of info, one being a "Database Name/ServerName" lookup (I need to be able to handle same id within different databases, and at the same time don't want to encode the server/database within each row, make it a nightmare to move).



So tried setting up the relationship through the spiffy UI, it doesn't let me, since the business objects are in different databases (To add to the fun)



And the "ERPSystemKey" (Really a guid stored in another db, through gets / save once) failed due to "ERPSystemKey not found in table" (It's not in there, I know that, there was a fair bit of code to get it set!)



So desire is to allow any fields that I have definied within the business object to be used to link the business objects, and not be dependent on the table structure

Whenever you define a parent relationship between two business objects, you can use any of the fields that have been defined on the business object and marked with the BindingFieldDisplayInEditor attribute.  So, if you add a custom field to a business object, you can use it as part of the relationship definition.

Don't suppose you have an example of using this attribute? I tried a couple of things, didn't compile.



Exact error occurs when assigning



Error:

Column 'ERPXrefKey' does not belong to table Inventory.

hier_Inventory_SOLBO1.ParentBusinessObject = inventory_ERP_SOLBO1;



Relationship had been set up through code:

MicroFour.StrataFrame.Business.BusinessParentRelationship oHierInvRel = new MicroFour.StrataFrame.Business.BusinessParentRelationship();

oHierInvRel.ForeignKeyField = new string[] { "ERPXrefKey", "InvtID" };

oHierInvRel.ParentPrimaryKeyField = new string[] { "ERPXrefKey", "InvtID" };



oHierInvRel.ParentBusinessObjectType = "HierBO.Inventory_ERP_SOLBO";

hier_Inventory_SOLBO1.ParentRelationship = oHierInvRel;

In these two lines of code:

oHierInvRel.ForeignKeyField = new string[] { "ERPXrefKey", "InvtID" };
oHierInvRel.ParentPrimaryKeyField = new string[] { "ERPXrefKey", "InvtID" };

do those fields belong to both tables (i.e. a compound primary key?)  If not, then you only want to specify the field once in the definition.  For instance, I have a table Customers with pk=cust_pk and a table Orders with a foreign key to Customers called or_cust_pk.  The relationship would look like this:

BusinessParentRelationship myRel = new BusinessParentRelationship();
myRel.ForeignKeyField = new string[] { "or_cust_pk" };
myRel.ParentPrimaryKeyField = new string[] { "cust_pk" };
myRel.ParentBusinessObjectType = "MyNamespace.Customers";
myOrder.ParentRelationship = myRel;

Table 1 has InvtID

Table 1 has a calculated field (In the business object) that is a GUID that corrosponds to the Server/Database (ERPXrefKey). This is NOT a field in table 1, but is required for the correct entry in table2



Table 2 is in a different database

Key in Table2 is the ERPXrefKey and then InvtID



I'd like to form a business relationship with the calculated field and the key.



Reason for this structure:

Client(s) of ours can and will install multiple databases, and there is a very likely probability that there will be a duplicate InvtID. As far as I can tell, the database deployment kit requires hard names, so I will only have one database that is mine, and will need to be able to deal with different connections. So added the ERPXrefKey to provide uniqueness to the invtid (this is one example, there are > 3000 tables that we may need to touch. I would expect all to be duplicated, most explicitly in test scenarios, only difference really is test data and name of the DB)



So my desire is to automatically figure out the DB info, and ensure I will always refer to the same values.

Well, any time a business object needs to reference a field from the business object on the other side of the relationship, it uses the default property (indexer), which will return a value through any strong-typed property, not just the ones that are in the table.  However, when the business objects attempt to do things such as cascading the row filter, or using the "FillByParent" methods, the business objects are expecting all of the fields to be part of the current data table and the table in the database.  So, I'm not sure of a way around your problem other than to add an extra column to the internal data table of the business object each time the CurrentDataTableRefilled method fires and calculate the values for the extra column.