No, what I said was, if I _explicitly_ dump the _DataSet_ into the
ViewState, it takes up 2 megs. the DataGrid
itself places its own data in the viewstate already. What I want to to is
simply let the DataGrid do its own job - retrieve
its own view state.

Have you tried calling SaveViewState or LoadViewState on a DataGrid? The
last time I did it failed miserably, the compiler
told me that I'm not allowed to call that method.





Feduke Cntr Charles R <FedukeCR@m...> on 08/08/2002 08:49:31 AM

Please respond to "ASPX_Professional" <aspx_professional@p...>

To:   "ASPX_Professional" <aspx_professional@p...>
cc:

Subject:  [aspx_professional] Re: Composite Server Control containing a
      DataGrid & ViewState...Please Help


Kevin,

     But you said you had something like 2.8 MBs of ViewState data - in
this case I would definately want to keep something like that on the server
in Session[].  As far as ViewState, make sure you have not explicitly
disabled it, and try something like this...

// assuming _dataGrid is a private instance of your DataGrid control
protected override object SaveViewState()
{
     // add whatever else you want here; if you
     // do, use an array
     return _dataGrid.SaveViewState();
}

protected override void LoadViewState(object savedState)
{
     _dataGrid.LoadViewState(savedState);
}

HTH,
- Chuck

-----Original Message-----
From: Kevin_Hoffman@c... [mailto:Kevin_Hoffman@c...]
Sent: Thursday, August 08, 2002 9:27 AM
To: ASPX_Professional
Subject: [aspx_professional] Re: Composite Server Control containing a
DataGrid & ViewState...Please Help



I see your point. My problem is that when a DataGrid is placed in a User
Control, it knows how to reconstitute itself
from the viewstate ... so how can I get it to rebuild itself from viewstate
when its placed in a composite server control? The items
in the dataset are not lookup data, they're search results, and as such as
highly expensive to re-retrieve on postback.





Feduke Cntr Charles R <FedukeCR@m...> on 08/08/2002 08:27:47 AM

Please respond to "ASPX_Professional" <aspx_professional@p...>

To:   "ASPX_Professional" <aspx_professional@p...>
cc:

Subject:  [aspx_professional] Re: Composite Server Control containing a
      DataGrid & ViewState...Please Help


Kevin,

     You're probably going to have to just rebuild the data from the data
source each time the page posts backn if you don't want to use Session[] or
ViewState - I mean the data has to go/come from _somewhere_.  You'd never
have 4000 copies of the same dataset in Cache[] - you'd use Session[] for
that type of stuff.  The Cache[] is useful for storing DataSets that you
use
as lookup tables (like state abbreviations, lists of document types, etc -
fairly static data that doesn't change often) - this prevents your
application from having to make a dozen or so connections to get all of the
information for your DropDownList boxes.

- Chuck

-----Original Message-----
From: Kevin_Hoffman@c... [mailto:Kevin_Hoffman@c...]
Sent: Thursday, August 08, 2002 8:56 AM
To: ASPX_Professional
Subject: [aspx_professional] Re: Composite Server Control containing a
DataGrid & ViewState...Please Help



My application requires a support of 4,000 concurrent users. That DataSet
is by no means small. I would cripple
the application by stuffing that many copies of the DataSet into the cache
object. But that is one good work-around for
small bits of data, though. Thanks.






snarula@s... on 08/07/2002 07:17:45 PM

Please respond to "ASPX_Professional" <aspx_professional@p...>

To:   "ASPX_Professional" <aspx_professional@p...>
cc:

Subject:  [aspx_professional] Re: Composite Server Control containing a
      DataGrid & ViewState...Please Help


Hi,
I am not sure if this would actually solve your problem the way you want
to, but it is certainly one work-around.

What you can do is stuff your souce dataset into the Cache.
(e.g. Cache[key] = yourDataSetObject).
Then, you can check if Cache[key] == null (on the PostBack), if it is,
then you rebuild your dataset and re-Cache it.  If it is not null, you
can just cast it back out from the Cahch
(e.g. myDatasource = (DataSet)Cahce[key]).
The benefit of this is that the data remains on the server and not sent
to the client with the Viewstate.  The second benefit is that the cache
can be set to expire automatically, that way you are not locking up
server resources for a long time.

Hope that helps!
S. John N.
www.sbasp.com


> Greetings,
     I've got a composite server control (e.g. just class, no .ascx
counterpart) that I'm building. It instantiates a DataGrid control and
then binds it to a DataSet that was fetched by a business component. What
I
need to be able to do is avoid re-fetching and re-binding
of the DataGrid control.

For example, when you put a DG on your page just as is, you can do this:

if (!Page.IsPostBack)
{
   DoDataBind();
}

and magically, without you even having to form a complete thought, the
ViewState is reconstituted for the DataGrid and you don't have to worry
about it. I want to be able to do the same thing, e.g. in my
CreateChildControls() method I want:

if (!Page.IsPostBack)
{
    // use freshly retrieved DataSet from data source
}
else
{
    // allow DataGrid to rebuild itself from its own viewstate
}

I'm building the DataGrid programmatically and am using BoundColumn and
TemplateColumn. The TemplateColumn is for the checkboxes. When I uset
Developmentor's ViewState decoder, I see that the checkboxes are indeed
being stuffed into the ViewState, but the text displayed for the bound
columns is not being stored in the view state.

My only alternative at this point is to stuff the source DataSet into
ViewState ... and considering when I do this (with 4,000 sample rows), my
page weight is about 2.8MB, this is unacceptable, especially considering
the DataGrid is supposed to do this automatically.

So, any thoughts on what I need to do in my custom composite server
control
in order to get my DataGrid to rebuild itself from ViewState without
having
to stuff the DataSet into the ViewState and re-bind on postback?

Thanks,
Kevin