Hi Bill,



FYI the last two post in the thread may be interesting to you:



http://www.devexpress.com/Support/Center/p/Q102008.aspx



Seems that the brick may not be best for us.



Also we are able to use out existing BO. In fact all the plumping we had for Crystal seems to work fine (early day though) for DX reports.



We use an existing view to get the field list for report design and initiate the report along the lines of:



myDXreport = DevExpress.XtraReports.UI.XtraReport.FromFile(ReportDefnFile, True)



bo.FillDataTable(cmd)



myDXreport.DataSource = bo.CurrentDataTable



The bo is standard SF bo that has been created using the same technique we used for Crystal.



Not saying this is any better approach than a standard dataset - just that we already had the code and it transferred over DX Reports nicely.



Cheers, Peter

Hi Bill,



Thanks for the tip about the Angle property - I will certainly look at this further.



I will let you know if we end up using standard SF BO's (as we do now in Crystal Reports) and how we implement them in DX reports.



Cheers, Peter

The Angle property should work for the headers, unless this is deployed on a web application. I've read that the angle property does not render into a web application because of HTML limitations. You could bypass that by creating a PDF on the server then sending that to the client.

I have not tried to use vertical row/column headers. That would be interesting to look into. DevExpress has made some changes in that area recently, I think.



I've attempted to integrate the SF BO into several reports about a year ago. There are way too many complications for me to have gotten a good handle on it. The BBS and even the custom BBS adds a level of complexity that I really do not need. It is far easier for me to define a dataset, then fill the dataset from a stored procedure. I pass the dataset as the DataSource for the report (setting the DataMember, of course ) and all is well. I can render some rather complicated reports this way with very little effort. I do use some SF while doing this. Sometimes, I'll call the stored procedure from within a BO and return a dataset...often I just use the connection information in the DataBasics namespace to get me to and from the data server. Basically, my BOs handle all the CRUD operations for the specific table involved. I do not use BOs for reporting. If you'd like a code snippet, I'd be happy to put something together; however, it is pretty straight-forward.



There may be better ways for me to do all of this, but for simplicity and flexibility (and maybe a little laziness), I've chosen to stick with the old ADO.NET way of things.



Have a great day!!

Bill

Hi Bill,



We also use DX with SF but not DX's reporting (we use Crystal Reports). Our preference is to use DX reports but we have several very important production reports that are cross tabs and most fit on one page wide (depending on the data selection) however the reason they fit on one page wide is because, with Crystal Reports, row headers can be vertically orientated and, with DX reports, this isn't possible. DX put vertical pivot tables labels on their 'things to do list' more than a year ago but no progress so far. In checking with DX recently to see the progress on this I see someone has posted a possible work-around (putting a newline character between every character in a row label) - this may by ok and I plan on looking at this in the next week or so.



So, the purpose of my message - I was wondering in you could let me know how (if at all) you manage to use SF BO's with DX reports. Also, a bit of example code for complete report would also be useful.



Cheers, Peter

The following code does NOT work (it worked before 9.3.2):



Reports.ScheduleWithNotesReport mReport = new Aspire.Production.Reports.ScheduleWithNotesReport();

mReport.DataSource = ds;

mReport.ShowPreviewDialog();



The following code DOES work:



Reports.ScheduleWithNotesReport mReport = new Aspire.Production.Reports.ScheduleWithNotesReport();

mReport.DataSource = ds;

[color=#ff0000]mReport.DataMember = ds.Tables[0].TableName; [/color]

mReport.ShowPreviewDialog();



I have gone through all my code and made the necessary corrections. Everything seems to be working fine, now.



Still...it was a HUGE mistake to post that update. More testing next time. More testing.

I installed the newest version of the DevEx controls last week...v9.3.2. Everything seemed to be just fine. I had a little trouble getting all of the remnants out of the projects from previous versions (including the Inherited UI project), but once I did that the build took off and it looked like all was well. I made a couple of changes to the code that users wanted and posted the update.



HUGE mistake. HUGE.



The DevExpress reports "work", but only one record shows up. If I have a packing list with 10 items on it, only the first one shows up. If I print a production schedule only the first work order shows up. Of course, I was not aware of this until the end-users started reporting this to me yesterday.



If anyone has run into this kind of problem before and has any ideas to try, I'd appreciate them. I am uninstalling all DevEx products right now and starting over again with a new installation. I'd rather move forward with newer version rather than taking a step backward; however, the clock is ticking. I'll rollback my versions by the end of the morning today if no fix is discovered.



Thanks!