>>>>Reload and rebind the data from database is the better way.
>>>>
>>>>But the database and application design not allow me to do that. I have to store the dataset as temporary data and only store all of them into the database when user clicks submit button.
>>>
>>>I'd recommend you dump that data into a temporary table and delete the data when it get added to your primary table. You can timestamp the temporary data and delete it occasionally when you deem it timed out.
>>>
>>>DataSets in Session are just a bad call if you have even reasonable volume of traffic on your site.
>>
>>Rick,
>>PMFJI, but would this still be the best method to take if your page does a postback? What are your feelings with a custom business object instead of a dataset... do you feel those are any better to store in a session?
>
>No. Session State should be for storing simple state or references to data, not the data itself.
>
>Let me illustrate why this matters. On my site at any given point in time I have something like 30,000 state server sessions going! Granted most of those sessions are empty or have one value in it, but any user that uses state - which includes search engines which will not properly track sessions because they don't use Cookies - will generate sessions. If you have 10 people who are using session state and you're storing say a 100k worth of data in session you're using 1 meg of memory (actually much more with datasets because of the object overhead). Now do this with a 100 or a thousand and you can see how you can very, very quickly overrun your memory capacity. That memory drags on the machine.
>
>You also have to remember that there's overhead involved in serializing and deserializing data like a data set and while this is generally less resource intensive than data access it's not free.
>
>Stateful coding in the Web environment is just not a good call - it will lead to all sorts of complications in all but the lowest volume scenarios and I wouldn't recommend going down this road. It's almost always better to re-retrieve data from the database unless there's a very good reason (ie. extreme complexity or time requirements) to not do so.

Rick,
Pardon my newbie questions about this. I have kept this in mind while working on my primary web application, and was wondering what you meant by "references to data" as you mentioned above.

For example, say a user logs into my system. What is happening now is that a Security dataset is stored in session state, and when they go to different pages content changes based on values in that Security dataset.

Should I instead be storing the unique UserID in session state, and then reloading the Security table everytime a new page is loaded?

Thanks!