Server Error In "/application" Application Error When Using Access Database With .net Framework 1.1 By Jason Fortner At Isnare.com Ezine Articles

I had an application that I was working where the client insisted on using an Access database for the application. The application was running on a two node server farm so the Access database had to be located on a seperated machine and accessed over the network. When upgrading the server farm from 2000 to 2003 the client ran into an issue accessing the database.

After checking to make sure it wasn't an error with the connection to the location where the database was held I attempted to put the database underneath the site and connect to it there. Well that connection worked fine and the data could be accessed.

Long story short after some research and some long hours on this I found that the issue was a combination of things. First under IIS 6 all applications are run under application pools. The application pools do not pass the identity along that they run under. This creates a problem when trying to access a remote drive. To solve this issue you can enable impersonation of the account that you had IIS to run as the anonymous user. To do this you need to open the web.config file of your application. Under the and then insert a line that is similar to this:

This line should be used if you wish to impersonate the user as the account that the user is logged in as on their desktop.

” password=””/>

This line should be used if you want to specify one specific account to impersonate.

After I turned on the impersonation in my project another issue appeared. I got the dreded / Application Error. This issue was addressed in Microsoft KB82719 Article. When a .NET application executes it uses the TEMP folder of the ASPNET user, or whatever user you have specified to run your .NET applications, to run and store temporary files. When you run an Access database/application temporary files are opened but since you are impersonating a user that user does not have access to open these files under the ASPNET temp directory. The solution for this is simple, go into the file structure and grant the account access to the temp folder in C:Document settingsServerNameASPNETlocal settings folder. Only give the account access to the Temp folder so that a security risk is not created.

Published At: Isnare Free Articles Directory http://www.isnare.com
Permanent Link: http://www.isnare.com/?aid=25272&ca=Computers+and+Technology

Important Notice DISCLAIMER: All information, content, and data in this article are sole opinions and/or findings of the individual user or organization that registered and submitted this article at Isnare.com without any fee. The article is strictly for educational or entertainment purposes only and should not be used in any way, implemented or applied without consultation from a professional. We at Isnare.com do not, in anyway, contribute or include our own findings, facts and opinions in any articles presented in this site. Publishing this article does not constitute Isnare.com's support or sponsorship for this article. Isnare.com is an article publishing service. Please read our Terms of Service for more information.