When using SF we have the BindingField which is based on the BusinessObject property of the control, sometimes I have controls which I would like to bind to a new form's property and no business object, so I can reference this property instead of the control itself.



In this case if I use a SF control, can still use its BindingField property with not BusinessObject? or should I just add a regular property and assign the control value in the GET/SET?

Edhy Rijo

You can build a sql select statement into the sqldataadapter rather than point it to a sproc and you'll get the same result, I believe. 

I am hosting the form that launches the report inside a SF app, so I think I can grab the connection from the application.  The connection string at design time is a different matter.

I'll keep posting as I work through this, but I'll probably post in User Contrib Samples for easy access.  I'm pretty convinced this is the way to go with SF apps.  I don't see any plus side to using SF business objects for reporting but am willing to listen to arguments in their favor.  Just don't see where the creating a propertyinside reporting bos for child stuff is near as fast as creating datasets from a sqldataadapter. 

Makes sense for CRUD of course, but for just grabbing data for reporting seems overbloated.