Feb 08, 2010 09:08 AM|atconway|LINK
Is it harful to use session variables to keep a database record ?
Generically speaking, not at all. Session state is secure and the variables are stored in memory on the server. So that answers the 'harmful' or reference maybe to security. The vulnerability with session variables is if the ASP.NET worker recycles or
the server is rebooted, the variables are lost. However there are options for storing your session variables in an alternate mode like 'StateServer' or 'SQLServer' which will persist the afore mentioned issues, but they each have there prerequisites
as well. To read up more on this, take a look at the following:
ASP.NET Session state:
If you want to read up on Session in general to help you getting a better understanding of its inner workings, than read through this which will help you make informed decisions on using Session State:
ASP.NET Session State Overview:
As far as calling SQLServer over and over; I would initially opt for using a Session variable to hold the object that was built up from the single call to the database. As mentioned in the last post, this suggestion could change if you have
a site with 1000 concurrent users, but many times this is not the case. ASP.NET does have connection pooling built in to help with repeat database calls which is good news if you do end up deciding to make the repeated database calls, but just based on what
you mentioned, I would probably use a Session variable to hold that data.