Infragistics webGrid gotcha...

On the last project I was working on, I used Infragistic's NetAdvantage control suite to display a nicely formatted, coloured grid on my ASP.NET web pages.

Turns out the client, in testing, is binding Dataset objects to it that contain 13,000 rows or more. I knew this was a possibility, but I thought that maybe the grid would be ok with that, since it only renders a page at a time to the browser.

While that may be true, after my client's testers came back with timeouts and 7 minute page response times for some (admittedly ludicrous) queries, I had to look into it further.

It turns out that each time you call Databind() on the grid, it slurps in the entire Dataset and iterates through all rows and does preprocessing on it, and THEN it renders the page worth of HTML for transmission to the client. Hence, the actual amount of data transmitted to the browser is quite small, the “time to first page” is poor.

So, I now have to implement custom paging for the control (thank goodness its relatively easy to do that with the grid) and slurp out a smaller “sub-”Dataset from the one that is being returned by the SQL Server (and cached). Basically I will fetch the main dataset (from cache or SQL) and then if its too large to fit on a single page, I will create a new Dataset and select only a page worth of rows into it, and bind the smaller dataset to the grid.

Don't get me wrong, I really like this Grid. I just assumed it would be a little smarter about preprocessing and rendering.

Mike

3 Comments

  • They probably assumed you would be smarter about how you returned your SQL results :-)



    No one in their right mind ever returns 13,000 rows from a query to output on an ASP.NET page. Implement paging or filtering at the SQL level.

  • <rhetorical question>

    Why implement paging at the SQL Server when the grid does it for you?

    </rhetorical question>

    In this case, it is perfectly valid to return 13,000 rows to the middle tier. I would never consider sending 13,000 rows to the UI.



    Mike

  • I'd basically agree with Jesse: in most cases (OK all cases I've ever seen), it makes more sense to limit your SQL query to what you can reasonably handle in the UI layer.

Comments have been disabled for this content.