>>>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.