Solved

Devexpress report stays empty


Userlevel 3
Badge +10

In the software factory I defined a report with two parameters. These parameters also exist in the Devexpress file uploaded to this report. After running the report in the Windows GUI the debug info clearly shows the report was fed with the correct parameter values. However apart from the static headers that exist in the design the resulting file remains empty. No data is retrieved from SQL Server. I’ve tried both PDF and XLSX as output with very similar result.

When I open the file in Devexpress from the cache folder as mentioned in the debug info and then enter the same parameter values there the report does work. This suggests the GUI does not communicate the parameter values to the report.

I haven’t seen a form or task to link a specific parameter in SF to its counterpart in the report file so I assume parameters in SF need to have the same name as those in the report file. Is that correct? If so what could I do to make the GUI produce a complete report?

icon

Best answer by Mark Jongeling 4 November 2021, 13:20

View original

10 replies

Userlevel 7
Badge +19

Hi Roland, 

Although I'm not sure if it's necessary, but having the same names for parameters in SF and in the Report is recommended. Have you tried naming the parameters the same as in DevExpress and see if that fixes the problem? You could also make sure the data types are the same to avoid data loss that way.

Userlevel 3
Badge +10

Hi Mark,

It turns out the issue only occurs when a report contains a sub-report as a separate file. Is this a known issue?

Unfortunately in this case integrating the sub-report into the main report file is impractical if not impossible because it would require the report to filter way too much data. This is now done in the query of the sub-report to improve performance.

Userlevel 7
Badge +19

Hi Roland,

That is currently not possible this way, on our docs we do recommend another method: 

Because reports are stored in the database, you cannot use sub-reports as separate files. For a solution, see Create a Master-Detail Report with a Detail Report Band.

Could this be the solution your are looking for?

Userlevel 3
Badge +10

Interesting, for some reason I hadn’t noticed that part in the docs before. In our case using detail report bands only is very inefficient. The report prints out tens if not hundreds of invoices for a customer. These invoices contain details on 3 different levels. Having only detail report bands makes it impossible to prefilter data per invoice. This results in the report itself having to do the filtering after requesting a huge load of data from the database. Devexpress does not like that and ends up with an error message. I’m not sure what exact error it was but we decided in quite an early stage that an all levels in one file approach is not the way forward.

Actually this is rather disappointing. Our report works and it works fast. It just won’t work in our end-product.

Userlevel 3
Badge +10

(I typed another rather lengthy answer here but it disappeared after a message saying that it was too long with no way to get it back.)

Userlevel 7
Badge +19

Maybe it's an option to already prepare the data in SQL beforehand so DevExpress can simply select the data from the table instead of having to filter by itself?

From experience, I know some Partners prepare the data used in the report beforehand by calculating all data when executing a task, then in the report simple select the data from the just-prepared table. Data could be username-separated so multiple people can generate reports at the same time. Then when you generate a new report, delete the old data and insert the new data for the report to use. Hope this helps regarding the performance issue.

Userlevel 3
Badge +10

Hi Mark. It’s been a while due to other projects. We’re still facing this issue. Problem is we can’t filter the data anymore than we already do. One of our reports is used to print a pdf of all invoices of a certain type for a customer for the entire month. In quite a few cases that can mean hundreds of invoices.

The issue is that our invoices exist of 3 levels meaning 3 tables (main, articles and sizes) are being tied together to form an invoice. So if we want to create a pdf of say 200 invoices we need to feed the data of 200 invoices of all these levels into the report. That’s a lot of data to be structured via the table relations in the report. When we run the report and there are too many invoices Devexpress stops with an error message. When we try to run it in our end-product it just keeps trying forever. Unless there aren’t too many invoices because then all is fine and actually quite fast.

I wouldn’t know how to further limit the amount of data with an all-in-one report. It is possible with separate sub-reports though. In that case the sub-report is a single invoice tied together with the other invoices by the main report which on its turn is basically a list of all the relevant invoices. With sub-reports Devexpress renders the invoices one by one whereas with an integrated report Devexpress has to structure all the required data at once. With sub-reports it doesn’t matter how many invoices there are. It always works.

I’ve tried to come up with another per-invoice method but I really don’t see how to do it other than separate sub-report files. Which I now know Thinkwise doesn’t support but if that really is the only practical solution I am very keen to hear your point of view. Don’t any of your other customers have this issue?

Userlevel 3
Badge +10

Just to be clear. When we feed these 200 invoices into the report we only feed the relevant data. That means all the main info, articles and sizes of those 200 invoices. Filtering is applied in all queries of the report.

Userlevel 7
Badge +19

Hi Roland, In GUI release 2021.3.13 the DevExpress component has been upgraded to a newer version which should result in performance improvements. Can you check again with that GUI if the performance is better?

Else, I asked around within Thinkwise and the method I proposed earlier is the way-to-go. By preparing all data the Report needs, do the filtering and such, the data only needs to be transported into DevExpress to generate the report. That really helps a lot. The table structure you have in DevExpress can be cloned in your own database to prepare the data in. Try and not use views for this as that might actually cost more performance than having tables. I can assist in this sometime if necessary.

In the upcoming 2022.1 release, you'll be able to generate reports in the background using process flows (Indicium). That will certainly help too.

Userlevel 3
Badge +10

Thanks Mark. I will definitely try your suggestions. I have to admit I am a bit skeptical about using tables because it doesn’t make the data set going into the report any bit smaller. The queries by themselves also aren’t difficult to process but even if they were the work to produce the results is done by SQL Server and not the report. But I will give it a try as soon as I have the time and then post the results here.

Even if it works I would still like to emphasize that reports with separate sub-report files are much easier for Devexpress to process without the need for report tables. I wish detailreport bands would have their own set of parameters and worked similar to sub-report files but unfortunately that is not the case.

Reply