IIS 7 and Above
Classic ASP App getting classic jet engine error 80040e09 -- cannot u...
Last post Jul 24, 2015 05:57 AM by Pengzhen Song - MSFT
Jul 17, 2015 04:56 PM|LLahman|LINK
Please don't tell me this question has been asked before...I know it's been asked before in hundreds of forums (I know because I've read every single one of them in the last 48 hours and none are applicable and none resolve my problem)...
I have a classic asp application (being replaced in about 30 days with new .net application) that has been running on Server 2003 and I am trying to move it to Server 2012 for the next 30 to 60 days because my hosting company is dropping support for 2003
(I know, my problem but that isn't my question).
I have successfully gotten this application to run on my own test/dev Server 2012 box using the exact same application code, MS Access database driver, same installation/configuration steps, etc.
I can display the site's home page with no problem. I can logon through it's own authentication process with no problem, but when the logon process attempts to set the value of the "Last Updated Date/Time" field the app blows up with:
Microsoft JET Database Engine
Cannot update. Database or object is read-only.
/PAGELogonEdit.asp, line 413
I know everyone reading this is already saying "you need to set permissions for IUSRS_..... I've done that (about 4 times now). Obviously, I have everything ALMOST correct or I wouldn't
be reading the database at all. As I said, I have a test/dev server in my office where I tested this whole process successfully before attempting to move it to a well-known and professional hosting company. The line of code that's blowing up works just fine
under Server 2003 and on my Server 2012 box. It's just the first time in the process where a database field is being updated with a new value.
line 413 --
The "GetClientNow()" function is just a simple time zone-testing function that returns the customers
current time. Nothing scientific.
I have checked (and rechecked and rechecked) the permissions on the folders, the permissions on the
actual .mdb file, etc. To the best of my knowledge, I have all of the necessary 32-bit settings defined correctly (they are exactly like the test/dev box I have in my office) and nothing is getting me past this.
Does anyone have an idea of what I can check, try, etc. to get around this annoying issue? I don't
have much hair left to pull out. I would like to keep what little is left up there!
Thanks in advance!
Jul 18, 2015 02:14 AM|tweenet|LINK
Can you post the NTFS permissions here using:
Also, do you have anonymous authentication enabled and if yes, what's the user for that.
What's the identity of the application pool you are using?
Jul 18, 2015 02:44 PM|LLahman|LINK
Permissions (using the command line you provided above, thank you) are:
As far as "do you have anonymous authentication enabled?", the answer is 'yes' (assuming you are talking about the IIS web site Authentication screen...Anonymous Authentication is Enabled and ASP.NET Impersonation is Disabled. Other Authentication forms
are also Disabled.
Thanks for the question and command line. To be honest, I've never looked at the output from that command so I'm not certain what they are saying. I would think they are saying (F) = "full" and that I really shouldn't be doing that, but that's the "leftovers"
from my last frustrated attempt to see if anything would jump start this process. I'm guessing that the (I) means "inherited" and yes, I performed this permissions assignment from the high-level folder with inheritance.
Thanks for your interest and questions! Any insights from this?
Jul 18, 2015 03:45 PM|LLahman|LINK
Whoa there! This is interesting! I looked at the permissions results from the command line query that you had me do...
On my test server (that works) here at my office, the only difference (after running this command line against that server) is that the BUILTIN\Users was also set at (I)(F) instead of (I)(RX). I changed the new virtual server to the same setting for users,
re-booted, and tried it again...successfully. It worked fine.
Now for the whole host of questions, Peter (or anyone else out there who's reading this):
(1) Why did changing the permissions for the generic system users make this work?
(2) Because I had to set the generic users permissions to full (as well as the other permissions to full also), does that mean that I have some other setting that is fundamentally wrong to induce this behavior?
(3) If there is a better way to do this without having to use (F) permissions, can anyone tell me the details of how I should approach this? I'm afraid I'm still more of a developer than a server administrator, so you may have to be very explicit in giving
me a plan. I'm not stupid and I've been doing this a long time, but we're right out there on the edge for me personally.
Peter, thanks so far, but I really am concerned about all these permissions being set at full to get this to work and am hoping there is a good plan described somewhere to accomplish this.
Jul 24, 2015 05:57 AM|Pengzhen Song - MSFT|LINK
For about permission issue, I suggest that you can use Process monitor to troubleshooting and grant the permission issue.