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.

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.

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?

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.

(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.)

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.

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?

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.

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.

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.

Hi Mark,

Can we now use the sub report from DevExpress?
For me I am getting below error: 

Prockees.Bootstrapper.ExecutionException: System.IO.FileNotFoundException: Could not find file 'C:\inetpub\wwwroot\indicium_nutland_ota\Cache\TempFiles\sub_report_vat.repx'.

Hi @Rucha Naik,

Subreports are not supported to my knowledge. We do have an idea for this here: DevExpress SubReport | Thinkwise Community (thinkwisesoftware.com)

Thanks for your quick reply Mark.

I created a separate report for sub report in SF. However do I need to add it as process action in the process flow too , in order to generate it ? As how you mentioned below:
There's an alternative way of achieving the use of Subreports for Windows GUI 2-tier (without Indicium). You can insert the subreport as a separate Report in your Software Factory project. This will ensure that the GUI caches the Report and the Subreport in the same folder, making it available for the Report to use.

Cause currently it still shows the same error for sub report missing from the folder.

You can insert the subreport as a separate Report in your Software Factory project. This will ensure that the GUI caches the Report and the Subreport in the same folder, making it available for the Report to use.

Whilst this might work right now in the Windows GUI, I'm unsure this is future-proof. It might only work when combined with the Start (table) report process actions. The Generate report process action cannot be used for this I think.

Best thing is to raise this need for subreports with your Thinkwise representative/account manager, and of course voting the idea.

To support subreports, we would have to design it first and thereafter implement it, but we currently don’t have it planned.