Work Order BO
workorderindex (pk)
workorderid
partindex (fk)

Parts BO
partindex (pk)
partnum
unitindex (fk)

Units BO
unitindex (pk)
unitdesc

The grid will display workorderid, partnum, unitdesc.  With only the BOs, their corresponding BBSs and a DevEx Grid, can this be done?  If so, how?

I can easily get the Work Order BO and the Parts BO to display everything I need (employing the appropriate repository controls in the grid).  The Units BO is the kicker.

Hoping someone in the SF community will have run into this issue and will be able to shine some light on this.  Please note that I do not want to resort to SQL script here.  I can certainly create a data query and pass the results to the grid and bypass the BOs altogether.  That is not what I want to do.  I have some custom properties that are showing up in the grid from the Work Order BO that I must have.  These will be lost if I bypass the BOs.

Thanks,
Bill

So, I could write something like FillDataTable("SELECT WO.*, Parts.partnum, Units.unitdesc FROM WorkOrders WO LEFT OUTER JOIN...") and these two fields will show up in the BBS?  Is that right?  If so...my problem might be solved.

Testing now.

As I understand it, the BO must have the field defined in order for the BBS to pick it up.  It has to be a part of the CurrentDataTable of the BO.  That is why I really want to see if this can be down only using currently defined BOs.  All of the data I need already exists in these separate BO definitions.  They can be instantiated and filled quite quickly.  Somehow, I should be able to relate the BOs and point to the field I want to display in the grid.  Somehow.

I really do not want to create a custom property in the Work Order BO called UnitDesc.  I shudder just thinking about that.

Thanks for the help!
Bill

I may be missing the point but isn't this just three DX grids: Parent, Child and GrandChild using the SF ParentRelationship and ParentBusinessObject properties to bind them together?

Cheers, Peter

Please keep in mind that this is an exercise for the use of SF BOs.  If a business object exists, then I should be able to point to its properties.  If one of the properties has a relation to another BO, then I should also be able to point to that second BOs properties, too.  The fundamental question is, can it be done in a grid format, using it as a table-like representation of the data?

Hope I am making myself clear--doesn't sound like it, though.  Holler if anyone needs more clarification.

Bill

Yes, I see now. Personally I would just create a view (and replicate your custom fields in the view) that brings everything together however I'm pretty sure you will see examples of bringing BO's together in this fashion for reporting. Try a forum search on reporting, especially SharpShooter examples.

Cheers, Peter

If I create a view (which is what I have always done up to this point...again, I am exploring the business object capabilities), then I also have to create a corresponding BO.  This new BO would easily populate the grid that I want.  I'll grant that option.  It is what I will be doing if no other clever solution comes my way.

I'd really like to take existing BOs that can be related to one another and display the flattened view of the data, including any custom properties of any of the BOs.  Perhaps this is simply not possible.  I am probably attempting something that the framework is not intended to do.

Actually this isn't far off.  There are a couple of things that you may want to consider.  First, I more than likely would not be trying to put all 3 tables inside of one grid unless they are all one-to-one relationships.  Otherwise this would get really messy.  In this case though, you would just want to create an updatable view which pulls this back and would then allow a record set to be updated going back the other way. 

What you are trying to accomplish is not outside of the scope of the framework and can be done, but the reason that you have received some of the comments suggesting other mechanisms is because a grid gets really messy when trying to cram all of this into one locale.  If this were read-only then it wouldn't be as big of a deal.  But in any case, just create an updatable view, then all of your BOs, custom properties, etc. will all work.  You can then create a new Custom BBS through the templates which will just side step the need to drop on a separate BBS on the form (same approach that is used for reporting).

Note: When creating updatable view