Home/ Questions/Q 8398011
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T20:55:39+00:00

I have the common problem of not wanting an empty report to be distributed

  • 0

I have the common problem of not wanting an empty report to be distributed to useres when there’s no data for a particular set of parameters.

But I’m not dealing with subscriptions: I have a small app that generates the report as a PDF via web service calls. (Subscriptions, for various reasons, weren’t workable in this environment.) The app is ignorant of the specifics of the report it’s generating, so I can’t have it run the queries in advance, and throwing some kind of exception in the proc when there’s no data would just confuse the web service caller.

But it did occur to me that I might be able to retrieve my reports first as XML, which I could inspect, and then as a PDF if the returned XML showed that data was present.

The downside to this, as I see it, would be that I’d be generating any report with data twice, which cumulatively would be costly. There may be other disadvantages that I haven’t thought of.

You might ask whether I couldn’t do some kind of inspection on the PDF to see if it was empty. What’s keeping me from pursuing that is that the PDF has page headers and footers, and the empty reports I get are in fact one-page reports that include header and footer. Inspecting them for data would be a daunting and very klugy task.

So, has anyone tried this? Could it work?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ll start by answering your questions. I personally haven’t tried this, but I suppose it could work. Skimming the Render documentation it seems you may even get the XML and PDF rendering to both use the same, cached data, though I’m not entirely sure.

    Alternatively, if you have several reports with this issue, you may be able to delegate the Yes/No check for mailing the report to a seperate meta report. The meta report would just have a table with two columns:

    • Report name
    • Should be mailed

    You could render this report once, to XML, and based on that result mail the other reports (or not). This may work best if the data for the other reports is contained, for example in views, so you can just run COUNT(*) on those views for the meta report.

    • 0