(We split up this article into two - one involving database-related issues, the other encompassing everything else. If your error does not involve a database, please see Article #2413.)
First off, test connecting to your database *without* any sort of DSN. See Article #2126 for sample DSN-less connection strings. Removing an incorrectly configured DSN might solve any 80004005 errors, but if nothing else, it will improve the performance and scalability of your application.
Next, make sure you have the most recent MDAC (MDAC Download Page). If you are using Access, make sure your database is in 2000 or 2002/XP format, and that your servers have the most recent JET drivers (see Article #2342). In addition, make sure the anonymous user on your machine (IUSR_machineName) has both read and write access to the folder in which the MDB file(s) reside. Finally, make sure your server is up-to-date (see Article #2151 for recent information on service packs and security fixes).
That said, in the remainder of the article, we will highlight some of the more common 80004005 errors, and attempt to explain and/or solve them.
This usually means that the MDB file is open in a copy of Access on the server, or Visual InterDev is open and has an active connection to the database — see KB #174943. You may just have incorrect permissions for IUSR_machineName (see KB #253604). This can also mean you are attempting to connect to an MDB file on a remote share; if so, see Article #2168 and KB #189408 for more information. See KB #315456 and PRB: "Disk or Network Error" o... for information on correcting the permissions on your %TEMP% folder. See KB #166029 for information on configuring credentials for authenticated users connecting to an Access database file. For other possible reasons, see KB #306269.
One possibility is that the file is corrupt (Access databases have a tendency to do that -- see Article #2190 for a way to compact / repair the database through code). A more common reason is that you are trying to connect to an Access 97 database with Access 2000 or better drivers, or vice-versa. Make sure the server has the most recent MDAC (MDAC Download Page) and the most recent JET drivers (see Article #2342). Also, try upgrading your database to a more recent format (Access 2000 or better).
Make sure that IUSR_machinename has read/write access to the temp directory, and the folder where the MDB file is located. You may also try compacting and reparing the database (to see how to do this from code, without having to download the database file and open it within Access, see Article #2190). Make sure you are using JET/OLE-DB drivers to connect to the database, not native/ODBC (see Article #2126).
If your table is large, you may need to increase the value for MaxLocksPerFile. You can do this through the registry:
If you don't have direct access to the machine's registry, you can also try editing this programmatically:
A safe value for n is probably double the number of rows in the largest table you are trying to modify when you receive this error.
For information on this error, see Article #2259.
This usually happens in one of the following scenarios:
This is almost always a permissions issue, where IUSR_machineName or the autheticated user doesn't have read or write access to the MDB file, the folder in which it is located, or the TEMP/TMP folders. For more information, see Article #2062.
A "bookmark" is the unique value that Access uses to identify a single row. This will typically point to two things:
System error 5 means "Access is denied." If you are using a DSN, make sure you are also passing username and password information. Or, better yet, stop using a DSN (see Article #2126). Make sure you are clear on what authentication method you are using: if you are passing a username and password, make sure SQL Server is set up for "mixed" authentication; if it is, then the opposite is true... make sure you are passing a username and password. Also, check the Windows user account that SQL Server is running under; it may not have enough permissions to access network shares or other resources necessary. You should also check for permissions changes on all of the drives SQL Server uses, including those that house master, msdb, tempdb, etc.
This usually happens because the anonymous or authenticated user does not have write permissions to create the LDB file (this is Access' 'scratch' file). Make sure IUSR_machineName (or the user(s)/group(s) accessing the application) have write permissions on the folder where the MDB file located.
Make sure you are using the most recent MDAC (from MDAC Download Page) and, if using Access, the most recent JET drivers (see Article #2342). See KB #249638. If you are using Oracle, this could be due to the scenario described in KB #248668.
This is actually often due to a corrupt database, when a table has long value columns (which are stored off-row). To fix, either run a compact / repair on the MDB file (see Article #2190 for information on doing so from ASP), or import all of its objects into a new MDB file and replace the existing file.
Again, IUSR_<machineName> must have read and write permissions not only on the MDB file, but also on the folder in which it resides, and in some cases the system %TEMP% folder. See Article #2154 and KB #315456 for more information. If you are trying to access a network drive, see Article #2168 for information on setting up IUSR_<machineName> to connect to an Access database via a UNC share. You should also check out Article #2142 for information on opening Access in the correct mode (e.g. adModeReadWrite).
There are certain situations where you will need to set up permissions for the IWAM_<machineName> user as well. Specifically, the C:\document and settings\%domainname%\IWAM_localmachine\local settings\temp folder. Thanks to Sylvain Paquin for pointing this out to us!
If you are not using anonymous access, but rather Windows Authentication, you want to be sure that all potential users are in a Windows group that has sufficient privileges on the folder on the web site where the MDB files resides. You might have to update individual permissions systematically if you are unable to do so via group membership.
If you are getting "unspecified error" then try running the IIS site in its own memory space or, if it is already doing so, returning it to the normal memory pool. Another possibility is the symptom described in KB #225042.
Finally, Access can produce the "unspecified error" message if you use reserved words anywhere in your SQL statement (see Article #2080 for a list of reserved words).
This could be because you are trying to create an ADO recordset object as a session variable. See Article #2053 for a variety of links explaining the reasons to avoid this; and see KB #262681 for specific information about this error.
See Article #2220 for a description of this informational message.
While the first error message is definitely more cryptic than the others, they all mean the same thing. The first simply uses DBNMPNTW, which is the protocol name for named pipes. What the error means is that the SQL Server you defined in your connection string is invalid - either because it is currently down, you named it wrong (either by hostname, DNS/domain or IP address), or you don't have permission to connect.
If you are expecting to connect by IP address, make sure you override named pipes (see Article #2082).
If you are using SQL Server authentication, make sure both ends are set up for it (see Article #2138).
If the error is 'SQL Server does not exist or access denied', see KB #328306, which has a large variety of possible causes and solutions. Also see KB #888228 if you are trying to connect to a named instance within a SQL Server 2000 cluster.
If the ASP page and SQL Server are on the same machine, then it may be a loopback problem - try using 127.0.0.1, LOCALHOST, (local), or just a period (instead of the external IP or network name) in the connection string.
This can occur if you use a valid user name in your connection string, but specify a database that user cannot access. Typically, this is because a user's default database is unavailable for verification (and this is a necessary step in the verification handshake). This can be because the default database is in single user mode, is offline, has been detached, or this user has been explicitly removed from their default database.
You can check their default database by issuing the following:
You can change the default database for this user issuing the following:
First off, make sure you are using a DSN-less OLEDB connection string to interface with SQL Server, not a DSN or the native SQL Server driver. Next you need to decide how you are going to connect to SQL Server. If you are using a SQL user account, you should not have anything like "Integrated Security=SSPI" in your connection string. See Article #2126 for more information; also, see KB #811889, KB #814401, KB #269541 and KB #247931.
I have seen this error when a user is associated with a login within a certain database, and their default database is set (using EXEC sp_defaultdb), then either the database is removed or the user is denied access to the database (but the login can still access the server). Since the initial connection is trying to set context to the user's default database, which either doesn't exist or is off limits, the process fails. To fix this, simply connect through Query Analyzer with a different login, and set the user's default database to a database that exists *and* is accessible by the user.
The MDB file you referenced in your connection string either doesn't exist, or might be malformed (e.g. maybe you just entered a folder name). Response.Write your connection string to the screen and see exactly what it contains.
This error message is pretty self-explanatory... your connection string either references a database name that doesn't exist, or provides an invalid / empty password.
Your connection string is, well, missing the DSN or SERVER keyword. You should not be using a DSN; see Article #2126 for valid connection string samples.
This usually happens with Oracle, when using a DSN or a misconfigured OLEDB connection string. To solve, drop-kick the DSN. Try using the OLEDB providers instead of using ODBC. First, try the Microsoft-provided OLEDB drivers:
If that doesn't work, download the Oracle OLEDB provider and use this connection string:
You have incorrectly configured SQL Mail. See if any of the following KB articles help: KB #263556, KB #274330, KB #279867, KB #293422, KB #312839, KB #315886, KB #321183.
Also, be sure to consider using XP_SMTP_SendMail (see Article #2403).
If you are trying to use Windows Authentication to connect to SQL Server, make sure the account being used has been mapped to a valid SQL user or role, and that the user has been authenticated correctly (see Article #2126 and KB #306586).
This usually means you left out some of the properties required to establish a connection. For example, you can reproduce with the following code:
To correct, make sure you've included all necessary parameters (see Article #2126 for valid connection string attributes).
Your connection string is malformed (perhaps you mixed up the Provider and Driver keywords?). Again, see Article #2126 for valid connection strings.
The main problem here is that you are using an ADODB.Recordset object to perform data manipulation operations. As described in Article #2191, do not try to hold recordsets open long enough to modify their contents back in the database. Get in and get out as quick as possible; therefore, execute direct INSERT/UPDATE/DELETE statements.
This can occur if you use an isolation level of READ COMMITTED or READ UNCOMMITTED and have multiple concurrent connections attempting to run the same procedure or batch. Consider using REPEATABLE READ or even SERIALIZABLE, realizing that this will be a performance hit (usually sending lock blocks through the roof). Otherwise, try and make your T-SQL code more efficient, so that there is less chance that two unique users will trip over each other.
This is often a firewall / router issue. Test that your web server can ping the SQL Server (both by name and IP) and make sure that your connection string points to a valid IP address or network name.
This is usually an intermittent error... it will happen every once in a while, and can be attributed to perhaps a flaky network connection or an isolated network jam. If the error message(s) persist, see the following suggestions:
If you are using an ODBC connection, see KB #176256 - and consider using OLEDB provider instead of the native SQL Server driver (see Article #2126).
If there is a specific stored procedure causing this problem, try adding these lines to the beginning of the proc, running it once, and then commenting out or removing the NO_BROWSETABLE line:
If you are querying system tables, use a forward-only cursor (to be safest, avoid ADODB.Recordset altogether).
If you are using SQL Server 7.0: if you have ANSI_WARNINGS set to OFF, see KB #259775; if you are using the ROUND() function, make sure that the parameters you are sending are not null (see KB #199105)
If you are using SQL Server 2000, and are using SELECT DISTINCT on a table with a LEFT JOIN on a view, upgrade to SQL Server 2000 Service Pack 2 (see KB #308547).
If you are using MTS transactions, try to change your approach by using transactions within SQL Server.
If none of the above solves your issue, see KB #243899.
Sounds like you are relying on a dynamic recordset of some kind. There really is no reason to do this in ASP; open a static, forward-only recordset for use in ASP. Issue DELETE / UPDATE statements rather than trying to update the recordset directly, and use INSERT rather than AddNew. And stop using the ODBC driver; use OLE-DB instead (see Article #2126 for some sample connection strings).
You are using MySQL, have opened a recordset that does not include a primary key, and have issued rs.update() in an attempt to modify a single row. Use an UPDATE statement.
One potential solution, according to KB #178040, is to use TCP/IP instead of named pipes. Or, according to KB #186726, use a local connection string, instead of a network string. Personally, I've never found any reason to use Named Pipes in a web environment. See Article #2126 for sample DSN-less connection strings that avoid using Named Pipes.
This usually means you have some code like this:
This can also happen if you are using ADODB.Recordset, and you use open and try to iterate through the results, which are actually EOF. ADODB.Recordset doesn't always die gracefully, and we recommend you stick to more straightforward methods for opening recordsets in ASP.
If you are retrieving data from a stored procedure, you might consider using SET NOCOUNT ON. See Article #2246 and KB #235340 for more information.
If you are using Commerce Server, see KB #303673.
This usually means that the object name was misspelled or doesn't exist, or the user connecting to the database cannot see the object because they do not have appropriate object-level permissions. For more information, see Article #2164.
This usually means that you simply have ODBC drivers that are out of date. Try updating to the latest ODBC drivers for your data source (this may mean getting 3rd party drivers from the manufacturer), catching up on MDAC from the MDAC Download Page, and possibly switching to OLEDB instead of ODBC (if possible). See Article #2126 for some potential connection string changes.
Make sure you are not using any reserved words (e.g. Date or Password) as column names ... if you cannot change the column names, use  brackets around them (see Article #2080 for a list of reserved words). Ensure that your datatypes are appropriately delimited (e.g. no delimiters for numbers, ' for strings (and dates in SQL Server), # for dates in Access. Also, try to avoid using rs.AddNew / rs.Update -- use a direct INSERT or UPDATE statement instead. This is more efficient and easier to debug (see Article #2191).
This seems like you are trying to insert a row into a child table where the foreign key does not exist in the parent table. It might be that your child key value is invalid, or it might be that you are attempting to insert a row into the child table and then the parent table, in which case you need to check the order of your statements.
Make sure that if you intend for the column to contain empty strings, that you explicitly allow it to do so (you can set this in the design view within Access). If you do not intend to allow empty strings, then validate your SQL statement before passing it to the database.
This one is quite similar, and pretty self-explanatory; you attempted to pass in a NULL value, but the column does not allow NULLs. You will need to validate the value for this column when building your SQL statement.
This usually happens when your parameters are empty, or strings aren't properly delimited, e.g. in the following code:
Of course, you'll want to fix this problem by making sure you're not inserting empty or non-delimited strings.
Double-check your connection string. This is usually caused by invalid characters or empty parameters in the connection string. See Article #2126 for examples of valid connection strings.
This is the most verbose error message I've seen from Microsoft to date. It seems pretty self-explanatory; you need to look at your query, and look at your data, and determine why one of these relationships or constraints would be violated by committing the INSERT / UPDATE you are attempting.
This error message indicates that the spid attempted to execute an instruction that is currently not allowed. Check your SQL Server error logs for access violations and other errors. Disable any startup procedures and make sure the server starts cleanly. Check the log folder for .dmp files that may have happened around the same time.
Make sure the services MSSQLServer and MSSQLOLAPServices are both running.
You are either attempting to access Analysis Server while it is preparing the cube, or you are referencing a cube that does not exist.
You are either attempting to connect to AS while a a database is being restored, or the initial catalog in your connection string is incorrect.
You are attempting to access a cube that has been processed but not yet had roles applied; or, you are accessing a cube with a user that does not have proper permissions.
Finally, KB #306518 contains a listing of many 80004005 error messages, the most frequent causes of the error messages, and troubleshooting steps to resolve them.
If you are using DB2 / AS/400
AS400 imposes a limit (through QQRYTIMLMT) on queries... and it will refuse to run any query which appear, through estimation, that they will take longer than y seconds.
Increase the commandTimeout on the connection object to some value higher than x (give yourself some buffer because the estimated query plan might change). For information on changing the commandTimeout value, see Article #2066.
If you are using SQLBase
Check out this thread on Google, it may be of help:
Google Groups : forum.sqlbase
(We will be covering MySQL and Oracle 80004005 articles in a forthcoming update.)
If you know of any other 80004005 errors that we haven't covered here, please let us know...
Related ArticlesWhy do I get 8002000A errors?
Why do I get 80040200 / 80040514 / 800A0E7A errors?
Why do I get 80040e09 errors?
Why do I get 80040E0C errors?
Why do I get 80040E10 errors?
Why do I get 80040E14 errors?
Why do I get 80040E21 errors?
Why do I get 80040E23 errors?
Why do I get 80040E24 errors?
Why do I get 80040E2F errors?
Why do I get 80040e30 errors?
Why do I get 80040E31 errors?
Why do I get 80040E37 errors?
Why do I get 80040e4e errors?
Why do I get 80040E54 errors?
Why do I get 80040E57 / 80040E07 errors?
Why do I get 8004D00A errors?
Why do I get 80070070 errors?
Why do I get 800A01FB errors?
Why do I get 800A0BB9 / 800A1391 errors?
Why do I get 800A0C93 errors?
Why do I get 800a0cb3 errors?
Why do I get 800A0CC1 errors?
Why do I get 800A0E78 errors?
Why do I get 800A0E7C errors?
Why do I get 800A0E7D errors?
Can I use the NZ() function without getting 80040E14 errors?