Hello Handy,

Yes, this was my concern. I never actually checked those values myself, just suspected they might be occurring as it looked the like the aggregates were being calculated off only the data that was currently loaded into the grid. As I mentioned I think it is important that the aggregate values for each grouping should be complete and accurate even if every row used to calculate those values hasn't been loaded on the client-side yet.

Thanks,
Scott French

Hello Product Support,

Not fully understanding the technical details and differences between client-side binding and server-side binding I would think the best case scenario would be for these features to FUNCTION exactly the same... only we would expect client-side binding to PERFORM faster. With normal binding we could open up a group with 2000 records. That might take a more than a few seconds but at least it would open without any errors. The same problem applies to a normal loading operation (no grouping) where the virtual paging size is larger. For example on the page we are trying to convert in our application we might load a dataset with 1500 rows into the grid using client-side binding. As of today if the virtual page size is set to 350 we will get the "stop this script" error. It takes a lot more rows to get the error in the samples we've provided but the page in our application is much more complicated. We never had to worry about this error with server-side binding. The implication here is we would prefer to find a way to suppress this error prompt if possible as its potential to show up and frustrate our users is larger in scope than this discussion has revealed up until now.

If it isn’t possible to suppress the error somehow my manager had the suggestion to display group totals as x/x. For example (200/350) or (200 of 350). It would be great if we could use the same paging mechanism of scrolling down to the bottom of the group to load more records instead of requiring a button click.

Regarding issue 2: It would be best if the group totals (aggregate area) is available for a group even if all the rows are not loaded into the grid. I’m not sure what this entails but I know many of our users will group the grid just to read the totals for a certain column. If only the tops few groups have totals they will be confused.

Thanks,
Scott French

Handy, You are correct that there is no longer a (0) row count issue. The issue has shifted slightly. You can tell which rows WOULD HAVE had a (0) row count by looking at the group sum for the 'Duplicate' column. Follow the steps A. and B. from the initial post. Now instead of seeing (0) row count for some groups you will see only the top few groups have a suming area with a value for the 'Duplicate' column. From what I can tell the groups without the sums are the groups that would have had a (0) row count before this fix. When you sort the grid these groups will disappear. Originally the (0) row count groups were disappearing. Now the groups without a summing area are disappearing. I think it is the same basic issue.

Yes, issue 2 still occurs in the original sample, the only difference is now there are row counts. The groups still disappear.

It looks like issue 1 and issue 3 are resolved. Issue 2 still seems to occur. The only difference in the row counts are now there. Basically open the sample I provided above and follow the instruction for issue 2. After you sort there will be row counts for all rows, BUT you will see only the top few rows will show a grouping sum for the Duplicate column. After sorting these groups will remain but all others without a grouping sum will disappear.

I am also still seeing issue 4 (the “Stop running this script? A script on this page is causing Internet Explorer to run slowly. If it continues to run, your computer might become unresponsive.” error) in our app even after upgrading to 2009 R2. I will work to get a sample replicating this error outside of our application today.