Thank you for your details information. I succeed in replicating 1-3 issues you reported to. I have submit  them into our developer teams and they will fix this soon. For 4-5 issues, i am still not able to replicate it. Please let us know if anything that can help us to replicate the issue in here.

Regards,
Handy

4.       I haven’t been able to replicate this issue in the sample yet but I wanted to pass it along in case it is a known issue and you have a solution. Opening a Group (clicking the plus sign) that has a lot of records (a few hundred) causes an error. “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.” This occurs even after we pulled all our custom code out of client side events OnSynchronizeCell and OnInitializeRow. Is there anything we can do to speed this up? It probably has to do with the large amount of data contained in each row being retrieved.

5.       We are running into a lot of other issues with saving and deleting taking a really long time. Any feedback on converting over a large/complicated page (lots of server and client side custom code) from standard server side data-binding using “OnInitializeDataSource” to ClientSideBinding and SmartBatchUpdate would be much appreciated. We will likely follow up with more questions soon.

 Scott,

I suggest you to use "Classic Paging" mode to address the both issues above. Since classic paging mode pages on all the child records equally according to page size, it should perform faster and more reliable regardless of your data size.

The Grid also has more advanced options for data scalability when classic paging is used. Let me know if the classic paging works for you.

Hope this helps,
James.

Any update on issues 1-3? We paid for the upgrade to the grid thinking it would improve some of our speed and reliability problems but have not be able to get any use out of it due to these issues. We tried the Classic paging but it was even worse. When grouped only the items that were displayed on that page were availalbe. This would be a mess for our users as they expect to see all the data for the range supplied when they group a column. I will work to replicate the other problems we were experiencing. I can still see them in our application itself but I will try to put together a sample file that illustrates them outside of our environment.

Issue 1-3 has been resolved. You can try by using our latest hotfixes or using WebUIStudio 2009R2 product. Please keep me update about issue 4-5. Thank you.

Regards,
Handy

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.

As promised here is the updated project to replicate issue 4. Basically all we had to do was add more rows to the database table. A group with 1000+ rows is not at all uncommon in our application. In this case we actually get this error with far fewer rows (sometimes only 300+) but the grid configuration on our page is far more complicated and contains many more columns, combos, web value lists, etc.

Steps to replicate

a.      Unzip ‘JSTimeout.zip’ to its own directory.

b.      Go to Visual Studio and select Open > Web Site > and browse to the new directory with unzipped contents.

c.       Right Click on ‘ClientBinding_BatchUpdateIssues.aspx’ and select ‘View in Browser’.

d.      Group the grid by the ‘Operating System’ column.

e.      The first group listed should be ‘Operating System: All (1276)’

f.        Open this grouping by clicking the plus (+) sign and wait.

g.       An error like the screen shot I’ve attached should be displayed warning: ‘Stop running this script?  A script on this page is causing your web browser to run slowly. If it continues to run, your computer might become unresponsive.’

Thank you for your sample. I can replicate it in here. I will forward this to our developer. Btw, about issue no 2, with the sample which you gave me before, did the issue still occur?

Regards,
Handy

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

Hello,

For issue no 2. The row count 0 has been fixed, how can i see the issue?
Issue no 2, The row count 0 group dissapears after sorting. In fact, there is no count 0 anymore.

Regards,
Handy

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.

Ok,Thank you for guiding me. I can see the issue and have forwarded to our developer.

Regards,
Handy

Hi Scott,

We're currently looking at the performance issue you're experiencing. We'd like to hear your feedback on how you desire to resolve the problem.

For background information, WebGrid currently loads all rows of a specific group on demand when Virtual Load paging is enabled. In the case when thousand rows existed in a group row, the browser itself will limit such massive rendering operation, that's why you see the 'stop the script' prompt.

To address this problem, the Grid will need a major enhancement in the virtual loading mechanism. The idea is to introduce another "breakdown" or some kind of paging inside the group. In such large group case, only a small amount (user-specified) rows will be rendered. If more data is available, a kind of "more" icon will be visible in the bottom of the last row in that group. As expected, more data will be retrieved when the icon is clicked.

Do you think the proposed technique above would be a permanent solution to handle large data in grouped scenario? Please share your thoughts if you have other ideas or feedback. 

Thanks!

Here is a suggestion that the developers might be able to use to prevent this type of error:

http://stackoverflow.com/questions/1930691/stop-running-this-script-ie-for-large-ajax-requests

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

Hi Scott,

Thank you for your valuable feedback. It really help us. I will forward this to our developer teams. I think they can figure out something in order to help you.

Regards,
Handy

Hi Scott,

Thanks for your detailed reply.

Actually the "stop this script" error is not a big deal as we may found the workaround to suppress the message. The real issue we consider here is the usage of the application itself, i.e, do you really want to display such a huge amount of data to your users?

The example you sent us include a group with 1000+ records in a group. While we might be able to easily suppress the "stop this script" prompt based on your sample, still this "large data" issue could arise again, i.e, if you have 5000+ or how about 10,000+ records. 

In our preliminary test, the browser that we used (Internet Explorer 8) will throw several errors such as "Out of memory" due to its limitation in the number of objects being created and the elements being rendered (we're talking about displaying > 2000 records at once). So we can conclude that it's not effective to present such a huge amount of data in web clients (browsers) due to its limitations.

To this end, we're seeing that breaking down the rows in several chunks is more to a feasible solution in terms of scalability. So either you have 1000, 5000 or 10,000 rows, the group expand process can be done consistently fast. However, the draw back is that users will be required to click an indicator to load more data, although we don't think that's an issue since most Web applications today (such as flickr, facebook, etc) used similar approach to cope with this scalability issue.

Let me know your feedback on this matter, or if you have other ideas or thoughts. Thank you.

Hope this helps.

Here is a suggestion that the developers might be able to use to prevent this type of error:

http://stackoverflow.com/questions/1930691/stop-running-this-script-ie-for-large-ajax-requests

 

Dan, thanks for your hints. We're aware about this technique, it's mostly applicable in simpler scenarios where the code logic doesn't have comprehensive life cycle. 

FYI, in WebGrid, the event life cycle such as OnDataBound, OnInitializeRow, OnInitializeCell, OnPostDataBound, OnRender and so on -- needs to be fired consistently in correct order. And thus, the time out technique can't be used as it'll break the event life cycle.

Hi Scott,

I haven't heard from you since yesterday. Is everything fine? Let me know if you have any questions or things that unclear.

We're waiting for your final confirmation about this resolution before going into experimental build. Unless there are other better approaches, we trust that the previously suggested approach should be the most sophisticated available.

Hope this helps. Thanks!

Hello,

Just to clarify our situation a little more. There really isn’t a need for our users to view more than 200 records at a time. Currently when you group a record the grid requires every row in the group to be displayed and that is how we came across this error in testing. So if you can apply the same virtual paging logic that the grid normally uses to groups that would be fine.

As far as suppressing the ‘stop this script’ error this is something we definitely think you should do. The great thing about this product is it is so flexible… there are so many options in using it. That can also be a problem as our users often do things we would have not predicted. That might include loading two weeks of labor data into the grid (5000+ records) and grouping the results by employee or division. That may make for some very large groups. We would expect this to be possible without any errors (even if it is a little slow).

We would also expect for the aggregate area of all of these groups (despite how many rows have been loaded 200/5000 or 5000/5000) to be accurate in their calculations (sums, totals, etc in relation to the total dataset) and not disappear when you sort or filter the grid.

Thanks,
Scott French

Hi Scott,

I have discussed with our developer teams. We are seeing the issue that you reported in here (also about inaccurate calculation).
Therefore, our developer team are going to enhance our grouping in client side binding scenario. The idea about LoadOnDemand is also included. Our hope after the enhancement, it would bring better performance so our customer can use this for their application.

Once more about one issue i need to ensure.

 

We would also expect for the aggregate area of all of these groups (despite how many rows have been loaded 200/5000 or 5000/5000) to be accurate in their calculations (sums, totals, etc in relation to the total dataset) and not disappear when you sort or filter the grid.

I found an issue about grouping footer.
It will show the total for the first grouping and also incorrect total in grouping when the data inside grouping has not been loaded yet. Is this the issue that you meant? 

Regards,
Handy

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

Ok, thank you very much, Scott. Our developer teams are working on your issues right now. Your feedback is very valuable.

Regards,
Handy

Hi Scott, 

Check our our new blog post about the enhancements at: http://intersoftpt.wordpress.com/2010/01/23/introducing-virtual-group-paging-in-webgrid-7/

Your issues should have been well covered, plus several good stuff on Web/WCF Service binding, virtual load and grouping.

Please let us know if you have any feedback, thanks!

Hope this helps.

Hi Scott,

We have recently released WebUI Studio 2009 R2 Service Pack 1 which includes the fix for this issue (WebGrid 7.0.7200.401).
Please click here to read the official press release.

You could also read which fix or enchancement included in the latest build by visiting the support page and clicking the control name located on the Right Pane "Latest Builds".

Regards,
Handy

Hi Handy,

Thanks for the update. I upgraded two different branches of our dev environment with the new hotfix but in both I am now getting the error below when I try to open a page with a client binding grid.

[NullReferenceException: Object reference not set to an instance of an object.]
   ISNet.WebUI.ISNetControl.ShouldReturnJson() +98
   ISNet.WebUI.ISNetControl.ControlRequestHandler(Object sender, EventArgs e) +188
   System.EventHandler.Invoke(Object sender, EventArgs e) +0
   System.Web.UI.Control.OnPreRender(EventArgs e) +8684342
   System.Web.UI.Control.PreRenderRecursiveInternal() +80
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +842

The page loads fine initially but the grid looks to be thinking for a second or so and flashes the line "Loading dataset from Server" in the status area at the bottom left. Then this error pops up in the standard webgrid error window. Maybe this is because we only have R1?

Thanks,
Scott French

Hi Scott,

It should no problem if you are using the hotfix assemblies. Btw, have you read about the enhancement at our blog? http://intersoftpt.wordpress.com/2010/01/23/introducing-virtual-group-paging-in-webgrid-7/.

Maybe your current sample also need to be enhanced as well with new approach. Please let me know about the update.

Regards,
Handy

Hi Handy,

It looks like this version of the grid requires a '<ClientBindingSettings></ClientBindingSettings>' tag when you are using client side binding. In our previous examples this tag was commented out and everything ran. We added this tag along with PreloadGroupTotals & GroupRowPageSize and the page started loading correctly. We haven't had a chance to fully evaluate but it does look like the PreloadGroupTotals is working. GroupRowPageSize on the other hand doesn't seem to do anything. We set this to 50 then 100 then 200 but it does not seem to affect the group paging. The groups still try to load the entire collection of rows so we are still getting the script error. Is there anything else we need to do to implement GroupRowPageSize?

Thanks,
Scott French

Hi Scott,

In blog, we have introduced when using Virtual Group row in webservice, you can use WebGrid LINQ provider which is just one line of code. Actually, It takes care the row paging, etc and you don't need to worry about  the size of data rows. Perhaps I am missing something so in your scenario so it still load the entire collection of rows. Therefore, could you show me more details what did you use in your scenario?

Regards,
Handy

Hi Handy,

The blog linked above has 4 main sections. "Preload Group Totals", "Group Row Paging", "Virtual Load Support For Web & WCF Service", and "WebGrid LINQ Data Provider". We are only interested in the first two at the moment. "Preload Group Totals" looks to be working when following the directions. "Group Row Paging" is what we are talking about. All we did was add the GroupRowPageSize="200" tag into the ClientBindingSettings area. I don't see any other instructions to get this working.

Thanks,
Scott French

We have a sample of the scenario depicted in this article in our WebUI Studio 2009 R2 SP1 WebGrid sample on the page ClientBinding_VirtualGroupPaging_WebService.aspx. The sample is using the GetPagedBugs function to select the data and in the new sample, this function has been modified using technique in section WebGrid LINQ DataProvider.

You will need to modify the select method in your WebService as well using the LINQ DataProvider in order to automatically handle the select operations.

Hi Glenn,

For this page we are using InitializeDataSource and there is a large amount of code specific to our own custom DAL and security settings in this sub. Converting this page to use LINQ and a WebService would require a huge development effort that we did not anticipate. Do I understand the situation correctly? Is the only way to get Group Row Paging to work using LINQ/WebService as the datasource?

Thanks,
Scott French

I am still discussing this issue with our developer, I will inform you if there is any update or progress regarding this issue. 

Hi Intersoft,

I'm using WebGrid 6 and I have the same issue like Scott have with large data and grouping function.

Did you add virtual group paging to webgrid 6? I think webgrid 6 and 7 are not differences too much.

Can I use service pack of Webgrid 7 for version 6? I need this function in urgent case.

Thanks,

Huy

Hello Huy,

Unfortunately, this could not be done. WebGrid 6 has been discontinued. So, there would be no enhancement and hotfixes. We suggest you to consider in upgrading WebGrid 7.

Regards,
Handy

Hi Intersoft,

I was tried to upgrade to WebGrid 7 but your example didn't work for me. When I try to expand a group, an exception appeared:

"Message":"A circular reference was detected while serializing an object of type \u0027System.Reflection.Module\u0027.","St...

I attached my sample to you.

I'm using ASP.NET 2.0 and VS2005 C#. I'm not using LINQ or ISNET LINQ DataSource, just only ADO.NET: DataSet and DataTable.

This is list dll I used in sample : Webgrid version is 7.0.7200.417 ; WebDesktop is 3.0.7200.322 ; WebCombo is 4.0.7200.232 ; System.Web.Extensions Version is 1.0.61025.0.

I'm not use ISNet.Data.Ling.dll

Another problem is the loading time for dataset with 500 rows. In my sample, I can see the progress icon loading take about 25s for just only 500 rows. Is this normal that loading webservice with 500 rows take about 25s? In my real application, I was faced to large data with more than 10.000 rows.

Please help me investigate why it couldn't run and is the webservice peformance too slow or not?

Thanks,

Huy

Hi Huy,

Please create a new thread for the new issue. Thanks.

Best Regards,

Gordon Tumewu

Hi,

I was create new issue at this link http://www.intersoftpt.com/Community/WebGrid/Cannot-use-VirtualGroupPaging-with-WebService-and-ADONET/

Thanks,

Huy