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

Whether the column you are trying to display is read-only or not I still believe a lookup is the answer, the only difference being that for the read-only case you need to ensure that the lookup, however it is implemented, is set so that it disallows editing/changing.

I tried using BOs based on views when I was getting started with Strataframe, and found that it just became too complex if I needed it to be updateable. That is not to say it can't be done, and in some places is preferable, but I wouldn't use one to try and maintain a table.

My experience with Devexpress is very positive, but I have no experience with alternatives. Their support is good (though not as good as Strataframe). There are a reasonable numbers of devexpress users on this forum, and has been considerable discussion in other threads, so I suggest you do a search.

Hope this helps.

Peter

I would then use the FillForComboDisplay as the method to populate the combo...and the ph_pk would be the Value Member which is bound to the foreign key field.

BTW, Peter, thanks for your nice words regarding our support! 

As you may have noticed, we have a wrapper for both DevExpress and Infragistics.  Ultimately we use some of the Infragistics (after first using DevExpress) controls in our medical software.  But we have create custom controls and continue to extend our StrataFrame controls due to one isolated issue or another.  DevExpress and Infragistics are both good control companies, but we predominately use the SF controls except in areas like the UltraGrid or controls of that nature.  Infragistics also has some good masking controls (i.e. currency) but they still take some tweaking to get it just right.

Thanks very much for your input and suggestions.  I'm making good headway learning SF because of this good support. 

As a small aside, Trent, I notice you include a table prefix in all our field names (e.g.,  Pharmacy.ph_Name).  Just curious how that helps.  Is it to avoid duplicate field names in JOINS?  Since I am essentially rebuilding some VFP applications almost from scratch, I'm open to anything that prevents problems down the road.

Larry

It's kindof funny how when a certain topic comes up it comes up everywhere.  It seems like I have had this converstaion a lot lately

Yeah, prefixes are a really good standard because it can uniquely separate one table from another.  This is a standard that I learned when I first started in the business and it turned out to be a good one.  This is especailly helpful when you start producing more complex queries such as JOINS or pulling values froma SPROC or VIEW.  Say for example that you have a field named CreatedDate in two different tables, you then have to *** an AS clause for every field in the query that is going to return a CreatedDate otherwise you will have an ambiguous field name.  SQL Server is much more forgiving when it comes to naming fields than VFP, but having prefixes has really reduced the complexity of some of my queries over time.

We always prefix our table and column names with a unique three character prefix, e.g. PUNWeight, HPCWeight etc. Not only does it eliminate duplicates names in procs and views it makes code easier to 'read'. Being doing this for years in various database and highly recommend it.

FYI, another convention we use and find useful is XXX_PK, e.g. HPC_PUNID, for all foreign key relationships, where XXX is the standard column prefix for the table and PK is the Primary Key column name in the foreign key table. As you can see we always name our Primary Key values as the table prefix followed by "ID".

Cheers, Peter

Regards,

Gerard