views:

305

answers:

1

An old site on shared hosting has developed an error when executing a simple SQL statement

Microsoft JET Database Engine error '80004005'

System resource exceeded.

/411971/users1.asp, line 68

Line 68 is Set objCon = objCommand.Execute

The Access database isn't large (less than 2Mb), this is a single table query and the table only contains around 500 records. Field count is only about 20 too with no memo fields. Nothing has changed in the script. A compact/repair on the database has no effect, as does creating a new database and copying the table in question too it.

Looking round in the web this would appear to be most likely a web server issue rather than the code (and the behaviour would indicate this too) but I'm not finding anything conclusive - and knowing how shared hosting support works I'd like to have a definitive case before I go to them. Has anyone else seen this error/behaviour before and what was the problem/solution.

OUTCOME: I made sure I'd tried all the obvious approaches then emailed the ISP support who confirmed it was a server issue and restarted services, which fixed the problem

+1  A: 

It may simply be a connection limit. On shared hosting with other sites using the same backend the limits are easily hit. Whilst you can help by making sure you explicitly close any connections after your script has used them, in the end this would be a hosting issue your provider would need to look at.

This is probably not what you want to hear, but Access/Jet is an unsuitable database backend for a web application. I got hangs and inexplicable errors like this from it with just a couple of concurrent users. When MySQL and SQL Server Express are free there is no reason to use Access on the web.

bobince
Oh absolutely and amen to that. I didn't write this and in fact I'm working on a replacement system, but we need to fix the current issue in the meantime
Cruachan
Jet/ACE is not unacceptable for *all* web back ends, but it's mostly just small-scale read-only sites that it's appropriate for. Accessing it via ADO is better than ODBC or DAO because ADO is thread-safe (even with Jet/ACE), so that could get you a little bit more robustness.
David-W-Fenton