I have an access database that sits on server x iis is running on server y. One of my web pages access data from the access database. If someone has the access database open say a end user on our network the web pages fail with a ...already opened exclusively by another user error message.
I created a local access database and used linked tables in order to access the tables that way. Even still I get the already opened exclusively by another user error. If I go through windows explorer and browse out to server x and open the database I can without issue. So my question is how can I simulate the same type of connectivity to the database without the error being thrown is it a matter of permissions to the access database or something within my connectionstring that would allow me to access the database.
Since it throws the error during my connection.open command I am figuring it is either permission related or something additional I need to add to my connection string. I have granted full control for the IIS AppPool\ on the local directory in which my local instance of the access database resides in but didn't seem to make a difference.
My connection string looks like:
Private Shared connSheriff As New OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=\\serverx\directory\Access\MyDatabase.mdb;Jet OLEDB:Database Password=property;")
There are some options within the mdb that change how the database is opened by default, these should be your first port of call particularly setting the "default open mode" to "shared".
You've already split the database (data tables in the shared back-end, linked tables and the rest in the front-end). Make sure that each user uses a separate copy of the front-end mdb, otherwise you'll get locking issues on this.
There is a command line switch (/excl) that sets exclusive mode, but you just omit this to open the db shared so I doubt this is a problem.
You probably already know this but the "Shared" modifier has nothing to do with sharing between applications or users, but shares the connection variable between instances of your class (the c# equivalent is "static")
Related
First and Foremost, I know zip, zilch, nada, about VBA, access, and Advantage database Server.
I have a PC in one location that can connect and update with an Access 2010 file where every drive is mapped, e.g. \file\whatever
The advantage streamlinesql odbc dsn's were setup as such \file\whatever foxpro
Now, the PC has been moved to a new location (the company moved) and there is a vpn connection between the two locations (the data server is still located in the old location and cannot be moved), and so the new map would look like this: \xxx.xxx.xxx.xxx\file\whatever
However, Access cannot connect so that it can run its process and update the files it needs to.
I do not know the actual code to place here to help with fixing this, so answering this question with more is fine with me.
I can say that the vpn is built with sonic wall.
The first thing I would try is to connect with ARC32 (The ADS query tool), since you can then rule out ODBC and Access as the problem.
ADS has three connection types:
local
remote
internet
When you directly connect to an Advantage Database Server via TCP/IP, you want the remote connection type.
The connection type can usually be set via the ads.ini file, which also must contain the IP address and port for the ADS server:
[SETTINGS]
ADS_SERVER_TYPE=2
[MYDATABASE]
LAN_IP=10.20.1.20
LAN_PORT=6262
For more info about ADS.ini see the official documentation:
http://devzone.advantagedatabase.com/dz/webhelp/Advantage12/master_ads_ini_file_support.htm
When you try connection over ODBC maybe a complete reference of the connection options would be useful, I have written them down here:
https://stackoverflow.com/a/33544131/426242
I am developing an ASP classic website that connects to a MS Access database and display data at real time (I know MS Access is not the best option for this purpose, but my company uses it for everything, so I just decide to use it for now). When the MS database is on my hard disk drive (C:), it works fine. But when I move the database to one of the network locations, such as U:\tracking, it gives me this error:
Microsoft JET Database Engine error '80004005'
The Microsoft Jet database engine cannot open the file 'U:\tracking\database.mdb'. It is already opened exclusively by another user, or you need permission to view its data.
I know it is probably due to the security permission (read and write) about creating temporary files (.ldb) for MS Access database. I reset the security permission on the U:\tracking folder, which contains the database, but it did not work. I even gave full control to every account listed in the "Group and user names" session, but the error was still there.
I also checked my Authentication setting in my IIS manager. The only enabled setting is Anonymous Authentication, and I use Application pool identity at this point. If I use specific user, I may add it to the above permission list and give it the appropriate permission, but I cannot guarantee it is appropriate. Any ideas about what I should do to connect to the database on the network location? Any help would be appreciated!
Following is the simple code I use to connect to the database:
Dim dbCon
Set dbCon = Server.CreateObject("ADODB.Connection")
dbCon.Provider = "Microsoft.Jet.OLEDB.4.0"
dbCon.Open = "U:\tracking\database.mdb"
Consider using the ASO connection string parameter as this W3Schools page indicates.
<%
set conn=Server.CreateObject("ADODB.Connection")
conn.ConnectionString="Provider=Microsoft.Jet.OLEDB.4.0"
conn.open server.mappath("database.mdb")
conn.close
%>
Also, path names do not need to be explicitly defined if server map targets the root directory. This is especially true since backslashes prove problematic for web URLs that use forward slashes.
I'm trying to get my Classic ASP application (works great on Server 2003/IIS 6) working on IIS 7.
I've done a zillion things recommended and finally got it actually pulling up the ASP front page that reads from a database.
But when I try to write to the database, I get errors. "Microsoft JET Database Engine error '80004005' Operation must use an updateable query."
Note: In the application pool for this classic ASP site I created an identity of "app_pool_casemodo" and then gave [website folders], [database folder], windows\temp, inetpub\temp, and windows\serviceprofiles\networkservice\AppData\Local\Temp all modify permissions for that user.
I installed Microsoft's Process Monitor and it is telling me there is an issue with a user account "app_pool_casemodo" having sufficient read/write permissions in relation with this registry key: HKLM\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines. So I used regedit and browsed to that key and made sure that account had plenty of permissions.
Tried using DSN and tried using just file pointing ODBC string and both exhibit read but no write issue.
Image of process monitor screen attached.
Please help. I've been banging my head for many days on this stuff. Feeling like I'm super close to a solution.
The user IUSR_< MACHINENAME > has permission over the access file?
I'm trying to connect to an Access database file using a System.Data.OleDb.OleDbConnection. I need to connect in readonly mode because another application uses it at the same time. I can connect to the database in read/write no problem but can't seem to find anywhere the correct string for readonly.
I've tried:
Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Persist Security Info=False;Mode=Read
Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Persist Security Info=False;Extended Properties="ReadOnly=true;"
Thanks.
EDIT:
(I should have put more information in the original question.)
I could connect successfully to the access database when it was on the local machine, but when I tried connecting to the access database on a remote machine with the connection string
Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Persist Security Info=False;Mode=Read
I would get the following error:
System.Data.OleDb.OleDbException (0x80004005): The Microsoft Office Access database engine cannot open or write to the file '{0}'. It is already opened exclusively by another user, or you need permission to view and write its data.
My application is running in a windows service under the local system account.
I think that has to be handled either by user permissions that the DB admin would control, or with different cursor types for your recordsets, which you would control. I don't think the connection string specifies access mode, it just gets you there. ;)
The real problem is that Excel leaves the connection open until the file is closed.
In Excel 2007+, the MaintainConnection setting is set to true by default. You need to go into the vb editor and use code to turn it to false. I haven't seen a way to do this through the visual interface.
Even if you set the connection string to readonly, it will lock an access database (from my experience).
For a pivottable connection:
Sheets("sheet1").PivotTables("pivottable1").PivotCache.MaintainConnection = False
For QueryTable:
Range("A2").Select
Selection.ListObject.QueryTable.MaintainConnection = False
Selection.ListObject.QueryTable.Refresh BackgroundQuery:=False
By setting it to false, the table will connect, run the command, then disconnect, releasing the lock.
I want to perform JDBC SQL queries on a MDE Access file.
I've set up the data source ODBC and everything worked well for a MDE file.
Now, I'm working with a newer version of the MDE file, and here is the result:
java.sql.SQLException: [Microsoft][Driver ODBC Microsoft Access]
Cannont read record. Read authorization unavailable for "tbl_mytable".
If I open the MDE with Access Runtime I am asked for a password, and after leaving a blank password I can see all the data. Of course, "tbl_mytable" does exist inside the database.
I assume that you did not make the MDE yourself. As David said, there is no advantage to convert a MDB database to MDE if it is just going to be used as a database file and not an application.
Anyway, it looks like some group security was put in place on the new version of the MDE database you are using.
You need to check with the person who created the original database if they set up security so they can give you the proper username and password needed to access it again.
Once you get the username/password, you can either change your ODBC data source settings or the connection string you are currently using, usually by adding a "UID=username;PWD=password;" to it.