OrderBO.Cust_id -> CustomerBO.Cust_id

and

OrderBO.Prod_id ->ProductBO.Prod_id

As I navigate through each Order record, I want to be able to display the related Customer.Name and Product.Title.

I've been able to successfully set the OrderBO.ParentBusinessObject = "CustomerBO" in the property sheet, but do not know how to set another relation at the same time or how to do this in code.  Any help would be much appreciated.

TIA,

Larry

Would settiing the ProductBO.ParentBusinessObject = "OrderBO" work for you?

Also, have a look at the CRM Sample that comes with StrataFrame, that will give you some ideas.

Cheers.

Now, for the second part of your question.  At present, there is not a similar mechanism to register multiple keys on the same BO.  However, there is good news, we have actually already implemented this functionality as we are using it in our medical product.  But it will not be in the 1.6.5 build, but a follow-up build in the 1.6.6.  The 1.6.6 release will follow 30+ days after the 1.6.5 build and include the features and enhancements that we could not squeeze into the 1.6.5 build.

Thanks for the quick replies and suggestions.

>>Would settiing the ProductBO.ParentBusinessObject = "OrderBO" work for you?<<

I think the directionality is backwards.  I really need to set two parentBOs for OrderBO, something like:  OrderBO.ParentBusinessObject = "CustomerBO, ProductBO".  I believe the ability to do this is what Trent is referring to in the coming upgrade.

>>Also, have a look at the CRM Sample that comes with StrataFrame..<<

This is a great example I hadn't picked up on.  Lot's of good examples of handling parent-child relations.  Very helpful.

Larry

Sorry if this is a silly question, but is it possible to have two parents set for the same child at the same time? I would think that we could have two childs for the same parent, something like your OrderBO being the same parent for the CustomerBO and the ProductBO, so you would set CustomerBO.ParentBusinessObject = "OrderBO", and ProductBO.ParentBusinessObject = "OrderBO".

Sorry if I got it all confused...

I may not understand what you're trying to do, but if you are just trying to display (and not change) the Customer.Name and Product.Title then you don't need any parent-child relationships between BOs you can just put lookups on the columns (set to read-only). For the Customer the lookup would have a Value Member of Customer.Cust_id  with a display member Customer.Name, and for the Product Value Member of  Product.Prod_id and display member Product.Title and in both cases they can be populated with all active records and you'll only see the ones that equate to your OrderBO.Cust_id and OrderBO.Prod_id.

If you're trying to change the values lookups still work, you just have to filter or repopulate the lookups. We've found it's easiest to repopulate the lookup using a sql stored procedure.

Hope this isn't too far off the mark!

Peter

Hey, I'm pretty sure I'm the one who is more confused <s>..

I generally think of two kinds of relationships:  true parent-child relationships and lookup relationships.  Both are 1:M, with the "many" table having a foreign key that holds the primary key value of the "one".  In the true child, it cannot really exist without its parent (like an invoice item on a single invoice header).  Other FKs on the child simply point to lookup tables and can be left blank and I see these as somewhat different.  

So when you say "two parents for a child", this makes sense to me if you consider "parent" broadly and include lookup tables.  That is what I want to do.

However, I think your example is suggesting one parent for two children:  setting OrderBO as the parent for both Customer and Product.  What I had in mind would look more like OrderBO.ParentBusinessObject1 = "CustomerBO" and OrderBO.ParentBusinessObject2 = "ProductBO"... but as Trent was saying, this feature is under development.

Hope this clarifies it.  Thanks for jumping in. 

Larry

Yes, this is what I am trying to do.  What is a "lookup"?  (I'm coming from VFP and am new to both SQL and .NET).

Larry

I'm using DevExpress a well as strataframe with a SQL Server database back end. With Devexpress the UI elements I use for this purpose are RepositoryItemLookupEdit on a Grid and LookupEdit on a form. Using Strataframe without Devexpress I guess that a Strataframe Listbox or ComboEditBox probably does the same thing.

The fundamental issue is that the UI element is bound to the field (that contains a foreign key) of the BO that you are trying to display, and has been populated with alternatives based on your lookup BO which sets the value of the foreign key, but displays something more meaningful.

Peter

Thanks for the additional info.  You summarized the issue nicely.  A relational database, by definition, has lots of relations (doh!).  This means tables have lots of foreign keys that are themselves meaningless to the user, who is interested in some value looked up on the related table.  How to best display these looked up values on forms, grids, lists, etc... is what I'm asking about. 

A combobox does this automatically, but I'm talking more about readonly situations.  Back in VFP, I used to put a little IIF(Seek(),lookupvalue,"") in the readonly textbox.refresh() to do the same thing.  Way back in dBaseII (dating myself) I used to use the multiple relations.  But in grids and so forth, I used to use multi-table views.  Your DevExpress Loookup control sounds nice; interestingly, I have a little system for Palm applications called Satellite Forms that offers a similar control. 

I don't mind spending money on good tools.  What do you think of DevExpress?

Larry