One of the issues I have is that I HATE doing reports.. When I first started in IT that is all I did for many years.

I want to be able to set up the query and any grouping on the report and have one of the girls do the tedious pretty work. This does require that the fields be bound to something at design time.

I will probably have specific questions on how to set up a bo to support a joined query and provide the strongly typed fileds required to make design time report binding possible. I just havent had a chance to try it so don't know. 

Paul

Below is query that I had just had to create for our accounting department. I have no idea how I would be able to use business objects to create a design time datasource for a report based on this query. I have to create a stored proc(parameters) or query a view of the joined data, or I use the sql data adapter method on the report and generate the table which I don't like.

For reporting you do not need to be able to insert update or delete which is the reason that business objects are what they are. However with a report you do not need that funtionality.

Would it be possible to create another type of object? A stripped down business object call it a report object that is strongly typed based upon the fields returned from the select query? This would provide for a read only view of data that could be bound in reports grids etc.

Maybe i am missing something but I just cannot seem to get my head around this so please be patient if I am in left field somewhere but the light is just not coming on

SELECT ECOApplyTo.CUSTNMBR as [Customer Id], RM00101.CUSTNAME as [Customer Name],

RM00201.CLASDSCR as [Office], RM20101.CHEKNMBR as [Check Number], ECOApplyTo.DATE1 as [Applied Date],ECOApplyTo.APFRDCNM as [Audit Trail],

ECOApplyTo.ActualApplyToAmount, ECOApplyTo.APTODCDT as [Invoice Date], RM00101.CUSTCLAS,

RM20101.ORTRXAMT as [Original Invoice Amount],ECOApplyTo.APPTOAMT as [Amount Applied],

CAST(ECOApplyTo.DATE1 - ECOApplyTo.APTODCDT AS int) AS Age, ALM_RM20201X.DOCNUMBR as [Invoice Number], ALM_RM20201X.CURTRXAM as [Current Invoice Balance],

(case when CAST(ECOApplyTo.DATE1 - ECOApplyTo.APTODCDT AS int) > 50 then ActualApplyToAmount else 0 end) as inEligable ,

(case when CAST(ECOApplyTo.DATE1 - ECOApplyTo.APTODCDT AS int) < 51 then ActualApplyToAmount else 0 end) as Eligable ,

DateAdd(day, -1 * datepart(dw, Date1), Date1 ) as week

FROM RM00101 INNER JOIN

ECOApplyTo ON RM00101.CUSTNMBR = ECOApplyTo.CUSTNMBR INNER JOIN

RM00201 ON RM00101.CUSTCLAS = RM00201.CLASSID INNER JOIN

RM20101 ON ECOApplyTo.APFRDCNM = RM20101.DOCNUMBR INNER JOIN

ALM_RM20201X ON ECOAPPLYTO.APTODCNM = ALM_RM20201X.DOCNUMBR

WHERE RM20101.RMDTYPAL = 9 and date1>= @FromDate and date1 <=@ThruDate

and Substring(CUSTCLAS,1,3) = @OfficeID

order by CLASDSCR,week,[Customer Id]

1) Create a fake table in some temp database in SQL Server that has the same structure as the results of your join and build the business object off of that.  Then, you will automatically have your strong-typed fields becuase the BOMapper will be able to "see" the object that has the structure that you want.

2) Create a fake table in some temp profile in the DDT that has the same structure as the results of your join... same thing as the one above...

Once you build the business object through the BOMapper, it becomes a strong-typed design-time data source for your report.  So, no matter what the crazy structure of your report, you can always create a business object that matches the structure by creating "dummy" structure sources in either the DDT or SQL Server.

I got the idea for the dummy table in the DDT, a fake Database there, and then map the BO.

Then, after instanciating the BO, I would just create a fill method with Paul's sql statement and be happy forever?

I did the changes you mentioned before to get the BO dropped into the designer. It worked fine!!!

But have you tried the "Preview" ?  I get an error message like this:

Serialization Error

81:  The type or namespace name 'tboTeste' does not exist in the namespace 'ProFilmeNET_BOL' (are you missing an assembly reference?)

I understand what you are saying about using a temp table to allow me to generate the fields for strong typing to be able to use the report designer at designtime. That should work ok but I would like to create a seperate report object type that would use the strataframe DAL but be generated using the schema returned from a select statement. This should give me the strong typing I would like as well as allow me some flexibility in having it able to work with Xtra Reports.   

I guess I am just trying to make the reporting process seem a bit more straight foward and maybe I am complicating it more than it needs to be but for some reason reporting in .net seems to be a pain in the neck. Anyways if worse come to worse I know that I can do as you suggested and it will work.

Paul