Trouble with using Session state

[Greg Linwood]

I'm having difficulty understanding Session state in ASP.Net. It's almost
embarrassing asking this as I've been using ASP since it was first released
& it really shouldn't be this hard to use - perhaps I'm just not very smart
or perhaps MS is making this too hard for us sql bunnies to understand - I
dunno, but I'd really appreciate someone explaining what I'm doing wrong
here & perhaps suggest a better approach..

I'm familiar with use of the old Session("variable") = value syntax. (also
very aware of scalability issues - so don't flame me on this - I'm just
trying to understand how the whole thing fits together here). I expected
things to work similarly with ASP.Net but I just can't get it to work easily
for me..

I'm trying to carry around a Session("login_id") type variable & would like
to access it via code-behind (.aspx.vb) modules as well as class (.vb)
modules. I can successfully set a variable in a Page_Load event from one
form (during postback) but after re-directing to another form, I get a nasty
error when trying to access the value:

Object reference not set to an instance of an object
Line 29: Dim LoginID As String
Line 30: LoginID = Session("LoginID").ToString

Source File: ... home.aspx.vb Line: 30

I've tried using HttpContext.Current.Session("LoginID").ToString but this
just gets the same problem.

Why do I get an Object reference not set error? Surely Session doesn't need
to be instanced does it?

I'd appreciate any help.

Regards,
Greg Linwood
SQL Server MVP

 

[Alvin Bruney]

when you transfer to another page, it isn't gauranteed to occur on the same
calling thread so all your state information, including session is discarded
and a new session built up to service the transfer call. If you want to
return state, there is an overloaded function parameter which enables you to
do so. Server.Transfer(page, bPreserveForm) set this to true and you will be
alright. the default is false. Same deal for redirect.

regards

 

[Greg Linwood]

Thanks Alvin - but that didn't work.

I changed my Response.Redirect to a Server.Transfer(page, True) and I still
get the same error...

I noticed that the bPreserveForm argument seems only to apply to QueryString
& Form state. I want to preserve variable values in Session state, similarly
to the manner in which ASP Session worked. Is this possible in ASP.Net?
Perhaps there's simply some setting I'm not getting right or something..

Regards,
Greg Linwood
SQL Server MVP

 

[Alvin Bruney]

Try server.transfer(page.aspx, true).
Are you transferring to a page hosted in the application directory? That
should work otherwise the problem lies elsewhere.

regards

 

[Greg Linwood]

hmm - that's what I did..

Perhaps I'm stuffing something up in my config or somewhere else in my
code.. I'll keep on debugging & try to identify whatever.. :c/

Regards,
Greg Linwood
SQL Server MVP

 

[Greg Linwood]

I think I may have an explanation:

I think that my code: Session("LoginID").ToString breaks if "LoginID" is not
in the HttpContext.Current.Session.Keys collection because there is no
object to call .ToString against.

Does this sound like a fair explanation? If so, how does one code
defensively around this issue without writing copious amounts of spag code
to handle session variables instances not being present?

Regards,
Greg Linwood
SQL Server MVP

 

[William LaMartin]

I too have been having problems with Session Variables at some servers--they
do not persist after, say, 20 seconds. But your problem is different.

And your code produces no problem when tested on my computer--the session
variable displays fine after a server.transfer or response.redirect.

What do you have in your web.config file as regards session state. Here is
what I have (watch word wrap).

<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="false"
timeout="60"
/>

What is this "nasty error" you are receiving?

 

[Alvin Bruney]

It will break with a null reference exception if login_id isn't there like
you said. Before touching session variables you should always test:
if(Session("login_id") != null) blah blah blah. But that doesn't explain why
it isn't there after the transfer in the first place. I've written a small
demo with a transfer and redirect. No matter how you transfer, session
variables will still be around unless you explicitly clear them. Are you
clearing it somewhere after the transfer? Otherwise, you will need to
examine your IIS settings adjusting the recycle properties as needed.

One more thing you can try is to put code in you session end event to
populate a static variable. Then try to read this variable on the page you
transferred to. Session end should never be called under these
circumstances, otherwise it is the reason for your lost session variables.

Regards

 

[Greg Linwood]

Thanks Alvin.

I wasn't aware that you needed to do if(Session("login_id") != null) blah
blah blah, which I guess is a new thing you have to do in a strongly typed
environment. It makes sense, because I was testing
Session("login_id").Length which would give an object instance error if the
session variable wasn't there in the first place. Previously, in ASP, you
could check Len(Session("login_id")) which would be fine as any Variant had
a length. It's just a fundamental thinig I was missing. Because I didn't
realise this, I was not being overly careful how I populated the Session
variable in the first place, which was ultimately the source of the
problem - I had an XPATH query which was wrong & caused the
Session("loginid") variable to not be populated first..

Thanks for your help though!

Regards,
Greg Linwood
SQL Server MVP

 

[Greg Linwood]

Hi William

I worked this out eventually - it was a Session variable population problem
& a fundamental mis-understanding about a strongly typed issue (which wasn't
a problem in ASP). My other post goes into a little further detail.

Thanks for your response though - my web.config is configured the same as
yours, but this isn't the problem after all.

Regards,
Greg Linwood
SQL Server MVP