maximum datagrid row count?

[jason]

hello everyone,

one of my developers is working with a DataGrid component, which uses a
DataTable as its DataSource.

the DataTable is populated by a method which calls a stored procedure
through an SqlCommand object, which accepts two input parameters which
affect the query range.

the problem she's experiencing is that with all input parameter values,
the DataTable is built correctly, and has data in it (this can be
verified through runtime debugging inspection - but also through
manually running the stored procedures with all the possible input
parameter values - they all return greater than zero rows). however,
when the input parameters are least restrictive (meaning the largest
range of rows returned) - even though the DataTable has information in
it, the DataBind operation seems to have no effect whatsoever. after
the DataBind, the DataGrid displays no data.

the only thing we can think of is if the DataGrid has a limitation of
the number of rows it can display? or perhaps just a raw amount of data
that can be bound to it? that seems unlikely though, since the number
of rows being returned by the least restrictive search is only 32,581.

thanks for any help,

jason

 

[Guest]

I do not mean to sound overly critical, but, realistically, who looks at 32
thousand rows on a web page? I am not stating that you might not have the
application that is the exception, but apps that dump huge amounts of data
are generally worthless, unless you are talking about reporting (which is
killing a lot of trees to make reams of paper that never get read ;-> ).

I would try paging and see if the data shows with paging on. If so, then you
are dealing with a huge amount of data and that is your problem. Attempt two
would be to turn off ViewState for the DataGrid, as every row you write out
could be writing out many bytes of ViewState data.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Eliyahu Goldin]

32,581 rows will easily eat up all the memory available for the browser and
you will end up with an "out of memory exception" on client side. Make sure
you are not getting client-side errors.

Eliyahu

 

[jason]

you're kidding me right? 32K text data rows is literally insignificant
for client side memory concerns, unless each row is an epic poem.
thanks though.

jason

 

[jason]

paging did the trick. interesting that paging is required for a certain
volume of data. i'll tinker with the viewstate and see if that's what's
causing the threshold we're seeing.

and to your criticism, you are correct, it is reporting, but why would
you think we're killing trees? that's beauty of web-reporting, no paper

 

[Eliyahu Goldin]

Don't forget about DHTML DOM. Do you know how much memory every object
takes? I don't know, but 32K rows plus number_of_columns x 32K cells could
be too much. One of my applications used to choke up on just few thousand
rows until I limited the number of rows. It did produce an "out of memory"
exception on client.

Eliyahu

 

[Randall Parker]

Jason,

Things I'd try to check for scaling problems:

1) Try different browsers. Maybe you are hitting a browser limit. So try IE, Firefox,
Opera, etc.

2) Do an HTML GET via a non-browser method on the client and save the result to a
file. You can use Perl or other languages for sending the stuff. See if the text is
all coming back.

3) Try eliminating most of the columns in a trial build and see if you can get more
rows per page if you have less data per row.

I wonder if a large page load could cause a time-out on total transfer time. Don't
think so. But, again, using different browsers might help you control for that.