ASP Pro Code ClinicAs of Oct 5, 2005, this forum is now locked. No posts have been deleted. Please use "Classic ASP Professional" at: http://p2p.wrox.com/forum.asp?FORUM_ID=56 for discussions similar to the old ASP Pro Code Clinic or one of the other many remaining ASP and ASP.NET forums here.
Welcome to the p2p.wrox.com Forums.
You are currently viewing the ASP Pro Code Clinic section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
This is a limitation of the HTTP protocol. HTTP is a connectionless, client initiated protocol. Unless some custom code is written to maintain connection, the only time a server knows when a client is on the other end of the line is when a page is requested or a POST is made.
A session will end when either it is abandoned or it times out.
Do you mean that the Session_OnEnd subroutine is not firing at all, ever, or that it is not firing when the browser is closed? If it is not firing when the browser is closed then I am afraid that David is right and there is nothing you can do about that.
If on the other hand you mean that it is not firing ever, then there are many reasons for this. Unlike the other sections of ASP code, there are several functions and objects that you can't use in Session_OnEnd.
For example you can not use the Response object or the Server.MapPath function. If you post the code for the Session_OnEnd routine along with the code for any other functions that you use in that routine then I will take the time to look through them and offer some suggestions.
Well, there is one little thing you can do about it.
Most browsers support the unload event, enabling you to request a page at the server that End the session explicitly.
However, it has some problems. First of all, it won't always fire correctly. Secondly, it may cause irritation with your users. Imagine a user has a modem dial up connection. They look at your page, then disconnect, and then close the browser (not uncommon for large pages that people want to read off-line). As soon as they close the browser, a new page will be requested and they are asked to dial-in again. Not very user-friendly (we had this situation on an Intranet we build for a client. It caused so many frustrated calls to the Call center that we decided to take the feature out).
The bottom line is: don't count on Session_OnEnd to always fire.
What exactly do you want to update in Session_OnEnd? There may be other ways to do what you need to do.....
Everyone is unique, except for me.
LOOK DUDE, YOU CAN'T USE SERVER(DOSOMETHING), YOU CAN'T USE RESPONSE(ANYTHING), YOU CANT USE REQUEST(ANYTHING). OK, THERE ARE ONLY 2 THINGS YOU CAN USE IN A SESSION END EVENT. I'M TIRED OF EVERYONE SAYING "YOU CAN'T RELY ON IT TO FIRE", THAT'S BULLSH*T, IT FIRES EVERY TIME YOU GUYS JUST ARENT USING IT RIGHT. I'VE ONLY BEEN DOING THIS STUFF FOR 2 WEEKS, AND I GOT IT TO WORK, I DON'T KNOW WHY THE "FORUM PROS" ARE TELLING YOU GUYS THIS JUNK. IF YOU WANT YOUR STUFF TO WORK, READ MY TUTORIAL. HTTP://WWW.FORUMS.GRIMMUSIC.COM GO TO THE TECHNICAL FORUM, IT'S THE FIRST TOPIC YOU SEE.
Sure, it fires most of the times as expected, and indeed you can't use the stuff you mentioned (which makes sense because there is no Request, and therefore no Response when the event fires).
However, there is no guarantee that it fires. If you pull the power plug of your machine, the Session_OnEnds will not fire for any remaining / open session. There is no queue or whatever of open sessions maintained on disk. This means that you cannot use Session_OnEnd for things that *must, guaranteed 100%* run for a client, like close an order / shopping cart whatever.
When you're using ASP.NET with SQL Server State storage the event doesn't even fire at all.
So, yes the event fires often; yes, most of the times it will run as expected. However, you can't fully rely on it. That's what many people have been saying on these forums for quite some time.
THAT'S NOT ME SHOUTING, WHEN I WRITE SCRIPT, I USE CAPS, TO ASTHETICLY SEPERATE MY VARIABLES, FROM SCRIPT. WHEN I "SHOUT", AS YOU PUT IT, I USE BOLD. THANKS, AND P.S I DON'T USE SQL SEVER STATE STORAGE, SO I DIDN'T KNOW THAT, SO IT IS GOOD THAT YOU INCLUDED THAT IN YOUR POST, SO PEOPLE ARENT MISLEAD. THANKS AGAIN.
I JUST REALIZED I ONLY POSTED HALF OF ONE OF MY RESPONSES," WHEN I WRITE SCRIPT, I USE CAPS, TO ASTHETICLY SEPERATE MY VARIABLES, FROM SCRIPT" , ANYWAY, I DON'T SEPEATE MY TIME OF READING THINGS ON THE NET, FROM MY TIME IN WORKING ON MY SITES, SO IT'S TOO MUCH OF A BOTHER TO SWITCH BACK AND FORTH JUST TO PLEASE OTHERS, IF SOMEONE DOESN'T LIKE MY SPELLING TYPE, THEY ARE FREE TO IGNORE ME, AND MY POSTS, IT JUST MAKES IT EASIER TO SEE WHAT I WROTE, AND WHAT I DIDN'T WRITE, AT A GLANCE. THANKS AGAIN.