Community
Participate
Working Groups
Created attachment 93722 [details] Sample report design Open the attached sample report. Decide to delete the data field called "Column Binding". Go ahead and delete it. Select the table. Look in the Bindings tab. Notice that the column binding for the data item still exists. You have to manually delete that as well. In general, add a data item and bind it to something in the table "row". Delete it. Expected that, at this point, the design would be back to the way it was when I started. Did not expect to have to do two separate tasks for each deletion.
We can't not just delete the binding. But maybe we can enhance the usability by providing a prompt or something.
Created attachment 93894 [details] Product Sales by Country.rptdesign
The whole table column binding area has some tender points. I've filed the following related bugs: Bug 224253, Bug 224263, Bug 224491, Bug 224498 It seems that the binding functionality works, but is very tedious to use. Bug 224015 offers some thoughts on how to resolve this issue by deferring most binding to runtime. In this case, the Designer should just assume that the table has access to all columns from the data set. There is no need to copy the columns to the table at design time, then force users to maintain the list. There is only one right way to do the data set binding: ensure that the table contains a binding for each column in the data set with no extras and no missing bindings. Because there is only one right way to do this, the software can do it automatically at run time, and can assume this binding at design time. It is of no value to the user for the user to be required to keep the two lists in sync. Thus, this is fundamentally an ease-of-use issue. There are probably underlying technical issues; but, as a user, I just see the extra work I must do.