The Question and Answer Board

[Bob Zumbrunnen]

i'm leading to think the issue may be what you mentioned yesterday with session variables. has clearing that out helped any?

I started destroying the biggest/nastiest in code yesterday or the day before, yet it crashed yesterday.

I don't know if any attention is paid to global.asa once IIS has fired up, so if not, the change I made to global.asa to destroy all of a session's variables on a session ending won't have taken effect until the reboot yesterday's crash made necessary.

I just got in, so don't know if the server crashed last night.

The new programmer's first task is to close/destroy all recordsets in code immediately after the code is done with them. Starting with the most frequently-used routines and working her way down.

Matt has done a lot of this already, but he's of the "knows enough to be dangerous" variety of programmer, so he's not always clear where it's safe or appropriate to close a recordset. The new programmer shouldn't have any trouble with that.

Question: Would memory leaks (and, as Luke and I were discussing yesterday, closing a db connection might still leave the recordset's memory space occupied but the recordset inaccessible) of a kind drastic enough to crash ASP manifest themselves as a consumption of memory until none is left?

The reason I ask is that of the 2 gig of physical memory in the webserver, 1.6 gig is shown as available at any time. Even right before and after a crash.

Oh, and I just checked. The server made it through the night without a reboot.

Edit: I also just now configured World Wide Web Publishing Service to restart itself on failure. I don't know for sure that the OS will be aware of its failure, but we'll see.