nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Cascading Parameters Not Working in Runtime

TomTroll

Just moved to BIRT 3.7.1. Also upgraded Runtime to 3.7.1 on server.

All old reports (2.x vintage) work including those with cascading parameters.

New reports (3.7.1) on new database with cascading parameters (dynamic, combo box, multiple data sets) work fine without errors or problems when run as HTML, pdf, & Viewer from within BIRT. However, when reports are uploaded to server and run in the Runtime viewer, the cascade displays first parameter list, but then fails to display dependent options at next level down. There are no error messages -- just no selection options on the cascade. Data is identical on server and development machine.

Any thoughts would be appreciated.

Thanks,
Tom

Find more posts tagged with

Comments

mwilliams

Hi Tom,

So, any report you design in 3.7.1 with cascading parameters does not work when you deploy the report? But all older ones do, when deploying on the same runtime?

Also, do other reports designed in 3.7.1 work fine? Meaning ones without cascading parameters? Let me know. I'll take a look.

TomTroll

<blockquote class='ipsBlockquote' data-author="'mwilliams'" data-cid="94810" data-time="1328034367" data-date="31 January 2012 - 11:26 AM">
Hi Tom, 
 
So, any report you design in 3.7.1 with cascading parameters does not work when you deploy the report? But all older ones do, when deploying on the same runtime? 
 
Also, do other reports designed in 3.7.1 work fine? Meaning ones without cascading parameters? Let me know. I'll take a look. </blockquote>

TomTroll

Actually, no. Just to be cautious, I blew away the entire runtime on the server, downloaded the runtime completely new, and re-installed it to the server.

I then created a new report in 3.7.1 without cascading parameters and it works perfectly on the dev machine; no errors and the report is correct -- as are the reports with cascading parameters. However, when I upload that same new report with no cascading parameters to the server, the report comes out in a totally different order, fails to properly group the data, and produces a report with major errors. The reports created with 3.7.1 that have cascading parameters still fail completely in the parameter selection, but if I insert the correct id numbers for the cascade, the report runs perfectly. It is only the cascade that is failing.

Previously, I ran other reports developed with 2.x to see if the cascading parameters were working, but did not check the detailed validity of the older reports' output. I guess I need to look at that, but should not have to.

To me, the runtime output should be identical to the development output given identical data which I have re-verified. Since the reports work without error on two different dev machinges, but not when using the runtime on the server, it tells me that the runtime viewer has major differences compared to the BIRT development viewer.

Do ya' think that logical and possible?

Tom

Tom

mwilliams

Sorry for the delayed response. Is this reproduce-able with the sample database?

TomTroll

<blockquote class='ipsBlockquote' data-author="'mwilliams'" data-cid="94988" data-time="1328306534" data-date="03 February 2012 - 03:02 PM">
Sorry for the delayed response. Is this reproduce-able with the sample database? </blockquote>

TomTroll

Have have no time to even try to create a report with the sample database. Have never done anything with the sample data base. I have two property evaluations that have to be done this weekend, so am not sure if I can do anything toward creating new reports with the sample database until next week.

mwilliams

I was not able to reproduce the issue in 3.7.1 with cascading parameters. I was only able to deploy to Tomcat on my own machine, though. Are you using more than one dataSet in your cascading parameters? Or just one?

TomTroll

There are multiple data sets.

mwilliams

Ah. Ok. I'll try setting up a little more complex one.

TomTroll

<blockquote class='ipsBlockquote' data-author="'mwilliams'" data-cid="94998" data-time="1328314567" data-date="03 February 2012 - 05:16 PM">
Ah. Ok. I'll try setting up a little more complex one. </blockquote>

TomTroll

I worked on the 3.7.1 stuff about 7 hours today, but at some point enough is enough. I blew away the Runtime 3.7.1 on the server plus 3.7.1 and Eclipse on my dev box. I downloaded 2.6.2 BIRT All in One and installed it on the dev box. I downloaded 2.6.2 Birt Runtime and installed it on the server.

Without ever opening and saving the problem reports in 2.6.2, I ran them on the server. ALL ran without a problem. I then opened all of the reports 3.7.1 reports in 2.6.2 without a problem and then ran them in the development viewer without a problem. I then uploaded those reports saved in 2.6.2 to the server and re-ran the them. All run without a problem.

The entire process took about 90 minutes. Wish I done it a couple of hundred hours ago.

Don't know why 3.7.1 is doing what it is doing or why others have had no problems, but this problem is solved for the present.

Thanks,
Tom

mwilliams

Tom,

Definitely log a bug for this in the bugzilla on eclipse.org. Sorry you wasted so much time on this. Hopefully it is something known that will be fixed in 3.7.2, so you can upgrade then!

TomTroll

<blockquote class='ipsBlockquote' data-author="'mwilliams'" data-cid="95014" data-time="1328423193" data-date="04 February 2012 - 11:26 PM">
Tom, 
 
Definitely log a bug for this in the bugzilla on eclipse.org. Sorry you wasted so much time on this. Hopefully it is something known that will be fixed in 3.7.2, so you can upgrade then! </blockquote>

TomTroll

Michael,
I appreciate your time and efforts. And you are correct: I have time to wait until 3.7.2 or higher. The amazing thing is that, based upon the basic nature of the reports, there have been no other reported problems. Thanks, again.
Tom