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
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.
If the issue happens again, just ask your hosting provider to recycle the application pool on IIS.
Related
My company uses a shared MS Access database, with a back end stored on a server and a front end copied onto users desktops.
Recently, our IT department moved us to a new server without giving us any notice, and now our database keeps crashing.
Every 20-40 minutes, users get an error message that says:
Error 3043 Your network access was interrupted. To continue, close the database, and then open it again.
If they close and reopen, it does work. However, I'd like to stop this from happening, since it typically happens when they are in the middle of something and have to re-do everything.
I've already spoken with our IT consultants and they see no issue with our server/network, nor do they know anything about Access and therefore are no help.
Does anyone have any experience with this or have any ideas that may help me repair my database?
Thanks in advance.
Here are some thoughts:
It sounds very much like (short) network interruptions. MS Access doesn't like these at all, in particular it doesn't recover from a broken connection (even if very short) until you restart the frontend.
Network interruptions during write operations on Access backends are the prime cause of backend database corruption. Consider yourself lucky if you haven't experienced that yet. But you should backup and Compact&Repair the backend often (!) .
You can prevent backend corruptions by moving the backend to a server database, e.g. SQL Server Express (free). Errors will still occur ("ODBC call failed" instead of error 3043), but they will only affect the frontends.
You can probably work around all errors by changing the frontend from bound forms to unbound forms. This is a major undertaking.
I don't think there is anything you can do with the backend to prevent the errors.
If this database has value to your company, and IT says there is no problem, I suggest you escalate the problem to someone who can make IT look closer into the issue.
(How to do so would be a separate question, perhaps on SuperUser.)
I am working on a set of Classic ASP (VBScript) websites under different domains with 64bit Access (2013) database connection. Server is a shared Windows Server 2012 with IIS 8.5. The sites were not coded by me.
Everything seems to work fine for a time, but after several page calls (sometimes also at the first or only call to the site) the server does not respond for more than 20 to 30 seconds. This means: I can't call ANY page hosted on this server, even all other websites under different domains stop working for that time.
I am not sure, if plain HTML pages will respond, but it seems not. After such an issue everything is running fine again for various periods (up to 1 or 2 minutes), pages show up with normal response time, then this system hang repeats. And so on…
Finding the problem is extremely difficult, because all the sites on this shared hosting server could possibly cause this behaviour, it not necessarily seems to be triggered by my specific page call or subsequent calls, though it could be.
I am not sure, where to even look for the problem. I searched this forum and noticed some interesting answers, but not exactly to our problem. I tried Sysinternal's Process Monitor on a virtual server, where only one specific site is hosted and the same issues exists, but was not able to interpret most of the messages. I looked into event viewer log at this machine and noticed entries saying:
A trappable error (C0000005) occurred in an external object. The script cannot continue running.
But even if that sounds to be a possible reason, I am not sure where to look in the script or a log file, where I could find the trigger of all that. And on the shared host I don't even have the possibility to do that. On our local 'internal webserver' under Windows 10, where local copies of all the sites reside, I can. But I'm not sure, where to start my search.
Any help would be appreciated (and please don't needle me with proposals for switching to ASP.net or SQL - this is not possible at the moment).
I work with huge classic ASP application this error normally happens in a call for a Server.CreateObject('foo'). We have this kind of error here normally at the excel object when someone try to upload a very large .xls file. I would start mapping all the Server.CreateObject.
Background: I have just completed a move of approximately 50 classic ASP sites from an IIS6/Sever 2003 and SQL Server 2000 environment to a new virtual environment of 2 machines behind an nginx load balancer. Each MS machine is running IIS7.5 and SQL Server 2008 R2. They current each have 6Gb & 2 VCPUs. The databases are set up in a mirroring configuration (currently without a witness).
During testing all sites appeared to function correctly.
Once live traffic started to hit the sites it became apparent quite quickly that the initial resource allocation (2Gb & 1 VCPU was way too low and was quickly increased). The main problem has come from an intermittent ASP error occuring on approximately 10 (and probably including the busiest) sites on the servers. They will produce a 500 response from an ASP error of
Provider error '8002000a' Out of present range.
All research has pointed to causes such as numbers too large to fit into an integer variable and some people have mentioned some correlation with the newer implementation of RAND and NEWINT() in SQL Server 2008 compared to 2000. The stored procedures that appear to cause the error are relatively simple, with some as simple as accepting a single VARCHAR parameter (well within the limits) and doing a single column select on a table. Most do not even involve INTs at all and if they do, the values are well within range.
The error can appear on one machine for a given amount of time while during this same time the other server will not necessarily have the error, it sometimes will though. After a while the error will stop occurring, this doesn't seem to correlate with excessively overloaded system resources either.
ASP to database is done via a DSN using SQL Server Client 10 drivers. The code is using the ADODB connection and command objects. This code has been working happily for 6+ years on the previous servers. The databases are set to compatibility mode 80 (SQL Server 2000).
Can anyone shed any light on where I should be looking to try and solve this please? If there is any other information I can share, specific code snippets etc please just let me know.
Update:
I thought the UPDATEUSAGE answer below had got it but unfortunately it reared up again a little later. After some thinking I've had the following thoughts... There are two instances of IIS, independent of each other, they both talk to a single database whether it be local at the time or not, they both execute identical sync'd code with code that has been working with the same syntax and valid variables for a long time. As the ASP execution through IIS is the only layer in this equation that is not a single point as it were this is where I've headed. When the problem reoccurred, I restarted IIS on the machine at that point that was showing the error (the situation is often that it is only occurring on one of the two servers). The restart of IIS appeared to cure the problem. It then happened on the other server with a different site, again restarting IIS appeared to sort the issue.
Further reading has now lead me to the "Managed pipeline" modes of the app pools. They are currently set to "Integrated". I've done some reading and I'm wondering if they should be set to classic to emulate IIS6. Does anyone have any more thoughts on this?
Many thanks
Eric
Did you:
(1) Update usage counters: In earlier versions of SQL Server, the values for the table and index row counts and page counts can become incorrect. To correct any invalid row or page counts, run DBCC UPDATEUSAGE on all databases following the upgrade.
(2) Rebuild all Indexes
Upgrading from SQL Server 2000 to 2008
I had the same problem and tracked it down to a field definition in my database i had defined as a long integer. the value i had in there was some like 53435534126262 , immediately changed it to a text field and the problem disappeared
try that??
I thought it might be useful to post my findings and solution to this problem as I found no where on the web that mentions the same situation I had.
I went through a number of steps that each seemed to reduce the frequency of the errors but not eliminate them. Firstly I changed the database authentication method to SQL instead of Windows based. At first I changed all the sites to use the same login but later on I changed them to all use a unique login.
I updated the SQL Server with service pack 2 and cumulative update pack 3.
As mentioned, the above steps reduced the frequency of the errors but didn't stop them. I started looking through the class that all the sites use to manage their database connections and use of stored procedures. I came across the line adocommand.parameters.refresh I read up on what this actually does and when called it makes a call to the database to retrieve the parameters of a given stored procedure so that they can be accessed as an object in ASP rather than the parameters having to be given in a particular order and manually assigning the types to them. On the Microsoft page that details this method it has a little footnote that says
Parameters.refresh will fail in some situations or return information that is not entirely correct. Parameters.refresh is particularly vulnerable when used on ASP pages.
This was all it gave and I couldn't find any other details about this. I increased the logging on my sites to, on error, output what parameters.refresh had returned. I caught it in one instance returning the two variables from the stored procedure, with the correct names, but not with the correct variable types. They should have been a VARCHAR and an INT but they came back as both being CURRENCY. Obviously this then errors when you try and assign a string to a CURRENCY. I only managed to catch this one instance of an error before I fixed the problem.
The only way I found that seemed to fix the problem was to change from using an ODBC based driver, both DSN or DSNless, and use the SQL Native Client OLE DB driver with the "PROVIDER" keyword. This had the added benefit of appearing to enable connection pooling when it previously didn't appear to have been working.
One side effect of changing to the driver is that the stored procedures and ASP became susceptible to intermediate results being returned from the stored procedure if there were multiple statements within it and it didn't have SET NOCOUNT ON explicitly set at the top. Rather than trying to update 1000+ stored procedures, I found that the NOCOUNT flag can be set at the database instance level for all databases which solved this problem.
I hope this helps someone, as it was an incredibly frustrating 3 weeks that I spent tracking down this problem. Feel free to ask any further questions and I'll help if I can.
Thanks
Eric
I've created a database in access 2007 that needs to be used by 3 users. I'm stuck because I don't know whether to place a copy on each users' computer or to place it on their SQL server. Placing it on the server would mean one access point which is desirable for data consistency but I don't know whether I need ActiveX. Don't know how to use it either. If I place it one each computer how do I work around the master file updates? Can somebody please break it all down, I'm a NEWBIE!!
Your question seems rather confused to me. You mention a SQL Server, but you don't say your application uses SQL Server for its data storage.
Thus, I can only assume that you have a single MDB or ACCDB file with your data tables and forms and reports all in the one file.
The only proper way to distribute this app is:
split it into front end (forms/reports/etc.) with linked tables that point to the back end (data tables only).
place the back end on your file server and relink your tables to point to the new location of the back end.
give a copy of the front end to each of the 3 users, who will run it from their desktop computers. If you're concerned about distributing changes to the front end, something like Tony Toews's front-end updater is very useful.
Others have jumped in to say that you should put the data in SQL Server, but most 3-user Access apps don't need the power of SQL Server. If you're not given administrative permissions on your SQL Server, it could be quite difficult to continue to alter your application's database.
On the other hand, if your database is going to grow to 1GB or more, or if you have strict security requirements, or if the data in your database is so important as to need completely failproof backups, then SQL Server would be a reasonable data store.
For most homegrown apps, not so much.
The "best" way I've worked this out is using Linked Tables in Access to go to SQL Server (since you stated you have that..?).
Using access as a front end in this scenario isn't the best thing you can do, but with 2007, it's a bit better than if you were a few versions back. Check out this article for info on linking Access into SqlServer:
Import or link to SQL Server data
One easy way is to use the EQL Data plugin: http://eqldata.com
That way you can give a copy of the database to each user, but users can sync the database with other users whenever they want. You can also access your tables and queries on the web.
Two users wanted to share the same database, originally written in MS Access, without conflicting with one another over a single MDB file.
I moved the tables from a simple MS Access database to MySQL using its Migration Toolkit (which works well, by the way) and set up Access to link to those tables via ODBC.
So far, I've run into the following:
You can't insert/update/delete rows in a table without a primary key (no surprise there).
AutoNumber fields in MS Access must be the primary key or they'll just end up as integer columns in MySQL (natch, why wouldn't it be the PK?)
The tables were migrated to MySQL's InnoDB table type, but the Access relationships didn't become MySQL foreign key constraints.
Once the database is in use, can I expect any other issues? Particularly when both users are working in the same table?
I know this topic is not too fresh, but just some additional explanations:
If you want to use MS Access effectively, especially with bigger, multiuser databases, please do the following:
split your MDB into frontend application and backend (data only) files - you'll have two separate MDB files then.
migrate all the tables with data and structure into external database. It can be: MySQL (works very well, no database size limitations, requires some more skills as it's not MS technology, but it is a good choice in many cases - moreover you can scale your backend with more RAM and additional CPUs, so everything depends on your needs and hardware capabilities); Oracle (if you have enough money or some kind of corporate license) or Oracle 10g XE (if this is not a problem, that the database size is limited up to 4 GB and it will always use 1 GB of RAM and 1 CPU), MS SQL Server 2008 (it's a great pair to have MS Access frontend and MS SQL Server backend in all the cases, but you have to pay for license! - advantages are: close integration, both technologies are form the same vendor; MS SQL Server is very easy to maintain an effective at the same time) or Express edition (same story like with Oracle XE - almost the same limitations).
relink your MS Access frontend with backend database. If you selected MS SQL Server for the backend then it will be as easy as to use the wizard from MS Access. For MySQL - you have to use ODBC drivers (it's simple and works very good). For Oracle - please do not use the ODBC drivers from Microsoft. These from Oracle will do their work much better (you can compare the time needed to execute SQL query from MS Access to Oracle via Oracle ODBC and MS Oracle ODBC drivers). At this point you'll have solid database backend and fully functional MS Access frontend - MDB file.
compile your MDB frontend to MDE - it will give you a lot of speed. Moreover, it's the only reasonable form of distributing MS Access application to your end users.
for daily work - use MDE file with MS Access frontend. For futher MS Access frontend development use MDB file.
don't use badly written ActiveX components to enhance MS Access frontend capabilities. Better write them yourself or buy the proper ones.
don't believe into the myths that there are a lot of issues with MS Access - this is a great product which can help in may occassions. The problem is a lot of people assume it's a toy or that MS Access is generaly simple. Usually they generate a lot of errors and issues by themselves and their lack of knowledge and experience. To be successfull with MS Access it is important to understand this tool - this is the same rule, like with any other technology outhere.
I can tell you that I'm using quite advanced MS Access fronted to MySQL backend and I'm very satisfied (as a developer which is maintaining this application). My friends, the users are also satisfied as they feel very comfortable with the GUI (frontend), the speed (MySQL), they don't have any issues with records locking or database performance.
Moreover, it's important to read a lot about good practices and other people experiences. I would say that in many cases MS Access is a good solution. I know a lot of dedicated, custom made systems which started as an experiment in form of private MS Access database (MDB file) and then evolved to: splitted MS Access (MDE - frontend, MDB - backend) and finally to: MS Access frontend (MDE) and "serious" database backend (mainly MS SQL Server and MySQL). It's also important that you can always use your MS Access solution as a working prototype - you have ready to use backend in your database (MySQL - let's assume) and you can rewrite frontend to the technology of your choice (web solution? maybe desktop C# application - what you require!).
I hope I helped some of you considering the work with MS Access.
Regards,
Wawrzyn
http://dcserwis.pl
I had an application that worked likewise: an MS Access frontend to a MySQL backend. It was such a huge pain that I ended up writing a Win32 frontend instead. From the top of my head, I encountered the following problems:
Development of the ODBC link seems to have ceased long ago. There are various different versions floating around --- very confusing. The ODBC link doesn't support Unicode/UTF8, and I remember there were other issues with it as well (though some could be overcome by careful configuration).
You probably want to manually tweak your db schema to make it compatible with MS Access. I see you already found out about the needed surrogate keys (i.e., int primary keys) :-)
You should keep in mind that you may need to use pass-through queries to do more sophisticated SQL manipulations of the MySQL database.
Be careful with using lots of VBA, as that tends to corrupt your frontend file. Regularly compressing the database (using main menu, Tools | Database utilities | Compress and restore, or something like that --- I'm using the Dutch version) and making lots of backups is necessary.
Access tends to cause lots of network traffic. Like, really huge lots. I haven't been able to find a solution for that. Using a network monitor is recommended if you want to keep an eye on that!
Access insists on storing booleans as 0/-1. IMHO, 0/+1 makes more sense, and I believe it is the default way of doing things in MySQL as well. Not a huge problem, but if your checkboxes don't work, you should definitely check this.
One possible alternative would be to put the backend (with the data) on a shared drive. I remember this is well-documented, also in the help. You may want to have a look at some general advice on splitting into a frontend and a backend and code that automatically reconnects to the backend on startup; I can also send you some more sample code, or post it here.
Otherwise, you might also want to consider MS SQL. I don't have experience with that, but I presume it works together with MS Access much more nicely!
Gareth Simpson opined:
If it's only two users, then Access
should do just fine if you put the
.mdb on a shared drive.
Er, no. There is no multi-user Access application for which each user should not have a dedicated copy of the front end. That means each user should have an MDB on their workstation. Why? Because the objects in front ends do not share well (not nearly as well as Jet data tables, though there aren't any of those in this scenario using MySQL as the back end).
Gareth Simpson continued:
I believe the recommended max
concurrent users for Access is 5 but
on occasion I've pushed it past this
and never come unstuck.
No, this is completely incorrect. The theoretical limit for users of an MDB is 255. That's not realistic, of course, as once you reach about 20 users you have to program your Access app carefully to work well (though the things you need to do in an Access-to-Jet app are the same kinds of things you'd do to make any server database application efficient, e.g., retrieving the smallest usable data sets).
In this case, since each user should have an individual copy of the front-end MDB, the multi-user limits of Access/Jet are simply not relevant at all.
I know this doesn't answer your question directly, but it might be worth checking out the SQL Server 2005 migration tool for Access. I've never used the tool, but it might be worth using with SQL Server 2005 Express Edition to see if there are the same issues as you had with MySQL
Dont forget to put some type time/date stamp on each record. sometimes ms access will think "another user has changed or deleted the record" and will not allow you to make a change! I found this out the hard way.
In general, it depends :)
I haven't had a lot of problems when the application side has just been updating the data through the forms. You can get warnings/errors when the same row has been updated by more than one user; but Access seems to be constantly updating its live record sets all the time.
Problems can happen if Alice is already working with record 365, and the Bob updates it, and then Alice tries to update it with her changes. As I recall, Alice will get a cryptic error message. It would be easier for the users if you trap these errors and at least give them a friendlier error message.
I've had more problems when I was editing records in the VB code through RecordSets, especially when combined with editing the same data on forms. That's not necessarily a multi user problem; however, you have almost the same situation because you have one user with multiple connections to the same data.
If it's only two users, then Access should do just fine if you put the .mdb on a shared drive.
Have you tried it first rather than just assume it will be a problem.
I believe the recommended max concurrent users for Access is 5 but on occasion I've pushed it past this and never come unstuck.
On the other hand I did once use Access as the front end to MySQL in a single user environment (me). It was a singularly unpleasant experience, I can't imagine it would become nicer with two users.