Mark Hensler — Sat, 10 Nov 2001 20:28:59 +0000

Just search for the error you have. You'll be overwhelmed by infomation.

Matt-T — Sat, 10 Nov 2001 17:59:54 +0000

Hey, thanks a lot!
I think I found my error in that trouble shooting guide, I believe I was using a reserved word!

I dont have anything which tells me that I'm using a reserved word, which is why I didnt detect it.

Out of curiousity, where did you get the trouble-shooting guide from for that specific error?
Something like that would come in really handy for future errors.

Thanks again!!

Peter J. Boettcher — Sat, 10 Nov 2001 15:50:06 +0000

The folder permissions would have to be checked on the server, the folder needs to have read/write access for the IUSER_machine account (the one used by IIS)

The credentials I referred to are only necessary if you have password protected your database, it would be part of your connection string.

Here's everything I could find regarding error '8004005', how it helps.

Troubleshooting Guide for 8004005 error messages.

Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Microsoft Access 97 Driver] The Microsoft Jet database engine
cannot open the file '(unknown)'. It is already opened exclusively by another
user, or you need permission to view its data.
Can happen if the account being used by IIS (usually IUSR) doesn't have the
correct NT permissions for a file based database orthe folder it is located
in.
Check permissions on the file, and folder. Ensure ability to create/destroy
any temp files. Temp files are usually created in the same folder as
database, but can be created elsewhere. Run NT File Monitor to check for
write failures.
If using UNC, check permissions on the Share.
Ensure file and DSN are not marked as Exclusive.
Simplify. Use a System DSN that uses a local drive letter.
The 'other user' might be InterDev. Close any InterDev projects that contain a
data connection to this database.
Delegation issue. Ensure the authentication method. If the connection string
uses UNC, try using Basic authentication or an absolute path such as
c:\mydata\data.mdb. This can happen even if the UNC pointsto a resource
local to the IIS machine.
IIS 4.0 Bug. UNC should work for Basic / Anonymous access, but doesn't under
IIS 4.0 because Transaction Server is switching the user context to SYSTEM
when it reads the database. The system account cannotaccess networked
resources. Use a local path. For InterDev to work remotely, setup system
DSN's as per article Q178215. This article refers to authenticated projects,
but the fix is applicable to this configuration..

KB References:
Q166029 PRB: Cannot Open File Unknown Using Access
Q178215 HOWTO: Configure VID to Work with an Authenticated Web Project

Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Microsoft Access 97 Driver] Couldn't use '(unknown)'; file
already in use.
The database cannot be locked correctly for multiple users. See the KB article
referenced below.

KB References:
Q174943 PRB: 80004005 "Couldn't Use '(unknown)'; File Already in Use"

Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Driver Manager] Data source name not found and no default
driver specified.
Most common cause: the connection string is a session variable initialized in
the Global.asa and the global.asa isn't firing. Check that the variable is
being initialized correctly with:

<?php
= "'auth_user' is " & request.servervariables("auth_user")
?>

<?php
= "'auth_type' is " & request.servervariables("auth_type")
?>

<?php
= "connection string is " & session("your_connectionstring")
?>

If the Global.asa isn't firing, check to ensure it is in an Application Root
for IIS 4.0, or a Virtual Root with Execute checked under IIS 3.0. Also, a
bug detailed in Q173742 may prevent the Global.asa from being firedwhen NT
permissions have restricted access to the folder.
DSN name not found. Ensure user is not using a USER DSN.
If using a file or system DSN, try changing the connection string to be just
"DSN=MySystemDSN" or "DBQ=MyFileDSN" as appropriate.
Ensure latest drivers installed using MDAC

KB References:
Q173742 BUG: Global.asa Not Executed If Restricting Web Access
Q172864 ASP Pages Fail on Access to Session and Application Objects

Microsoft OLE DB Provider for ODBC Drivers error'80004005'
[Microsoft][ODBC Access 97 ODBC driver Driver]General error Unable to open
registry key 'DriverId'.
Error reading a value from the registry.

KB References:
Q156526 General Error=51 Connecting to an Access Datasource

Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC SQL Server Driver][dbnmpntw]ConnectionOpen (CreateFile()).
There are two causes of this error. Both are permissions related and involve a
database that is either on a different machine from the web server, or the
database is possibly being referenced using a UNC path (\\Server\Share). Even
if the database is on the same machine as the web server, UNC paths make the
database appear to the web server to be on a different machine on the
network.

1. If the asp page is accessed anonymously:

If IIS is serving up the page to an anonymous user, IIS will use (by default)
an NT account called IUSR_. This account is local to the web
server and is essentially unknown to any other machines on the network. When
IIS, operating under the security context of the IUSR account, tries to access
any resources on a remote machine, the remote machine will try to validate the
account being used. Since the IUSRaccount is a local account that is unknown
to the remote machine, access is denied.

There are two solutions when anonymous access causes this problem:

a) In the Internet Service Manager tool, under Web Properties, change the
anonymous logon account from the default local account to a valid domain based
account. In the 'UserName' field, enter the domain account to use as
'domain\userid'. In this way, the remote machine can check with the domain
controller to validate the security credentials passed to it by IIS.

b) Duplicate the IUSR_ account on the remote machine that
contains the resource you wish to access. If an account is created on the
remote machine that has the exact same name and password, NT will treat them
as equivalent accounts.

2. If the ASP page only allows authenticated access:

If the page doesn't allow anonymous access, IIS will try and authenticate the
user making the request, and use their security credentials for all activities
such as database accesses. There are two primary causes for a failure in this
scenario

a) By default, IIS is configured to use NT Challenge/Response as the
authentication method. Because of limitations in the NT 4.0 (and prior)
security model, a user that has been authenticated using NT Challenge/Response
cannot access resources on remote machines. This is commonly referred to as a
'delegation' problem. To verify if this is the case, in the Internet Services
Manager tool, under Webproperties, select the Basic(Clear Text) checkbox and
deselect the Windows NT Challenge/Response. If this solves the problem, then
this is a clear delegation issue.

b) If problems persist, it is likely that user account being used does not
have rights to the SQL NT machine. Try using an account that has known access
to the SQL machine.

For more information concerning delegation, how IIS uses authentication to
secure a web site, and problems such as this, see the article "IIS
Authentication and Security for Internet Developers on

http://www.microsoft.com/workshop/server/default.asp

KB References:
Q175671 PRB: 80004005 ConnectionOpen (CreateFile ()) Error Accessing SQL

Microsoft OLE DB Provider for ODBC Drivers error '8004005'
Microsoft][ODBC Microsoft SQL Driver] Logon Failed()

This error is generated by SQL server if it doesn't accept or recognize the
logon account and/or password being submitted (if using Standard security) or
if there is no NTaccount to SQL account mapping (when using Integrated
security
If using standard security, the SQL account name and password are incorrect.
Try the system admin account and password (UID= "SA" and null password).
These must be defined on the connection string line. DSN's do not store
usernames and passwords.
If using Integrated security, check the NT account that is calling the page,
and find out what account (if any) it is mapped to.
SQL does not allow an underscore in a SQL account name. If someone manually
mapped the NT IUSR_machinename account to a SQL account of the same name, it
will fail. Map any account that uses an underscore to an account name on SQL
that doesn't use the underscore.

KB References:
Q149425 IDC: Error Performing Query, Not Defined as a Valid User

Microsoft OLE DB Provider for ODBC Drivers error '80004005' [Microsoft][ODBC
SQL Server Driver][SQL Server] Login failed- User: Reason: Not defined as a
valid user of a trusted SQL Server connection. Integrated Security is turned
on in SQL enterprise manager, and the NT account being used hasn't been
mapped to a SQL account. Try changing SQL to use Standard Security (In
Enterprise Manager, select Server/ SQL Server/Configure…/Security
Options/Standard

KB References:
Q149425 IDC: Error Performing Query, Not Defined as a Valid User

Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Microsoft Access 97 Driver] Couldn't lock file.
Can be caused by not having correct rights to create the lock file for an
access database.
Try giving the user accessing the database (usually the IUSR_machinename
account full control to the share/folder

KB References:
none

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC Microsoft Access 97 Driver] Syntax error in INSERT INTO
statement.
Column name is a reserved word, such as DATE. Change to MyDate.

KB References:
none

Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Microsoft Access 97 Driver] '(unknown)' isn't a valid path.
Make sure that the path name is spelled correctly and that you are connected
to the server on which the file resides.
The path being readby the web server is not a valid path. This most commonly
happens when the global.asa is being used and the connection string was
created on a different machine than the web server. If the path is a mapped
drive letter, it is probably only valid for the client machine that created
the connection string

KB References:
Q167452 PRB: 'Not a valid path' Error when Using Access Data Source

Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC SQL Server Driver][SQL Server]The query and the views in it
exceed the limit of 16 tables.
The query is too complex. There are several limitations on a query

KB References:
Q125767 PRB: Query Too Complex Error After Execution of SQL Query

Microsoft OLE DBProvider for ODBC Drivers error '80004005'
[Microsoft][ODBC SQL Server Driver][DBNMPNTW]ConnectionWrite
(GetOverLappedResult()).
When the allow Anonymous User context is turned off, NT is closing the pipe to
SQL Server after the first request is complete. This is because the first
connection to SQL Server is made under the IIS Anonymous User account. IIS
then either impersonates the browser client on that same thread, or tries to
access the connection on a different thread that is running inthe
impersonated user context. In either case NT would detect the attempt to use a
network named pipe handle that had been opened in a different user context and
force the pipe closed, per its security rules.
When the connections are viewed on the SQL Server with a network monitor, a
name pipe close request comes from NT, causing the error in the Web browser.

KB References:
Q166659 PRB: Accessing SQL Database Fails on Second Attempt

Matt-T — Sat, 10 Nov 2001 12:50:22 +0000

The error which appears on the website is as follows:
----------------------------------------
Microsoft OLE DB Provider for ODBC Drivers error '80004005'

[Microsoft][ODBC Microsoft Access Driver] Syntax error in INSERT INTO statement.

/search_page/question_form_thanku.asp, line 47
---------------------------------------
Line47 in the ASP code is: objRS.Update

The connection to the database is fine, as I checked that I can read from it, and I can.

I'm not well up on SQL, but I believe that the INSERT INTO statement is generated by Access to allow a new record to be written.

My ASP code is identical to other collegues code and some text books, and their's works. So it shouldnt be that.

Since other people I know havent had this problem, and they are on the same server as me, I wouldnt have thought it was an error by the server (I dont have control of the server anyway)

How can I check the permissions (write/modify) on the folder? and how would I check the correct credentials are being passed?
I cant see anywhere, where the database could be set to read-only.

Any more ideas? Thanks for your help by the way!

Peter J. Boettcher — Fri, 09 Nov 2001 15:43:00 +0000

Well, if you're sure the code is correct and the database is not set to read only, then there's not much else you can check. Are the permissions on the folder where it sits on the server set correctly (write/modify), are you passing the right credentials... Are you sure it's not a problem with the query/code?