locked
urgent pleae databas calls or session variables ? plz advice RRS feed

  • Question

  • User852864959 posted

    Hi,

    Is it harful to use session  variables to keep a database  record ? In my snario I have 4/5 froms which fills an object. I need to open these forms in edit mode. It is generally said session variables should not be used for keeping data. I was thinking is it not bad to call database again and again ? I am not going to pull a table but just a recod (having about 50 columns data in it)

    What you advice ? using session or calling db again and again.


    thanks

    haansi

    <input id="gwProxy" type="hidden"><!--Session data--><input onclick="jsCall();" id="jsProxy" type="hidden">

    Monday, February 8, 2010 5:51 AM

Answers

  • User541108374 posted

    Hi,

    to measure is to know.

    How many concurrent users will you be having? How big's the data? You stated something like 50 columns but 50 columns of ntext or varchar(15) makes a difference.

    Do you need to keep everything in Session of that record? I guess that you're going for some wizard like approach so you could keep the primary id of the record in session and retrieve the data dedicated to one page of the wizard from the database and not perform a select * from tableX.

    Grz, Kris. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, February 8, 2010 7:41 AM
  • User-952121411 posted

    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:

    http://wiki.asp.net/page.aspx/57/session/

    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:

    http://msdn.microsoft.com/en-us/library/ms178581.aspx

    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.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, February 8, 2010 9:08 AM

All replies

  • User541108374 posted

    Hi,

    to measure is to know.

    How many concurrent users will you be having? How big's the data? You stated something like 50 columns but 50 columns of ntext or varchar(15) makes a difference.

    Do you need to keep everything in Session of that record? I guess that you're going for some wizard like approach so you could keep the primary id of the record in session and retrieve the data dedicated to one page of the wizard from the database and not perform a select * from tableX.

    Grz, Kris. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, February 8, 2010 7:41 AM
  • User-952121411 posted

    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:

    http://wiki.asp.net/page.aspx/57/session/

    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:

    http://msdn.microsoft.com/en-us/library/ms178581.aspx

    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.

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, February 8, 2010 9:08 AM