>for every user, so it's real easy to get really large session stores and lots of objects in memory (In Proc) or tons of network traffic marshalling (SessionServer or SQL Sessions).

So tell me Rick, how is storing your Session objects in SQL Server any different, network-traffic-wise, then re-running your queries? Seems like six of one, half dozen of the other, if you ask me. <g> In which case, I think storing your DataSets (or objects) in Session objects is cleaner. Just my 2 cents. =)

~~Bonnie



>>How is this typically handled on the web in general? Control State? View State? Session Ojbects?
>
>Typiucally you SHOULD actually re-run those queries. You can minimize the amount of postbacks. Storing data like this in Session state is not really a scalable solution.
>
>While Session can be used for objects, it's generally not good advice to utilize it extensively for state management. You don't want to persist business objects or data sets in most situations because that's just not scalable in anything but the smallest volume of simultaneous clients. Sessions stick around anything you park there persists there for ever user, so it's real easy to get really large session stores and lots of objects in memory (In Proc) or tons of network traffic marshalling (SessionServer or SQL Sessions).
>
>Sessions are useful but they should be used as a minimal store for data. If there's complex data - dumping to a database is usually a better idea and then restoring.
>
>
>
>ATLAS is another option in that you can update parts of a page without refreshing all of it. This makes it possible to leave the bulk of the data alone and only update portions of the page that are actually affected.
>
>+++ Rick ---