|Re: Refresh Dataset using BIRT API [message #657670 is a reply to message #657525]
||Thu, 03 March 2011 15:43
| Jason Weathersby
Registered: July 2009
The bindings on a table will map the dataset to the table columns. You
can look at them in the properties view, binding tab. They are
referencing them by name. If the column names change the bindings will
have to be updated either through code or manual intervention. One way
around this is to change the bindings to not use the column name but to
use alias or the column number. For example my column binding for one
column is mapped to
I could change this to
Keep in mind dataSetRow always contains the row count.
On 3/3/2011 2:51 AM, Jan Kohnert wrote:
> The reports data sets queries are stored procedures (defined with the
> SQL Query page, not the stored procedure page). These procedures return
> a result set with named columns. From release to release the returned
> result set may change. We always are taking care that no column will
> ever disappear from the result set. But we can not guarantee that for a
> columns position. This results in BIRT not finding the columns anymore,
> because it is locking for the columns by index, not name (I'm guessing
> here). Since the reports being in use are customizable we do not want
> them to be in need of an update once a system update happens. Updating a
> dataset automatically at runtime has the goal to avoid exceptions being
> thrown once the columns positions have changed. (Or, with other words,
> to keep the reports being runnable.).
|Re: Refresh Dataset using BIRT API [message #661548 is a reply to message #657267]
||Fri, 25 March 2011 09:19
| Jan Kohnert
Registered: July 2009
Unfortunately the work around is too complicated to offer BIRT reports for a professional health care product. To get reports run on a wide range of installed platforms using different product versions, it is not acceptable to manually check all reports after an update each time. The goal should be to have BIRT reports run as stable as possible. For us this is not guaranteed using BIRT 2.6.1. The bindings throwing exceptions under certain circumstances which make reports not being generated are THE major part speaking against BIRT.
This could be solved if it would be possible to not include any items into the bindings that are not being used as output or part of the output somewhere. To do that manually is to difficult and will result in people doing it wrong (For instance by pressing the 'Refresh' button of the 'Binding' tab in the 'Property Editor View, which result in all possible columns of a data set are included into a controls binding....). I belief, that the BIRT Designer should support the steps necessary to avoid unused bindings. Or, the BIRT runtime should be fixed in a way that when such an Exception is thrown, the report is still getting created.
I can imagine three possible solutions to fix that issue
1. When saving a report, bindings, which are bound in the 'Data Column Binding', but are not getting outputted somewhere, are removed from the 'Data Column Binding's.
1a. Alternatively the 'Refresh' button of the 'Binding' tab in the 'Property Editor View could do that job (what would be the opposite of what it is doing now)
1b. Adding a new Button that does the job.
2. The BIRT Runtime does not throw an exception as long as a bounded item is not used as output or as part of a script somewhere.
3. An easy to use API that makes it possible to update and refresh a report's dataset and bindings at runtime.
Could you please check which on of the solutions could be a possible solution, of check if there is another possible solution?
Powered by FUDForum
. Page generated in 0.02005 seconds