Planned for "Unassigned" - BIRT Reports

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.

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.

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