Planned for "Unassigned" - BIRT Reports
Hi,
I'm trying for a report using LIVE_SNAPSHOT on Project Area X with following conditions. Status of workitem is New and Planned for is Unassigned. In report designer , when I try to use a filter for Planned For, in the select list I don't see "Unassigned". Instead I see "{Null}". Are these two same? Using "{Null}" doesn't give me correct results. Any ideas? Thanks, Bharath |
15 answers
Which version of RTC are you using? 2.0 or 2.0.0.1?
|
Which version of RTC are you using? 2.0 or 2.0.0.1? Hi Rafik, itz RTC 2.0 Thanks, Bharath |
|
Any chance trying your report on a 2.0.0.1 or 2.0.0.2 server? We fixed sveral issues related to the handling of null in 2.0.0.1.
|
Any chance trying your report on a 2.0.0.1 or 2.0.0.2 server? We fixed sveral issues related to the handling of null in 2.0.0.1. We are still in the process of migrating to 2.0.0.1. But to my question, "Unassigned" should be listed in the "Planned For" right? |
Any chance trying your report on a 2.0.0.1 or 2.0.0.2 server? We fixed sveral issues related to the handling of null in 2.0.0.1. We are still in the process of migrating to 2.0.0.1. But to my question, "Unassigned" should be listed in the "Planned For" right? Anything on this? --Bharath |
|
Can you please create a work item and attach the report design that has the problem?
|
Can you please create a work item and attach the report design that has the problem? Hi Rafik, here is the workitem. I have attached the design file. https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=102147 |
|
Unassigned is stored in the Data warehouse instead of null for all string values. We decided to do that to keep things simple.
Live tables that originate from the jazz repository (as opposed to the data warehouse) will return {Null} for null fields. {Null} can also be passed to data set parameters. I attached a modified version of your report that passes {Null} to the target.name data set parameter instead of using a BIRT filter. I tried this on 2.0.0.2 and it worked for me. If this does not work for you, it is probably because of a bug that was fixed in 2.0.0.1 or 2.0.0.2. Try to avoid using BIRT filters. These do not translate into an SQL WHERE clause. Instead, all the data will fetched and the filter will applied to the data. This tends to be slow and can cause out of memory problems. I also noticed in your data set, you are fetching the work item id, state id and creation date. Fetching these will increase significantly the number of records you get back from the data set as the aggregate field recordCount will always be 1. |
Unassigned is stored in the Data warehouse instead of null for all string values. We decided to do that to keep things simple. Rafik, I still see the issue on 2.0 . May be I need to try on the latest version Try to avoid using BIRT filters. These do not translate into an SQL WHERE clause. Instead, all the data will fetched and the filter will applied to the data. This tends to be slow and can cause out of memory problems. Thanks for the tip, will keep in mind. I also noticed in your data set, you are fetching the work item id, state id and creation date. Fetching these will increase significantly the number of records you get back from the data set as the aggregate field recordCount will always be 1. I have used these fields for testing and validating the retrieved data. |
I attached a modified version of your report that passes {Null} to the target.name data set parameter instead of using a BIRT filter. Rafik, Is there a way to pass a value to the parameter conditionally? For example, I would like to use the following condition where workitemtype is the parameter: if (resolutioncode == 'Fixed'){ workitemtype is (defect,task,enhancement) } else{ workitemtype is defect } --Bharath |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.