Hello

Please let me applogize for what could technically be described as a cross post. This issue was posted in the begginer area yesturday:

http://p2p.wrox.com/topic.asp?TOPIC_ID=72331

I do beleive its a more complex issue and should be here. Aditionly the problem chnage slightly as a reult of a registry permissions change to the ODBC area.

History:
I have new XP pro machine. While getting everything up an running all of my sites using Access which were previously runing fine are now giving me the following error on the connection string line:

Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][ODBC Microsoft Access Driver]General error Unable to open registry key 'Temporary (volatile) Jet DSN for process 0xb9c Thread 0xe48 DBC 0x1164024 Jet'

Please note all the connections strings in all the sites run fine everywhere else (in the public domain, my old XP Pro machine and my Win 2000 old machine) excpet for my new machine. The connection string is:

Conn.Open "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Server.MapPath("/DB/em.mdb") & ";"

After assistance from very helpful memeber (Old Pendant) the following article:

http://support.microsoft.com/kb/295297

lead me to allow full permissions in the following area of the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\ODBC

Which now gives me the following area for all sites:

Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][ODBC Microsoft Access 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.

Permissions for everyone, IUSR, [logged on user account] have been set to full in everyarea i can think of including temp directorys, the .mbd its self and the dir which it resides in.

I am really very stuck here. I spent hours trying to find a solution yesterday however all advice has been carried out, checked and double checked. Has anybody seen this before? What can I do or do you suggest I do? I havnt seen 'Mr ASP' around the classic ASP area of the forum in some time - Imar your opinion would be very helpful and as always very much appriciated indeed - Along with all the other members of course.

Sorry about the long post - TYVMIA.


Wind is your friend
Matt
www.elitemarquees.com.au

__________________
Wind is your friend
Matt

From my experience, 80004005 errors are almost always related to security errors: http://Imar.Spaanjaars.Com/QuickDocId.aspx?quickdoc=263

Try this:

1. Make IUSR and IWAM accounts member of the Administrators group

2. Reboot

3. Try again.

If it works, remove them from the group Administrators again, and try to find out where the problem lies (did you check temp folders like C:\Temp and C:\Windows\Temp)?

Imar


---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of Beginning ASP.NET 3.5 : in C# and VB, ASP.NET 2.0 Instant Results and Dreamweaver MX 2004
Want to be my colleague? Then check out this post.

Hi Imar - nice to see you again. As always your time is like its weight in gold, all fixed!!!!

After looking at your very informative quick doc, the IUSR was the IIS account being used. As you suggest above making this user a part of the Administrator group and rebooting fixed the issue. Note - I didnt need to make the IWAM part of the group also.

This problem was very strange, had no logic to it and it shouldnt be neccessary to make this user part of the admin group given the other permission alterations I carried out. mmmm very weird indeed.

To answer your other question - yes full permissions were given to both of the Temp dir locations.

Have a fine day Imar :o) For others having this issue make sure you read:

http://p2p.wrox.com/topic.asp?TOPIC_ID=72331

To get a full understanding of what steps were taken to fix things. Thanks also to Old Pendant and his time and effort in the above post.

Wind is your friend
Matt
www.elitemarquees.com.au

But this is a DANGEROUS solution!

It means that your ASP pages will, in general, have WAY more "permissions" than they should have.

If you, yourself, tightly control all your ASP pages/code, then it's probably okay. But if not, you could be asking for other kinds of trouble.

Note that IMAR suggested that, if that worked, you should then *remove* IUSR_xxx from the Admin group and try to find the "real" problem.

Now, I do hear you saying "but that *is* the real problem." So if you don't have tight control of your ASP site, I don't know if there *is* any good solution!

yes its not a safe solution in a production environment however this issue is on my local working machine. The sites that are hosted work without issue.

I still dont understand why this step was neccesary given all the other permission alterations I made. I am asuming all would agree to add the IUSR to the admin group should never be needed? So my new local machine is an odd ball without logical reason....Im just glad these sites are now running - Thankyou again and have a fine day :o)

Wind is your friend
Matt
www.elitemarquees.com.au

Yes, you're correct. You never need to give administrative rights to the IUSR account on a production server.

IMO, it would be better to remove the account from the Admin group again and find the real cause. However, if it's a development machine, it doesn't matter much as the risk is probably quite low (then again: a nice buggy for each loop using the FileSystemObject can easily erase your entire hard drive.... ;) )

Imar


---------------------------------------
Imar Spaanjaars
http://Imar.Spaanjaars.Com
Everyone is unique, except for me.
Author of Beginning ASP.NET 3.5 : in C# and VB, ASP.NET 2.0 Instant Results and Dreamweaver MX 2004
Want to be my colleague? Then check out this post.