><< Session are fine if you really need them. But if you don't you're wasting
><< valuable resources on the server. Sessions also don't scale to multiple
><< machines, so there are other issues.

>How do you know if you actually need them?

If you don't use 'em you don't need 'em <s>...

><< In general I don't use sessions at all. Rather I use a single Cookie
><< which *I* manage rather than ASP and then store my session info
><< in a database. If you use ADO there's more overhead there, but if you
><< use a VFP COM object the overhead is actually less than a session.
><<
>I thought you needed Sessions turned on to see cookies? How is is that you manage it yourself?

Cookies and Sessions are two different things altogether. Cookies are part of the HTTP protocol and so don't require any software support except that the
browser must support them. Sessions are an ASP construct - basically a property bag that ASP persists for you. Hence the memory requirements. ASP must hang on to all the memory in use for any of the session variables as well as manage those sessions on every single hit. Finally, ASP sends a new Cookie for every hit which adds about 120 bytes to every request so there's overhead there as
well, not even counting the issue of the Cookie popup that occurs if 'show
cookies' is turned on in the browser.

>I do in fact use ADO but would consider using something else. Is there a way to create an object at the session start that can carry information throughout the session? Like if I created some object in VFP or VB that created the properties I wanted to carry as session vars, and updated to a table when I was done?

Nope you can't do that. In order to persists object refs across pages you
need the Session object - which of course you're trying to replace in the first place.

Bottom line is: If you really need to persist data from one page to the next
and it's more info than you can or should store in a Cookie - use a Session.
Otherwise use a Cookie and store the session data in a database. Most serious
Web apps need to persist user information anyway (for example a shoppers table
in a shopping cart app) for usage tracking and traffic statistics, so it's not
a big issue anyway.