Community
Participate
Working Groups
Open the attached report (or pretty much any non-trivial report). The report appears to incorporate two sets of column bindings, and this is both confusing and tedious. Here is why. First, notice the data set. In the data set, I can map column names, assign data types, and define display names for input columns. Very good. I can add computed columns. And, I can preview the resulting data set. All excellent. Now, look at the table in the report, specifically the Binding tab of the property editor. Here we have a whole separate copy of the data set binding, but with much more restricted semantics. * The user cannot change the column names. * The user can assign a display name, but the display name is never used (not even the display name on the base data set.) * The user can change the data type, but then I could have done that on the data set. It seems awkward to have two separate mappings. * The user cannot remove columns. Or, rather, the user can do so temporarily, but they are put back on the next press of the Refresh button. It appears that BIRT requires that all columns in the data set be shadowed in the table, but relies on the user to ensure that this is done. * Columns added to the data set don't appear in the table binding until the user explicitly refreshes. (See comment on above bullet.) In short, the table bindings for data set columns adds no functionality that is not already available in the data set. (Specifically, data type and display name can be set -- and tested -- in the data set.) But, the table bindings do create work for the user who must remember to delete columns dropped from the data set and press "Refresh" to add new columns. It is not clear, really, what value the user gets from doing this. Will the report still run without doing the refresh? And, data items are added by dragging and dropping from the data set, not the table column bindings, so it is not even clear what the data set column bindings are doing. Further, the bindings presumably add bulk to the design file, making it that much harder to understand and to do diffs with previous versions in a source control system. In short, given all these issues, expected the data set column bindings to be handled implicitly. They are available when need be, but are not explicitly copied within the design file. That is, it is not clear how the data set column bindings on a table are ever used in the designer except to appear in the bindings tab. But, if they are used somewhere, the designer could certainly grab them from the data set rather than from the copy on the table. If they are needed at runtime, then they are generated then. The result would be a simpler user experience. The data set columns defined on the data set are available, including data type mapping, name mapping and display names. There is no need to worry about the copy on the table.
