1
votes

I have a report that consists of a single table with 3 groups. The last group has 6 rows in it's footer. Each of these rows has KeepWithGroup set to Before and some of them can be hidden conditionally. When all of the rows are visible, the footer rows are kept on the same page as the detail where possible. However, when one of the Hidden conditions evaluates to true the row is hidden correctly but the other rows are moved to the next page even though they would fit fine on the current page.

If I look at the groups in advanced mode I see this

(Static)

(Group1)

(Static)

(Group2)

(Static)

(Static)

(Group3)

  (Static)

  (Static)

    (Static)       -- Don't know why this is here

      (Group4)  -- This is the detail

  (Static)

(Static)

(Static)

(Static)

(Static)

(Static)

(Static)

All of the Static rows after the detail have KeepWithGroup set to Before, but this seems to be ignored when any of them are hidden.

I've tried setting the hidden condition on the table row and on the static row in advanced mode but both cause the issue.

Any ideas?

Thanks,

Bill

1

1 Answers

0
votes

I have two ideas for you to try:

  1. In setting the advanced properties up of your grouping try to change the 'Hidden' property to an expression evaluating if there is data in the parent grouping.

    =IIF( Fields!(parentitem).value != Nothing, false, true)
    
  2. Is it okay to repeat one of the groups on a page break? Generally forcing page breaks in my experience helps with keeping data together more often than not. That and tweaking the options of 'KeepTogether' to TRUE of the 'Static' members and maybe attempting to change 'KeepWithGroup' to After instead.

I know I usually avoid the advanced mode of groupings unless there is an issue with display which sounds like you have fell into unfortunately. While debugging you may wish to see if you remove the highest parent group if the problem still persists to see where the layout is causing issues at. I know with groups that shared dependent members across multiple heirarchies there can be issues. You could also attempt doing a subreport that you know works that is called as a child of a parent member while debugging. This would not be a final result as it would be kind disjointed IMHO, but may help to see where the dependency problem lies.

I also saw another article posted by someone that had similar issues: http://blogs.msdn.com/b/robertbruckner/archive/2008/10/13/repeat-header-and-visible-fixed-header-table.aspx