locked
reading data from access with a linked table (pointing to a access table on another location in the network) RRS feed

  • Question

  • User1835900635 posted

    Hi,
    Here's a short explanation of my asp.net project.

    1) the default page loads, it will read the Windows Login of the user opening the page.
    2) I'll check if this login exists in a table stored on the webserver. 

    In this Access Database, there's a 2nd linked table, pointing to another access table on a network location.   Now, I want to read
    data from this linked table.  However, at this moment I receive an error:

    "The Microsoft Jet database engine cannot open the file '\\<ip>\<shared-folder>\statistics.mdb'.  It is already opened exclusively by another user, or you need permission to view its data".

     

    Some extra info:
    - The network folder has read and write permissions for everyone

    - the user and group permissions on both access files are set to read/modify/administer for the Admin user (on the tables I want to read from)

    - IIS authentication on the server is set to "Windows Authentication" (this is needed so I can read the Windows Login from the user).  All other authentication modes are disables (like anonymous, ...)

    - When the error occurs, no other program or process has access to the statistics.mdb (so, it can't be locked by someone else)

    - the web.config files access connection string looks like:
    <add name="AccessConnectionString" connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\\<IP>\<shared-folder>\statistics.mdb;User Id=admin; Password=;" />

    Like I said before, in this statistics.mdb file, there are 2 tables.  One normal table, and another linked table (pointing to a network location)


    Searching for solutions, I discovered the following:

    - if I don't use linked tables, everything works fine (however, I have to use this linked table)

    - even if I connect directly to the table in the network I receive the error.  So, I'm pretty sure I don't have sufficient rights to read from this table.

     

    I read that not the Admin user is opening the file, but actually a user called ASP.NET.  This user doesn't have the correct rights to do this.  However, I'm not sure if this is true.

    Can somebody help me with this problem?

    Tuesday, September 7, 2010 10:03 AM

Answers

  • User1867929564 posted

    i) For smooth sailing,what is the problem in keeping both mdb in same system from where your web application run.

    ii) Use DSN

    iii) The default ASPNET user account doesn't have network permissions.
    One solution is to change ASP.NET to run under a different account that has
    the necessary permissions. For testing purposes I suggest having it run
    under your user account since you know you have permission.

    For example, you can add a line similar to this to your web.config file:
    <identity impersonate="true" userName="domain\MyAppUser">
    password="password"/>

    Here's more info on impersonation:
    http://msdn.microsoft.com/library/de...ersonation.asp

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 8, 2010 3:26 AM

All replies

  • User-1199946673 posted

    I read that not the Admin user is opening the file, but actually a user called ASP.NET.  This user doesn't have the correct rights to do this.  However, I'm not sure if this is true
     

    Yes,

    Read this:

    http://www.mikesdotnetting.com/Article/74/Solving-the-Operation-Must-Use-An-Updateable-Query-error

    Tuesday, September 7, 2010 11:46 AM
  • User1835900635 posted

    Hans_v, thanks for the reply but...

    - If I check the account running with "Environment.Username", I receive "POM" (which is the user logged on to a computer, browsing to the website)

    - The folders containing both access files (the original mdb the site is reading from and the linked access file) have full control permissions for "everyone" (and as a test, also for the user "POM")

     

    Wednesday, September 8, 2010 2:36 AM
  • User1867929564 posted

    i) For smooth sailing,what is the problem in keeping both mdb in same system from where your web application run.

    ii) Use DSN

    iii) The default ASPNET user account doesn't have network permissions.
    One solution is to change ASP.NET to run under a different account that has
    the necessary permissions. For testing purposes I suggest having it run
    under your user account since you know you have permission.

    For example, you can add a line similar to this to your web.config file:
    <identity impersonate="true" userName="domain\MyAppUser">
    password="password"/>

    Here's more info on impersonation:
    http://msdn.microsoft.com/library/de...ersonation.asp

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, September 8, 2010 3:26 AM
  • User1835900635 posted

    Hi,

    1) I can't keep both tables in the same mdb file.  One table contains Windows Logins with extra information (like AgentID for a call center).  The other table and mdb (the linked one) is filled by an external appliation (the call center) containing the AgentID and call logs.  With the AgentID from the first table, I would like to receive all the call logs for this agent. 

    I'm not allowed to alter the mdb from the call center, since any changes will be lost when there's a software upgrade.  Even so, I tried it in here for testing purposes, but I receive the same error when I point to a network location in the web.config file

     

    2) I assume you mean use DSN names instead of IP addresses in the web.config file?  I'll do that. 

     

    3) I'll read the info about impersonation and give it a shot...However, if I alter the web.config file like you say - will the ASP.NET page be able to check which Windows User is opening the page?  This is necessary, because this Windows Login is used to find the AgentID

    Wednesday, September 8, 2010 3:37 AM
  • User1835900635 posted

    Edit: Great! Seems it's working with the impersonation tag...I'll do some more testing!

    (sorry for the reply instead of edit - the post didn't seem to work...)

     

    anyway, thanks for the quick replies and help

    Wednesday, September 8, 2010 4:40 AM