Troubleshooting microsoft error messages – Adobe Dreamweaver CC 2014 v.13 User Manual
Page 649
Understanding anonymous authentication and the IUSR account at
Setting IIS web server permissions at
Troubleshooting Microsoft error messages
These Microsoft error messages can occur when you request a dynamic page from the server if you use Internet Information Server (IIS) with a
Microsoft database system such as Access or SQL Server.
Note: Adobe does not provide technical support for third-party software such as Microsoft Windows, and IIS. If this information does not fix your
problem, please contact Microsoft technical support or visit the Microsoft support website at
For more information on 80004005 errors, see “INFO: Troubleshooting Guide for 80004005 Errors in Active Server Pages and Microsoft Data
Access Components (Q306518),” on the Microsoft website at
[Reference]80004005—Data source name not found and no default driver specified
This error occurs when you attempt to view a dynamic page in a web browser or in Live view. The error message may vary depending on your
database and web server. Other variations of the error message include:
80004005—Driver's SQLSetConnectAttr failed
80004005—General error unable to open registry key 'DriverId'
Here are possible causes and solutions:
The page can’t find the DSN. Make sure a DSN has been created on both the web server and on the local machine.
The DSN might have been set up as a user DSN, not as a system DSN. Delete the user DSN and create a system DSN to replace it.
Note: If you don’t delete the user DSN, the duplicate DSN names produce a new ODBC error.
If you use Microsoft Access, the database file (.mdb) might be locked. The lock might be due to a DSN with a different name accessing the
database. In Windows Explorer, search for the lock file (.ldb) in the folder containing the database file (.mdb) and delete the .ldb file. If another
DSN is pointing to the same database file, delete the DSN to prevent the error in the future. Reboot the computer after making any changes.
[Reference]80004005—Couldn’t use ‘(unknown)’; file already in use
This error occurs when you use a Microsoft Access database and attempt to view a dynamic page in a web browser or in Live view. Another
variation of this error message is “80004005—Microsoft Jet database engine cannot open the file (unknown).”
The probable cause is a permissions problem. Here are some specific causes and solutions:
The account being used by Internet Information Server (usually IUSR) might not have the correct Windows permissions for a file-based
database or for the folder containing the file. Check the permissions on the IIS account (IUSR) in the user manager.
You might not have permission to create or destroy temporary files. Check the permissions on the file and the folder. Make sure that you
have permission to create or destroy any temporary files. Temporary files are usually created in the same folder as the database, but the file
may also be created in other folders such as /Winnt.
In Windows 2000, the time-out value may need to be changed for the Access database DSN. To change the time-out value, select Start >
Settings > Control Panel > Administrative Tools > Data Sources (ODBC). Click the System tab, highlight the correct DSN, and click the
Configure button. Click the Options button and change the Page Timeout value to 5000.
If you still have problems, see the following Microsoft Knowledge Base articles:
PRB: 80004005 “Couldn't Use ‘(unknown)’; File Already in Use” at
.
PRB: Microsoft Access Database Connectivity Fails in Active Server Pages at
PRB: Error “Cannot Open File Unknown” Using Access at
.
[Reference]80004005—Logon Failed()
This error occurs when you use Microsoft SQL Server and attempt to view a dynamic page in a web browser or in Live view.
This error is generated by SQL Server if it doesn’t accept or recognize the logon account or password being submitted (if you’re using standard
security), or if a Windows account does not map to a SQL account (if you’re using integrated security).
Here are possible solutions:
If you use standard security, the account name and password might be incorrect. Try the system Admin account and password (UID= “sa”
and no password), which must be defined in the connection string line. (DSNs do not store user names and passwords.)
If you use integrated security, check the Windows account calling the page and find its mapped SQL account (if any).
SQL Server does not allow an underscore in SQL account names. If someone manually maps the Windows IUSR_machinename account to
642