Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Intermittent Error The connection cannot be used to perform this opera

Status
Not open for further replies.

PaulHInstincticve

Programmer
May 31, 2006
45
GB
I am receiving the following error intermittently from my application

The connection cannot be used to perform this operation. It is either closed or invalid in this context

I cannot replicate this. I have an error handler running (to email me details of any errors that occur in a user friendly screen). This handler emails me details of this error occuring once every few days across 15 or so customers (eg with hundreds of members running the application). Unfortunately the application cannot pinpoint line numbers unless the error handler is turned off at which point it is unlikely I would hear of the error or be able to replicate it!

The only pattern that seems to have been showing up so far is that it has been happening more in one of the more resource intensive sections of the application that outputs a lot of information.

I am therefore suspecting that the error is due to a lack of resources on a shared web server which is why it is intermittent and happens in the busiest part of the application mainly (but not always). It also happens more for some of my bigger customers who will therefore have more members who will be using the application (this is an on-line event booking application for social clubs with 1000 to 3000 members each!).

I have scoured the internet for this message and only seem to come up with causes that can be replicated. I did however find one suggestion that says you always need to use SET before the activeconnection command, I have therefore just changed some code from

Set defaultsrs = Server.CreateObject( "ADODB.Recordset" )
defaultsrs.ActiveConnection = Con

to

Set defaultsrs = Server.CreateObject( "ADODB.Recordset" )
set defaultsrs.ActiveConnection = Con

I await to see if that makes any difference. Has anybody else had this? Thanks

Paul
 
Unfortunately the application cannot pinpoint line numbers unless the error handler is turned off at which point it is unlikely I would hear of the error or be able to replicate it!

In situations like this, I have that creating a custom 500 error page helps immeasurably. Just change the server's default 500 error page so its appearance matches your "friendly error" page. Then you will be able to get detailed information like the line number and error source. It can even tell you if the error occurred in the requested ASP or one of your include files.
 
Thanks Sheco. I was, however, directed to using

on error resume next

for my error handler and then to check the error number at key points and activate my error page followed by a response.end when a find a value other than 0. That is all very well in ASP because it stops the system crashing badly and allows me to present a nice tidy screen and then to email myself with details. Unfortunately, however, apart from the script name and error I do not receive the line number in the error object (I believe ASP.NET is better at this but not got into that yet). There was little mention of error 500 pages when I did my research before writing my handler. Is it able to pinpoint line numbers and if so how? What are the pros and cons to both approaches?

Paul
 
That page you get when you don't use [tt]ON ERROR RESUME NEXT[/tt] is the standard 500 error page.

You can customize the page to present a nice tidy screen and then to email you with details except you have access to all of the details of the ASP/IIS error objects and not just the VBScript Err object...

Bottom line is you can can get the line number and other good stuff and the user sees the same "nice tidy screen.
 
Don't suppose there is a chance of some sample code that access the objects that can get me started. It was really frustrating last time I looked into this that noone could supply sample code referencing a line number, only a script, I was told it was a limitation of ASP which having had such features available for my Visual FoxPro desktop applications for 15 years or more really surprised me! Thanks

Paul
 
Talk about using a sledghammer to crack a nut!. How can a company like Microsoft produce such good software and then design something as complicated as messy to use as IIS and ASP - oh, I remember, they buy up the companies that produce the easy to use stuff then brand it as their own! Might see what I can make of this lot but as my system is sold more as a 'packaged' system, I don't want to mess around too much with customer's IIS, particularly as most are running on shared servers with their ISPs. Neither do I want to support them in such an area, I would rather just include a script that sorts everything. What I have at present works reasonably good for me now, ie I get an alert that a script has crashed and have a good indication of how that script was called and the user alert is clean and I can then just comment out the 'on error resume' command and run the script myself to get more detailed crash info with line number to start debugging. Will have a play with it but if there are any Microsoft guys listening out there - come on, error handling doesn't need to be rocket science, make life easier for us will you!!! Thanks again

Paul
 
I believe it is worth the time required to make a nice 500 page, at least for your internal development and testing servers. You can get more and better information than from the standard 500 error. Also I prefer to add at the bottom everything from the HTTP Request like so:[tt]
Dim foo
For Each foo in Request.ServerVariables
Response.Write foo & " = " & Request.ServerVariables(foo) & "<br>" & vbCrLf
Next[/tt]

You can do the same thing for the Request.Form collection and also you might as well print out (or email) any important Application or Session variables.


That said, I would want to print this onto your live site. You might want it to generate an email but it could be a mistake to display to users.

Also, and I'm just guessing here, you might be able to figure out a way to "install" the custom 500 page for your customers without them having access to their own IIS Admin tools... perhaps this could be done by editing the IIS metabase.
 
Sheco,

Thanks that's good advice. I do similar loops and dumps of databases, variables, objects etc in my desktop app. Something similar needs to be done with the on-line app if only it weren't so much more complicated! Will implement those ideas. Thanks

Paul
 
I had a typo that changed the meaning... I meant that I wouldn't want to display debug data to users on a live site.
 
Yes knew what you meant first time and agree entirely! Exactly how I work on the desktop app!

Paul
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top