Tracking User Sessions

Results 1 to 3 of 3

Thread: Tracking User Sessions

  1. #1
    Join Date
    Dec 1969

    Default Tracking User Sessions

    I hope this isn&#039;t too dumb of a question so it goes. <BR><BR>I&#039;m tracking user&#039;s sessions using code similar to this in my global.asa:<BR><BR>In Session_OnStart:<BR><BR>conntemp.Open Session("aspdb_ConnectionString")<BR>sqlString = "INSERT INTO UserTable (session_id) " & _<BR>" VALUES (" & Session.SessionID & ")"<BR>logRS.Open sqlString, conntemp<BR>Set logRS = Nothing<BR>Set conntemp = Nothing<BR><BR>In Session_OnEnd:<BR><BR>&#039;Remove user from UserTable<BR>set conntemp=server.createobject("adodb.connection")<B R>set logRS = Server.CreateObject("ADODB.RecordSet")<BR>conntemp .Open Session("aspdb_ConnectionString")<BR>sqlString = "DELETE FROM UserTable WHERE session_id = " & Session.SessionID<BR>logRS.Open sqlString, conntemp <BR>Set logRS = Nothing<BR>Set conntemp = Nothing<BR><BR>However, I also have &#060;%=Session.Abandon%&#062; statements placed here and there in my application. If the user hits one of these pages, is their original Session.SessionID value lost that was assigned to their session in my global.asa? If so, I guess another unique Session.SessionID is created when they visit another page in the app? If these are both true, then my code in my Session_OnEnd section won&#039;t be able to find the Session.SessionID originally inserted into the dbase.

  2. #2
    Join Date
    Dec 1969

    Default RE: Tracking User Sessions

    Upto my knowledge It is a bad practise to keep Objects in Session. Please check it once.<BR><BR>Thanks<BR>-Venky

  3. #3
    Join Date
    Dec 1969

    Default Instead of Session.Abandon think about

    using Response.Redirect "Leave.asp" where Leave.asp contains all the code you want to run upon where you now have Session.abandon.<BR><BR>DON&#039;T depend upon Session_OnEnd. It&#039;s flakey and doesn&#039;t always get run.<BR><BR>Venky is right about keeping objects in Sessions, however, you are keeping strings, not objects. If the base string, however, doesnt change from session to session, you might want to keep the strings in Application variables. Slightly less overhead in that there will be few instantiations (only 1).<BR><BR>HTH

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts