Reputation: 88082
I have a simple web site that needs to connect to an access database over a unc share.
The server is a windows 2003 box running IIS 6. The connection is via ODBC.
We're receiving an error message that says "
ERROR [42000] [Microsoft][ODBC Microsoft Access Driver] Not a valid password.
ERROR [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed
I'm guessing that the IIS server doesn't have access to the share. The app pool is running under Network Service.
How can I fix this?
UPDATE
This just got weird. IF I have ReadOnly checked in the ODBC configuration AND No one else is attached to that database, then it works.
If someone else attaches to it then it gives me an error "HY000][Microsoft][ODBC Microsoft Access Driver] COuld not use '(unknown)'; file already in use."
If I uncheck the readonly configuration (no other changes), then it says "Not a valid password".
Upvotes: 2
Views: 2420
Reputation: 23067
This is not something I have experience with (I don't consider Jet/ACE to be an appropriate data store for a website), but I know a lot about Jet/ACE.
The fact that when you set to Read-only you get a connection suggests that the user the web server is running as lacks write permission on the file you're opening (or, more likely, for the folder it's in and/or the share that makes it available over the network). A read-only connection from a single user won't need to create an LDB file (the record-locking file). If the web server user doesn't have CHANGE permission on the folder the MDB/ACCDB is stored in, it won't be able to create the LDB file, and thus won't be able to edit the file.
Also, keep in mind that all operations with Jet/ACE utilize a username. Transparently it will use the default admin account with no password, but maybe you've attempted to provide some other username/password pair. In that case, it could be that you're using the wrong workgroup file, or a different one than you assume is appropriate.
Upvotes: 1
Reputation: 124794
IF I have ReadOnly checked in the ODBC configuration AND No one else is attached to that database, then it works
That would suggest that you have read access to the share, but not write access.
Upvotes: 2
Reputation: 3477
This is a very common problem. One way of fixing this is to run your application pool under domain user that has access to that share, or have you web application impersonate a domain user that has access to the share:
How to access network files from IIS applications
Upvotes: 1