0 × 80004005 unspecified error in Access Database

0x80004005 unspecified error in the ACCESS database and its solution.
[Oledbexception (0x80004005): unspecified error]

After three months of project execution, I finally finished the test. I handed in the test yesterday. The following problem occurs:

[oledbexception (0x80004005): unspecified error] system. data. oledb. oledbconnection. processresults (int32 hr) + 20 system. data. oledb. oledbconnection. initializeprovider () + 57 system. data. oledb. oledbconnection. open () + 203 Webb. wave. controls. oledbmanager. filldatatable (datatable I _datatable) + 85 Webb. wave. controls. waveexpire. loadexpiredateforclient (datatable I _table, int64 I _clientid) + 189 Webb. wave. inc_client_accessmanage.loadexpiredate (string I _sortkey) + 99 Webb. wave. inc_client_accessmanage.page_load (Object sender, eventargs e) + 85 system. web. UI. control. onload (eventargs e) + 67 system. web. UI. control. loadrecursive () + 35 system. web. UI. control. loadrecursive () + 98 system. web. UI. control. loadrecursive () + 98 system. web. UI. page. processrequestmain () + 750

Note: this error will always occur after running for a period of time, and the problem will be solved after waiting for a while to work (no matter how long) or restart IIS or server. This problem will occur again (the time is getting shorter.

While I was running on my computer, I basically didn't see such a problem. So I repeatedly searched for the cause and found three related articles in msdn.Article: There is still some truth in this article, which is the same as the cause of my error.
MS-help: // Ms. msdnqtr.2005apr. 1033/enu_kboledb/oledb/251254.htm symptoms

When trying to connect to an access. MDB file, an ODBC error is returned stating "disk or network error ". the Microsoft ole db provider for the Microsoft Jet Database Engine may also return an "unspecified error" (error code = 0x80004005) message.

The problem can occur only when the data source is opened under the Microsoft Internet Information Server (IIS) or a Microsoft Windows NT Service but not under a logged-on user account.

Cause

Jet creates a temporary file when the engine is started. in doing so, it first checks the TMP environment variable and uses that path to define where the temporary file is created. if it doesn't see a tmp environment variable, it looks for the TEMP environment variable. if temp is not defined, it then uses the Windows folder (\ windows or \ WINNT ).

If tmp/temp is defined but points to a nonexistent folder, the error occurs.

Moreover, when opening the ACCESS database through IIS or a Windows NT Service, and when IIS or the service is running under the local system account, the TMP or temp system environment variable is used. when the web services or Windows NT Service are started using a user account, the tmp/temp user profile environment variables is used.

Resolution

Define a tmp or TEMP environment variable and assign the variable to an existing folder. if you are accessing the ACCESS database from IIS, be certain to check the system environment settings rather than environment variables of the logged-on user. also ensure that the iuser anonymous IIS account has access to the Temporary Folder.

You must restart the computer after changing any environment variables.
Environment variables are set under Windows NT 4.0 by going to the control panel and clickingSystemAnd then selectingEnvironmentTab.

However, I don't understand why this problem was not found during tests in the past few weeks, but has become more and more frequent in recent days?
I have found several related articles on the Internet (there are many posts on the forum discussing this issue, but I cannot find a solution ):
Http://www.issociate.de/board/post/276824/ASP_Error_0x80004005_Unspecified_Error.html
Http://www.sitepoint.com/forums/showthread.php? T = 213666
Http://support.microsoft.com/default.aspx? SCID = KB; en-US; 825738

After thinking for a few minutes, I wonder if it is the reason why temporary files cannot be created? In fact, as long as I can make a mistake appear on my own computer, I can do it well, but the problem is that it only occasionally appears on my computer, and it will soon be better, it appears only two or three times from start to end. But there are more and more problems on the server, and it will not work in a few minutes. According to the previous articles, I decided to perform the next test:

1. delete the file write permission of the IIS account (Internet Guest Account) under Windows. Of course, this permission is only for the project directory.
2. Also delete its write permissions in the temporary directory (C: \ Documents and Settings \ WEBB-COUNTRY-WU \ ASPnet \ Local Settings \ Temp, not all machines are different.

Now, the same error occurs on my computer, and all database-related pages cannot be accessed. According to the description in msdn, this is because you do not have the permission to write files in the temporary directory. However, the problem is that the error on the server is not always correct, but a temporary error is normal.

The only thing that can be explained is that the temporary files on the server are full !!!! This is not a good proof. I cannot keep testing and make my temporary files full (even if I copy files to a temporary directory, it cannot be considered an IIS account, but an operator ), in addition, the temporary file itself (the link thread of oledb) will also be deleted. I had to try another way: Use the disk quota. To the IIS account: the Internet Guest Account has only 10 KB of write permission on the drive C, and then the test is as scheduled ......

At this point, you can be sure that there are too many temporary files on the server. It seems that you want to restart the server, or clear the temporary files or adjust the disk space ......

Alas, I am adding a day to work in vain ,..... I hope this article will help those who have not solved the problem. At the same time, the MS website and several articles on msdn are also very helpful, especially the other reasons for the error, although I have not met, but you already know what to do if you encounter it.