Skip to main content
Answer

Run subreport based on conditions

  • November 7, 2023
  • 3 replies
  • 244 views
T
Semi-Pro II
Forum|alt.badge.img+1

I have a report that I’m using check boxes to ask the user to include data.  It’s timing out because the dataset is large, however, if I can make my subreports conditional it will reduce processing time.

 

The subreports are located in the “detailSection” and are set to “WhilePrint” and Visible = False with a VisibleExpr of “=[@IncludeThis] = True “

 

If @IncludeThis <> True I want to exclude the subreport from running at all. 

Best answer by mbridges00

Without more information on the specifics of the report you’re running it may be difficult to give an exact solution here, but here’s some typical ideas I usually follow to help processing speed.

 

Are you only getting information from your subreport to send back to your main report via variables, or are you actually displaying the contents of the subreport, depending on the visibleExpr?

 

  • If possible, Try moving subreport from detailSection to a headerSection, as it may reduce the amount of times main report is calling subreport (and underlying SQL queries).
  • Set a variable to send to your subreport (like your @IncludeThis), so that it only actually runs the subreport if needed. You can add this to your filter parameters on the subreport.
  • Review and check for optimizations on the DAC joins on both reports to reduce duplicated/unneeded records. You can use the Trace Profiler to get a better idea of the underlying SQL queries.

 

These are general points and it depends on your specific use case, so If these are not helpful, you could provide your .RPX file of both main and subreport to help review.

 

🚀If I have helped you, "Like" my post. If it solves it mark "Best Answer". 🚀 ➡️ www.linkedin.com/in/-travis-lawson-/

3 replies

M
Jr Varsity II
Forum|alt.badge.img+1
  • mbridges00
  • Jr Varsity II
  • Answer
  • November 8, 2023

Without more information on the specifics of the report you’re running it may be difficult to give an exact solution here, but here’s some typical ideas I usually follow to help processing speed.

 

Are you only getting information from your subreport to send back to your main report via variables, or are you actually displaying the contents of the subreport, depending on the visibleExpr?

 

  • If possible, Try moving subreport from detailSection to a headerSection, as it may reduce the amount of times main report is calling subreport (and underlying SQL queries).
  • Set a variable to send to your subreport (like your @IncludeThis), so that it only actually runs the subreport if needed. You can add this to your filter parameters on the subreport.
  • Review and check for optimizations on the DAC joins on both reports to reduce duplicated/unneeded records. You can use the Trace Profiler to get a better idea of the underlying SQL queries.

 

These are general points and it depends on your specific use case, so If these are not helpful, you could provide your .RPX file of both main and subreport to help review.

 

Chris Hackett
T
Semi-Pro II
Forum|alt.badge.img+1

Without more information on the specifics of the report you’re running it may be difficult to give an exact solution here, but here’s some typical ideas I usually follow to help processing speed.

 

Are you only getting information from your subreport to send back to your main report via variables, or are you actually displaying the contents of the subreport, depending on the visibleExpr?

 

  • If possible, Try moving subreport from detailSection to a headerSection, as it may reduce the amount of times main report is calling subreport (and underlying SQL queries).
  • Set a variable to send to your subreport (like your @IncludeThis), so that it only actually runs the subreport if needed. You can add this to your filter parameters on the subreport.
  • Review and check for optimizations on the DAC joins on both reports to reduce duplicated/unneeded records. You can use the Trace Profiler to get a better idea of the underlying SQL queries.

 

These are general points and it depends on your specific use case, so If these are not helpful, you could provide your .RPX file of both main and subreport to help review.

 

I’ll try to move them to a header.  I am using variables to pass back, not to the subreport though to run as needed.  That’s an idea I didn’t think about.

Here’s the RPX’s:    https://file.io/Ufjz6GKsRrhq

The IC600100pdamt.rpx should be named:  IC600100pd.rpx

 

🚀If I have helped you, "Like" my post. If it solves it mark "Best Answer". 🚀 ➡️ www.linkedin.com/in/-travis-lawson-/
T
Semi-Pro II
Forum|alt.badge.img+1

@mbridges00:  Moved the subreports to the header and passed the @IncludeThis to the parameters and also into the filter of the subreport…  @IncludeThis = TRUE.  Definitely made it faster.

🚀If I have helped you, "Like" my post. If it solves it mark "Best Answer". 🚀 ➡️ www.linkedin.com/in/-travis-lawson-/
Chris Hackett
Terms & ConditionsCookie settingsAccessibility statement
About Acumatica ERP system
Acumatica Cloud ERP provides the best business management solution for transforming your company to thrive in the new digital economy. Built on a future-proof platform with open architecture for rapid integrations, scalability, and ease of use, Acumatica delivers unparalleled value to small and midmarket organizations. Connected Business. Delivered.
© 2008 — 2024  Acumatica, Inc. All rights reserved