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.

Hi 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

One grid.  Three BOs.  Three BBSs.  Just looking for a simple, flattened view of the data.  I do not need any of the master-detail type stuff going on in this particular DevEx grid.

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

Hi 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

That does not work.  The fields come back with blank stares.  Kinda creepy.

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

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.

Bill,



If I understand you correctly, you could write a fill method in your Work Order BO that would return the appropriate data (using the appropriate SQL joins to the other tables). The data table under BO can have any column in it (i.e. there doesn't have to a strongly typed property associated with each column), to the extra data would be available in the underlying datatable. You would then have your custom properties. I'm a bit slow to make use of grids, so I'm not sure how the BBS works with a datatable like this, but if the BBS is just binding to the data table, I'd guess that it would work just fine.



Hope that sparks some ideas.

The BOs are defined.  Relations exist.  The user wants a form that simply displays data from the BOs.  For example:

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