views:

56

answers:

2

I have been coding an app in classic ASP that accesses 2 Access databases. I had a page I was working on throw an exception, which is normal during development and causes no lasting problems. This time however, after the exception any attempt to open either of the databases would freeze the session with an infinite script timeout. If I delete the session cookie I an able to access ASP pages again until I try to open the database again.

The database that was open when the exception was thrown is left open. There is a LDB lock file and I can't rename or delete either the LDB or MDB file, though I can download the MDB file with FTP. The 2nd access database is not open but any attempt to read this also hangs the session.

Accessing HTML pages is fine.

The site is hosted with Hostway and they are not interested ("Coding problem = Your problem" even though it leaves my site dead in the water, I suspect until the next reboot, whenever that might be).

Here is the dump from the relevant ASP page that threw the exception:

Active Server Pages error 'ASP 0115'
Unexpected error

/translatestats.asp

A trappable error (C0000005) occurred in an external object. The script cannot continue running.
Active Server Pages error 'ASP 0240'
Script Engine Exception

/translatestats.asp

A ScriptEngine threw exception 'C0000005' in 'IActiveScript::Close()' from 'CActiveScriptEngine::FinalRelease()'.

Is there any way I can unstick the site / force close the database remotely ?

A: 

The process hosting your site has entered into an unknown state. The exception C0000005 is an access violation.

The only way to recover this situation is to end the process which in IIS speak means to recycle the application pool that your app runs in.

AnthonyWJones
which I can't do from half-way around the world, right...?
@user89691: I don't know, I could it to one of my servers "from half-way around the world" so geography isn't the issue. Whats at issue is the level of control your hoster is willing to give you. Whats more worrying is that either you have managed to find a strange bug in some very well established components or your host server has some problems with the installation of these components. If they remain unsypathetic you might need to take your business elsewhere.
AnthonyWJones
I've googled the dump contents and it seems like I'm somehow killing the scripting engine, probably through an unhandled exception.My next thrust will be to try to run the code locally under IIS.
@user89691: Quite so. You should really test all your code on a local IIS first. Leave your live site as production.
AnthonyWJones
Getting IIS running locally is proving to be a nightmare also. Can I upgrade IIS5 to 6 (to align myself with what is running on the hostway server) on WinXPSP3?
It appears you can't update IIS5 to IIS6 under WinXP
@user89691: For classic ASP work the differences between IIS 5.1 and IIS 6 are minor. I've never found something that failed on IIS6 that worked on IIS 5.1. And yes the version IIS is tied to the operating system version. Can be a bit more specifc about the "nightmare", its usually quite straight forward.
AnthonyWJones
A: 

IIS6 at least restart app pools every 26 hours.
(http://serverfault.com/questions/108898/restart-iis-app-pool-automatically)

try this for some restart script
http://forums.iis.net/t/955382.aspx

RandyMorris
Sure enough, the site has kicked back into life 2x hours after I killed it for the second time. Now what I would like is a fragment of classic ASP I could call up to kick it in the head next time... 27 hours between edits is too long. BTW the script link above ( http://www.tonybunce.com/RecycleAppPool.zip) is a dead link.
I was going to help you find some script to help you with that, but really the best direction is to FIX THE BUG lol, please try some of these out (http://www.forumtopics.com/busobj/viewtopic.php?t=15541) or provide more information so we can help you fix the bug :D
RandyMorris
Thanks Randy. The problem will all the resolutions like "check for a dud dll" is that I don't have access to the (hostway) server other than by emails to an unhelpful support team who are not interested if there is even a sniff of 3rd party code involved. You bet I intend to find the bug, but at present every time it happens I have to go away for a day and do something else.
Update. I finally got things working on localhost and was able to run the troubled code locally. I had an error "Error 16389 ([Microsoft][ODBC Microsoft Access Driver] Query is too complex.)" from a malformed SQL string (I had "SELECT COUNT (*) AS TotalRecords" as the query - note missing table name). This might be what upset IIS on the web server (it's IIS6, I'm running IIS 5)
@user89691: I don't think you will find that the problem is simply the difference in IIS6 to IIS 5. Its a fairly simple error and the server process should not lock up like it did just because of this.
AnthonyWJones
@user8969 Good man, finding the real problem is much better than some kind of work around. So after you fixed your queries, how is it running or is there a new error code or same one?
RandyMorris
The code ran as expected once I had fixed the query syntax - both local IIS 5 and Hostway IIS 6. I'm still not quite sure what the exact source code that caused the lockup was - I need to go back through incremental backups, recover it, and see what happens locally.