>
>You've already gotten some feedback about saving into the user's session (which works). Your ASP.NET pages are created and destroyed on a per-hit basis (stateless) so you have to think about restoring it's state via some other means. Session is one way, Viewstate is another, and finally just reloading the data from the database on an as-needed basis.
>
>If you're storing the information in the Session, one thing to keep in mind is the number of records you are storing vs the number of users of the site. For most business apps., this isn't really a big deal since the number of users is usually fairly low (assuming you're not pulling down a huge table into memory). But if you've got a large number of users, serializing a large DataSet and storing into the session may not always be the best idea. Sometimes it's just better to reload the data from the database on each hit. There isn't really a hard and fast rule, since each of these have issues (for example, accessing the database is usually the slowest thing happening on a given page, so it might not scale particularly well).

Paul,

I appreciate your input. I actually asked the question knowing that a session is one way to persist the dataset without reloading. And I was considering this method vs. reloading. But I wanted to be sure that I was not missing a method that has the advantages over reloading and/or session. And in the end I decided to go with Reloading of data. The table should not be very big (my guess between 1 and 30 records). And I determined that the business logic is such that user will not have to reload on each hit; but only if they change another pull-down on the page (which should not be frequently done).

Thank you for you help.