We have an access database on a file share that has permissions for everyone in the department to access. The problem i am having is that when multiple users try accessing the database at the same time they are unable to do this. One user can open the database fine but when another user tries to simultaneously, they double click the file icon, get an hour glass for a split second and nothing happens after. We are using Server 2003 as our domain controller. All permissions have been verified on both a domain level and in the access database under tools-options-advanced and setting relevent permissions to shared and no locks. Do you know what could be causing this issue with a "dead link" when user try to open the file simulateneously?
Any help is greatly appreciated.
Thanks.
Ignore the naysayers - Access is perfectly fine for a small number of users. Either you have the default Access settings to open dbs exclusive which will lock out other users or there is some weird network problem.
EDIT
- noticed you already have default shared access
- is record-level locking on?
- also try giving user full control of the shared network folder (Access needs read/write/create/delete to be able to create and delete the ldb file)
This issue occasionally happens to Access databases for almost no apparent reason. Of the suggested responses by Microsoft, you are already doing the second (opening from within Access) but I believe the first provides somewhat of the answer you are looking for.
In the target of the shortcut, include
the path of MSAccess.exe
According to Microsoft Help and Support
When you say share permissions, do the users have full permissions? Full permissions are needed because the share file (.ldb) must be created and deleted.
I am just recently experiencing the same issues, only one person can open the database. We only have 3 people accessing the same database through shorcuts on our desktop.
Now according to Microsoft we need to include the database path in our shortcut, I will tried that. They acknowledge this problem.
MS Access is not worth the trouble in a multi-user setup.
Your time is better spent converting the database over to a server-based RDBMS such as SQL server while you still have hair.
Believe me, you will have to do it sooner or later anyway! Sorry for the bad news.
Related
I have a database that I have created for a friend of a mine that he would like to store his data and work directly from on a daily basis. Recently I came across ExcelforMySQL and thought this would be a perfect AddIn for him to use.
I have successfully linked the AddIn to the database (Xampp Local connection) and this loads up fine but when I move the database onto a webserver that I have with ionos(1and1) and enter the Host Details along with the Username and Password, I get the following error:
Connection attempt failed.
Unable to connect to any of the specified MySQL hosts.
When I click Show Details:
All it says is One or more errors occurred.
Would really appreciate it, if somebody could advise on how to fix this, as I really want to be able to work live on the data and update the changes from the user directly in Excel if possible and this addin looks like it does that.
If anyone has any other suggestions then I am happy to hear them as not fussed as what is used as long as it works.
Thanks
I had a similar problem to yourself with a number of my own sites/DB's hosted on Ionos. After a bit of searching through their help they state that access from outside your Ionos package is not possible. Unfortunately we're stuck with their hosted version of PHP My Admin in the control panel.
Although I have found that MySQL-front works great and bypasses the Ionos restrictions. Google is your friend...
Maybe a bit late for you but for others who come across this question as I said google is your friend...
I have been working on a submission form for two of our employees' to enter tax data. It is an InfoPath 2010 form, which is connecting to an Access 2010 accdb. The purpose of the form is to pull related data from two source tables (one from the old dB that was used, and the other from APX which houses additional information) to prefill as many fields as possible. Everything works fine when running it from my computer, or directly off our server. The problem I am running into now, is that our two users have access to the files, can open them with InfoPath Filler, but upon opening, they get the "InfoPath cannot connect to the data source...". The funny thing is, is that last week, they were able to connect and submit data with no problem (then one day I came back from lunch and it no longer worked). How I had to originally set them up was to create a certificate, make the forms full trust, added both user ID's as being able to have read write access. When I run the form from my desktop it works without a hitch. I even tried remapping to a mdb to see if it was a version issue. The dB is stored on a shared domain, \testdomain\, for arguments sake. Then they access the form via the same directory. Just to note, SharePoint is not connected in any way. All the searches I have done have yielded no solutions. I am thinking it is a networking issue, and have a meeting with the network admin in a few hours. But, what I can't figure out, is how it worked before, and not now. Does anyone have any suggestions or thoughts on what could be causing this? Just to clarify, I can run the same xsn form they run, from the same server location, without having the issue they do. I truly appreciate anything anyone might be able to offer!
Ok, finally figured out what was causing the problem (totally feel dumb). Apparently the servers used randomly get backed up, and when they do, the permissions get overwritten. If anyone else runs into this, review the access permissions for the directory and all the files. Thanks Nathan for your advice!
I'm creating an Access 2010 database and would like some clarification when it comes to concurrency and security. What I would like is upon starting the app only a menu form to be displayed with several buttons including a login button. Most buttons would be disabled until after the user logs in at which point based on their permission group; Viewer(Deafault), Worker, Editor, Admin.
Also, Admin should be the only one to be able to see the access database while the others are restricted to seeing the forms only.
I was just testing the default concurrency implementation but saving my database to a shared network and having myself and a co-worker try to access it. Found out if one accessed the database it locked it from others, and if we both tried at the same time it became read-only.
So I'm just looking for tips on how to start this.
For an Access database all users must have as a minimum read, write and modify permissions on the folder in which the database resides. This is because MS Access creates a lock file and if the second user does not have permissions to modify the lock file, the cannot get access to the database. Delete permissions may also be useful, to remove the lockfile when they are the last person out.
I maintain an ms-access application splitted to frontend and backend files.
The frontend file is in the users conputers.
The backend file is in a shared folder in the server.
What is the lowest permissions required?
can I give some of the users only read-only permissions in that folder? (or hide it from them in some other way) but still enable them to view the data?
How should I give the best security to the data file and to the folder containing it?
Unfortunately, the lock file (ldb) must be created, updated and deleted. If a user with insufficient permissions opens the database, it will be locked for all other users, therefore all your users need Read/Write/Delete permissions on the back-end.
EDIT #1
The lock file must be created every time the database is opened, this includes via linked tables, and deleted when the database is closed. If a lock file exits and the database is closed, it indicates a problem has occurred. You will also run into problems with compact and repair if it is run with insufficient permissions.
Edit #2
Security for Access is quite a large subject and depends to a great extent on your environment and requirements, for the back-end, it ranges from a database password, which is tissue thin, but quite suitable for most offices, to Access security, which can be complicated and has been dropped in 2007. Here is a link http://support.microsoft.com/kb/207793 for a download for the Microsoft Access Security FAQ for versions < 2007.
Information on security for 2007 can be found here http://www.microsoft.com/technet/security/guidance/clientsecurity/2007office/default.mspx.
Many have suggested that you must give FULL permissions to users, but this is not true. You need only give them MODIFY permissions -- you can deny them DELETE permission, which is a good idea, as it prohibits the users from "accidentally" deleting your data file.
It is true that for a user with DELETE permissions, the LDB file will be deleted on exit when that user is the last user exiting the database. But it is not required that the LDB file be deleted -- indeed, in Access 2 and before, the LDB files were not deleted on exit, but just left there hanging around. This generally has no downside, but occasionally the LDB file gets corrupted and causes problems and really does need to be deleted and recreated afresh.
What I do is have two classes of database users (as defined in custom NT security groups specific to my Access application(s)) -- DBAdmins and everyone else. The DBAdmins have FULL permissions, everybody else only CHANGE. The result is that any time a DBAdmin exits as the final user, the LDB is deleted. This setup works really well, and I've been using it for well over a decade.
Using a hidden share for your back end is really only "security by obscurity," and not really worth the effort. Sophisticated users can figure it out through any number of methods (depending on how you've locked down your front end):
view the MSysObjects table and find
the CONNECT string for the tables,
which will identify the hidden
share.
examine the results of
CurrentDB.TableDefs("name of linked
table").Connect in the immediate window in
the VBE
Now, if you've properly secured your app using Jet user-level security (and it's very easy to think you've secured your database and find out that there are holes, simply because it's really easy to forget some of the crucial steps in the process), they won't be able to do this, but even if you have, Jet ULS security is crackable (it's pretty easy to Google it and find cracking software), so is not really something you should depend on 100%.
Yes - it resolves down to file access permissions as well as read/write. You can't execute any type of data update stuff (you'll get "operation requires an updateable query") unless the user supplies credentials that allow them to write, or you allow write on the file.
Running a query requires only read access.
From the documentation, I would expect adModeShareDenyWrite to be the way, but it's not working right.
I'm using an Access database via ADO. My connection string says Mode=8, which is adModeShareDenyWrite. But when I try to delete a row from a table, I get:
Unspecified error, Description:Could not delete from specified tables., Source:Microsoft JET Database Engine
In other words, the setting is preventing ME from updating the database using my OWN connection.
I found a couple other posts on the web reporting the same thing, the adModeShareDenyWrite setting used with Access not working as documented.
I am looking for a solution that doesn't involve an administrator changing permissions. It needs to be something that my program can control.
My motivation here is to minimize the chances of database corruption. One of the causes of mdb file corruption documented by Microsoft is two apps writing to the same db. So, I want to make sure that only one app can have a write connection to the db. Others can read, but should fail when they try to write. Whoever makes a connection first wins.
Cory Trager wrote:
My motivation here is to minimize the
chances of database corruption. One of
the causes of mdb file corruption
documented by Microsoft is two apps
writing to the same db. So, I want to
make sure that only one app can have a
write connection to the db. Others can
read, but should fail when they try to
write. Whoever makes a connection
first wins.
Why are you worrying about it? Jet is by default a multi-user database engine. If somebody else is updating a table, the data pages involved will be locked as read-only (in the state they were before the write began).
There is no realistic reason to fear corruption from mere multi-user interaction. Corruption of Jet databases usually happens because of dropped connections or an interruption of the connection during a write (such as users who force quit an app that is not responding as fast as they want).
I think your fear of corruption is misplaced.
On the other hand, you should still be able to open with an exclusive lock, and I'm not sure why it's not working. Have you considered using DAO instead of ADO to manipulate Jet data? Given that it's the native data interface (instead of a generic interface layer), it ought to be easier.
One solution is to give them access to a copy of the database. They can change whatever they want, but it won't keep past your copying it over with the master.
I suppose you access here an MDB file from a client interface, whatever it is, and others can also connect to the same file at the same time. When you use adModeShareDenyWrite in your connection mode, it means that you can still share the data with others (no locks of any kind on tables or records in the MDB file) but it can't be modified (this is why you get an error).
One solution would be to manage your connection parameters, with something like that:
(where you have a user object with a '.role' property, or anything equivalent ...)
if activeUser.role = "admin" then
m_connectionMode = adModeWrite
else
m_connectionMode = adModeShareDenyWrite
endif
Then you can open your ADO connection with the parameter m_connectionMode. Administrators will be given the right to insert/update/delete while other users will ony be able to view the data. This means you have somewhere in your program, or ideally in a table, some data saying who is what in your application.
EDIT: Following multiples comments with Corey:
You won't be able to do what you want to do in a straight way. My proposal: when the app accesses the database, it checks for a special file in the .mdb folder (whatever the file is).
If this file exists, the app opens a "read-only" connection.
If this file does not exist, the app creates the file (you can create one for example with "transferDatabase") and open a read-write connection. Once you quit the app, destroy the file.
If you have multiple users connecting to an access database across a network you might want to consider upgrading to SqlServer instead of using Access.
Corey Trager wrote:
I am looking for a solution that
doesn't involve an administrator
changing permissions. It needs to be
something that my program can control.
Well, if the problem is due to NTFS permissions being read-only for the user, there isn't a thing you can do to make the MDB writable. You don't specify where the MDB is stored, on a server or on a local hard drive, but in either case, for a user to have WRITE permissions on the MDB, NTFS permissions have to be set to allow it (for a share on a server, it has to be allowed both on the SHARE and on the underlying file). If it's a local file, the best solution is to make sure that you're storing the file in a location in which user-level logons have full WRITE permission. This would be anywhere in the user profile, and just about nowhere else.
That said, I'm not really suggesting that this is the source of your problem (I really can't say one way or the other), just pointing out that if it is the cause, then there's not a damned thing you can do programmatically to work around it.