It's primarily a scalability thing. Always remember that the Session object and the variables and objects it contain are stored on the web server. This means that for every user, you could have one of those objects instantianted. Multiply the resources used by that object by the number of users and the resource usage on the server can skyrocket. Add more objects and it gets even worse. We rarely store anything to the session object for that reason. Sure it's convenient, but if a site starts to get heavy traffic, it can cause you serious grief.

>I think it's because that if you make an object in a session object, then you have to remember to clean out that object or your stuck waiting for the timeout of the session. If you just use local variables in your ASP code, then the object SHOULD be cleaned out when the page load is done, or when it hits an "SET object = NOTHING" line.
>
>If someone hit your site and an object was created in a session, then they leave without going through the proper exit routine to clean out the object, that object is in there for the timeout period (default 20 mins).
>
>That may not be a bad thing for a small or even medium site. However, programming "DO's and DON'T" tend to be universal. "If you wouldn't do it on a BIG site, don't do it in a SMALL site..."
>
>That's what I've heard in the past of this subject. There could be more reasons.
>
>-Joe