Replies to post #35032 on The Question and Answer Board (IHUB)

[IH Geek [Dave]]

The OS event logs don't show that anything occurred. It turns out that ASP does not write events to it.

[Bob Zumbrunnen]

It hasn't been logging anything.

However, I did configure ASP last night to log all errors to the event log. Keeping my fingers crossed that whatever is happening to cause it to shut down will get logged.

This has already proven to be handy in another way, too. It (repeatedly) logged an error that was happening in 3 different ASP's, so I was able to go in and fix them even though they hadn't been reported.

Also reported an error in global.asa, which is a file I'd never looked at, but am glad I did. Not only was it trying to store a user's account number as an integer (not good when account numbers are now too high to be integers -- 32765 is the int limit, if memory serves), I went ahead and added a session.contents.removeall() to the Session_OnEnd sub.

I wish there were a Recordsets.Closeall(). I spent about half a day last week seeing if there were such an animal. Nope.

Getting back to the 3 ASP errors that were logged, I might've learned something from them.

Each one was a complaint that a recordset.close was being attempted on a recordset that didn't exist. Hmmmm... In each of those ASP's, the recordsets weren't being explicitly closed anywhere prior to the line that was erroring out, however, something they all had in common was that the recordset.close was being attempted *after* the subroutine that does all the end-of-page processing.

One of the things in the end-of-page routine is to close and destroy the database connection.

In the forum where Matt and I were describing our problem and being told that explicitly closing recordsets would cure it, I asked if destroying the db connection would also destroy the recordsets. No answer.

I think that perhaps it does, though. And that bothers the hell out of me.

If destroying the db connection destroys all recordsets associated with it, then the last few crashes can't be blamed on recordsets being open because it was late last week when I put in the db connection destroying code.

On a side note, in other languages I've dealt with (I'm thinking maybe it was the old DAO flavor of Access), Recordsets was a collection and it was possible to step through its members to see what recordsets were open. I think I ran across a few different places last week that specifically said that you can't do this in ADO. Too bad. If such a thing (still) existed, then I could easily do something like:

 
 For each item in Recordsets 
   item(name).close 
 next 
 

Anyway, if I find that destroying db connections really does destroy all the recordsets, that'll probably prove that too many open/unused recordsets isn't the problem. If that's the case, and the problem has stopped as of last night since the last IIS restart, I'm going to be very inclined to blame the session variables.