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

I've been working a bit more with Xtrareports now, so i wanted to share some observations and this thread seems a good place to tack it on, as Peter was so helpful.

Hi Charles,

Thanks for posting the link to the video, very interesting.  I was wondering how to get the data to preview with SF BO, but guess is not possible for now.  I kind of like the SP approach, even though that will require an stored procedure for each report, but is either that or no having preview available.

Using the method explained in the video, you also need to grab the connection string at runtime to avoid having to hard code it.

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.