Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 350117

Summary:

"Bottom n" and "Greater than" filters on same crosstab group level results in runtime exception

Product:

z_Archived

Reporter:

Kevin Rahe <KevinR>

Component:

BIRT

Assignee:

Lin Zhu <lzhu>

Status:

RESOLVED FIXED

QA Contact:

Xiaoying Gu <bluesoldier>

Severity:

normal

Priority:

CC:

bluesoldier

Version:

unspecified

Target Milestone:

3.7.1

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
Sample report in which the problem is manifested	none
Exception logged by a different report with the same problem	none

Description Kevin Rahe

2011-06-23 00:19:36 EDT

Build Identifier: M20100909-0800

Creating a "Greater than" filter based on an aggregate value directly from the cube and a "Bottom n" filter for the same group level based on a derived value on a crosstab report results in an exception.

Reproducible: Always

Steps to Reproduce:
See attached test case based on Classic Models.

Comment 1 Kevin Rahe

2011-06-23 00:22:32 EDT

Created attachment 198441 [details]
Sample report in which the problem is manifested

Comment 2 Kevin Rahe

2011-06-23 00:24:01 EDT

Created attachment 198442 [details]
Exception logged by a different report with the same problem

Comment 3 Kevin Rahe

2011-06-23 00:26:08 EDT

While there are other issues with defining multiple filters on the same group level in the same crosstab, such as the inability to control the order in which they're applied (suggested enhancement there), doing so shouldn't result in an exception despite any other caveats.

Comment 4 Kevin Rahe

2011-06-23 00:27:46 EDT

This problem exists in BIRT 3.6.1

Comment 5 Kevin Rahe

2011-06-23 10:49:45 EDT

I have found a workaround until this problem is fixed.  Instead of referring to the derived column in the formula for the "Bottom n" filter, reuse the formula that computes the derived column's value as the filter's formula (in the attached sample that would mean replacing 'data["HALFEXTPRICE"]' with 'data["EXTPRICE_Order/ORDERNUMBER"] / 2').  This will avoid the exception.  (Though it still won't provide any control over the order in which filters are applied, which I would still suggest as an enhancement.)

Comment 6 Lin Zhu

2011-07-04 03:35:20 EDT

Thank you for the detailed info.The bug is fixed in latest build.