If you are unable to create a new account, please email support@bspsoftware.com

 

News:

MetaManager - Administrative Tools for IBM Cognos
Pricing starting at $2,100
Download Now    Learn More

Main Menu

Conditional Rendering

Started by nosub, 05 Oct 2007 10:24:58 AM

Previous topic - Next topic

nosub

Hi All,

I have a report which will be scheduled to run daily. Right now, it is indevelopment and it filters its data based on several prompts, but since it should be automated once it rolls out into production, I cannot use prompts. 

Instead, I would like to be able to pass values to the report by which it decides what to
filter on and which pages to render.  I have tried creating a variable and using a query item in the
report to determine whether it renders the page or not, but I guess the query isn't run before it attempts to evaluate the condition of that variable, so it does not recognize the query item I'm referring
to at the time of making the decision...and so, it does not validate the variable.

So here's my question...Do I need a parameter map to accomplish this? And if so, I'm having a hard time understanding how it works simply from the documentation provided with Framework Manager and Report Studio. Would someone please shed some light on this...and in particular, using a parameter map for rendering

MFGF

Hi,

It's possible you can leave your prompts in place and put the report into production.  From Cognos Connection, you can define default values to pass to the prompts in the properties of the report - these are used when the report is fired off as part of a schedule or as a batch process.

If different groups or users need to see different items rendered, you can set up a separate report view for each, and again define default prompt values for each view.

Does this give you what you need?

Best regards,

MF.
Meep!

nosub

Here's the problem with that though:  The report would give out about 70,000+ permutations...and that means the same number of report views.....so too much inventory to keep on the server.

What I'm trying to do is have a table with those permutations...and a flag on each combination that when set to 'Y' would pass the corresponding values to the report and tell it to run and save to a certain directory.  So, everyday, it would go down the list and run the report for each record for which the flag is active...and save each file to that directory.

rockytopmark

70,000???  Are there 70,000 different users?  Who will be looking at the report... will all 70,000 permutations actually be viewed and used?  Wouldn't your Parameter Map require 70,000 entries?  That is about 69,950 more parameters than I would care to have to maintain.

Just trying to grasp the audience for this report.  It seems too daunting to me.  Why not leave it self-service... and let the Users set the parameters at run-time?

I'd say with the # of permutations, you may need to think about a redesign.

MF's suggestion of using Views is the best way to go, if there is a smaller number of repeated runs happening.  If there is no View created for a specific combination of parameters, then let the user execute the report.


Can you shed a little more light on the purpose of the report, the audience and scope of the report?  That may be helpful in determining a solution.

nosub

Ok...here's the situation.  This report is made to run daily and burst by product name, dealer number, form number...etc...producing 70,000 or so total reports.  However, only the first run of this will require producing all the reports...After that, there'll be a db table to query and determine what reports have had a price change and therefore need to be run and re-saved in a network directory.  So at all times, there should be a report for every permutation in that directory.

The thing is, that not all product/form combinations use all the pages...so some of the report pages do not return any data and I would like to have them not render.  And due to the nature of the data, I can't have a parameter map for every page that tells me whether or not to render, because I cannot know beforehand which pages to render for what combination...I have to determine that on-the-fly.

I hope that cleared things up a bit...I agree though, this report is a pain and the most complex one I've come across.

nosub

#5
To put it simply...I want the report pages to render only if the associated query returns rows.

Another related question is how do I create a stand-alone parameter (I mean 1 that is not explicitly tied to a prompt) in a report...to be able to pass values into it at runtime?  I know I can create a calculation to use a parameter map, but again, that would be a query item, which would not allow me to evaluate it before the query runs...and conditional rendering would fail.