I manage an access database that runs on a server and utilizes the split tables and front end option. When i have to make updates i have to get everyone out of the database and this often is difficult. There is always one or two peopl who forget to log off after hours or dont exit when requested. I found a few third party access applications that say they work but i cant find any for access 2010. i guess in access 2010 they changed how user permissions work and this messes up the previous solutions.
Thank You
I haven't tried this approach so I can't validate that it works, but have you seen \ tried this?
http://www.databasejournal.com/features/msaccess/article.php/3548586/Auto-Logout-Users-for-DB-Maintenance.htm
Essentially the idea is you open and hide a form at startup that periodically queries a table in search of the log off flag.
If the flag is not set the form resets its timer and queries again at some regular interval.
If the flag is set the form is displayed with a message to the user that he\she will be logged off in X minutes. When the countdown reaches 0 the form closes the application.
As far as I can tell, the biggest key to this approach is that the flag needs to be set in the back-end database so that all front-end clients see the same data.
Related
I'm fairly new to Access and am struggling with setting a pessimistic Record Locks policy (Edited Record). I have a database that I am developing and have not published yet, so it is not split at the moment but will be in its final form. I have a few tables that will be accessed through forms by multiple users at the same time, and ideally I would want the Record Locks property of these forms to be set as Edited Record on a row basis so that once a user starts editing one record, other users cannot mess with it but can still edit all the other records. I have:
set the relevant forms' Record Locks property as Edited Record
enabled the "Open Databases by using record-level locking" advanced option
read/write permissions to the folder where the database is
..but it is not working correctly. It seems that Access is still locking records at the page level, as I am prevented from simultaneously editing two adjacent or "close" (within 30 rows of each other or so) records.
I even tried creating a brand new database, just one table and two forms (actually one form duplicated with two different names) - result is the same, once I start editing one row of data in one form, all "nearby" rows are locked from editing as well. I tried splitting the database, asked another user to try on his machine together with me, but always the same result. What am I possibly getting wrong?
I have no issue sharing the brand new database I made as a test if needed, not sure where I can upload it though.
Ok, a few things:
Given this is not split? Ok, less things to check.
so, you have this setting:
and for the test form in question, you have this:
Now, we assume you not left out some huge-massive whopper here, right?
First up - we assume no one else, or no other program has this file open.
we assume that you do NOT have ANY startup code at all - but are just launching to that form? Right (if you have startup code - especially ANY code that opens the database or opens a table? ALL BETS ARE OFF!
next up: since this is a single user machine - I would re-boot - just to ensure that no stray copes of Access are running or were left running due to all this testing.
Note that the FORM MUST open the table(s) in question. There is NOT to be ANY code of ANY kind that runs before the Access UI application say via form OPENS that table.
The above is BEYOND important!!!
Why?
Because DAO code, VB code or ANY OTHER PROGRAM or PROCESS that opens the file BEFORE YOUR access applicaton does? Then you not get row locking.
And the above tip ALSO includes ANY VBA + DAO code!!!
You see, the JET (now ACE) row locking feature? There is ONLY one way and ONE WAY ALONE to use this feature:
It ONLY works from the MS-Access UI. That means no VBA code can do this, no vb.net code or ANY OTHER system or code can run before Access UI (forms) opens a single table.
The reason why?
The first person + process WILL determine if the row locking feature is turned on. And I want to double, tripe, quadruple and MORE stress that ONLY the UI can cause the ACE/JET data engine to engage this row locking feature.
In other words:
If on application startup ANY CODE that runs that opens a table (DAO or ADO code) then that code who FIRST opens the database will from that point on force ALL OTHER programs, forms and yes even MS-Access forms to NOT USE row locking. (you get page locking).
So, this is a first in kind of setting.
the FIRST process that causes a table to open will then determine if row locking is to be turned on. And the ONLY POSSBILE WAY for this to occur is if the MS-Access UI opens a table (any table) with a form. You cannot have ANY code run that touches a table BEFORE that UI opens a table. So any kind of say startup code, or even code (rather common) to create a persistent connection will thus ignore the row locking feature.
And if any other outside program, say ODBC from FoxPro, or even code in vb.net, c# etc. opens the database BEFORE the Access UI gets it hands on the table(s)? Then once again, row locking is not used (page locking of course will be used).
So the flip, the flag, the switch to row locking CAN NOT BE set in code. (you can set the options in access via code - but then you get that prompt about having to restart access (and you must do so if you change that row lock feature). So, code can change the setting, but it will NEVER take effect until you re-start. And thus once again, code cannot set this on startup (only change the settings that tells access what to do on startup - and it too late to thus change it in code once code starts running.
So, just keep in mind that you need as the first thing to launch is some form that is bound to a table, and that form will have to run first before any DAO or any other kind of VBA code grabs or opens a table via DAO or ADO code.
If code uses the DAO/ADO object model, then you by-passing the Access UI and thus no means to tell JET/ACE to use row locking. This is a MS-Access feature and NOT a JET/ACE data engine feature. As a result, you have to ensure that it is the Access UI that opens that table. Once that has occurred, then any and all other code, forms and even external ODBC connections will now respect the row locking feature.
Hi i am working on access 2007-2013 application with DSN-less linked, the application is working perfectly, but when i shared it with other users i am getting the following error
Run-time error '3328' table is read-only
i tried to enable the active x component in the application under options then go to trust center, and check [Never show information about blocked content]
also i noticed that when one user open the application the other user get this message
Could not lock file
how can i solve this issue? i know i have to go to do something under options, but what?
thank you
Like #AVG said, you're going to need split architecture.
This has to components:
Back End
This is where all of your tables will be stored. It is just another Access database, without Forms/Queries/Reports/Modules.
Front End
This is where you are going to Link to your Back End, and this WILL contain Forms/Queries/Reports/Modules, and create linked tables as well.
You're going to distribute this Front End to all of your users to solve these concurrency issues you're facing (people are editing records/viewing data and others are trying to write to that table and do other things at the same time, which Access doesn't like).
The Back End needs to be in a location where everyone has access to it.
I think in your question what you're asking for, would be this, but splitting the front end and back end is by far the best route to go. Simply turning off the security checks Access has in place to protect your data isn't advised in the least. It also helps reduce bloat.
For disabling record locks : Click the top left Office Button, Click Options, Click Advances. Select No Locks.
I have a multi-user split access DB with a front end and back end on a network drive. I often need to make structural changes to the back end of the database but the file is always locked due to the frequent use of the file by many users and the fact that nobody seems to be able to close the file when they are finished with it.
When I need to modify the file I have to contact IT to kick everyone out of the file from the server which is a real pain.
I've tried things like coding an auto close timeout on the FE and a few other vba methods but over time there will always be something that causes the FE to hang or something before running the necessary code leaving the BE locked.
Is there any way to get access to the file without needing access to the Server settings?
Unfortunately, no.
Unless you implement a listener on the FE that looks at a flag on the BE and closes the FE when the BE flag is set (it sounds as if you've tried something like that), there is no way to do what you want. You can't even open the BE exclusively unless there are no other users. This is just one of the reasons that Access is not really a preferred multi-user DB solution.
I'm using Microsoft Access as a means of managing data (that used to be stored in spreadsheets) in a more tabular, orderly, and logical manner. Everything seems to be working good for my client, but she has one question: "Is there a mode that allows changes to be reverted? Let's say I've made some changes, and I'd like to revert to my original version, is that possible?"
I understand her concerns and as much as I'd like to say "this is how a database works; you make changes to a row and they are written to the row immediately", I can't bring myself to say it. She's been using MS Excel and Excel has the ability of undoing multiple changes, as well as reverting back to the original file if you haven't saved it. To me, I feel that she is afraid that Access will bring about disastrous consequences--one fine day she's a bit groggy and starts making random changes all over, and then she has no means of getting back the original file. Bam.
What I'm asking now is this: is there any way/setting to allow Access to not commit changes immediately, perhaps until the user has clicked some button or something? It's not the way Access works, and please don't ask me to return to good old Excel because I enjoy and appreciate the chill WYSIWYG interface of Access and its familiar database environment. Maybe just not this behaviour, which came along with the databases.
If you are looking for a simple setting to preserve history, or enable undoing or force all changes to be encapsulated in explicit transactions, then you are out of luck as Access provides none of these out of the box.
There are however ways to implement all of these features to varying degrees, from a simple confirmation whenever the records are about to be changed, to create logs of all changes (so that the user can at least see what changed), to duplicating records before they are modified, etc.
Undoing an action can be something simple, like restoring a value you just typed, but it can become very hairy quickly if you want to undo an action that created or modified a dozen other records elsewhere in the database.
It becomes especially difficult if other actions have been performed after that one (by other users connected to the database for instance).
However, a few of things that could help you:
You can track all changes in a form and keep a log of the actions (in another table or just a text file):
Track all changes made to a record in Microsoft Access
KB197592:How to create an audit trail of record changes in a form
Creating an Audit Log
Add an Audit Trail to your database
you can use Access 2010 data macros to automatically trigger some action (like duplicating a record or keeping track of changes) whenever something is updated or added to the database.
Data Macro similar to triggers
Leveraging Data Macros in Access
you can use all forms in unbound mode and manually set the data when the form opens (or change record) and only save it back to the database when the user is completed.
All of these methods require work and testing and need to be adapted to the experience you wish to provide your user.
Another thing you can do is simply make copies of the database as backups at regular intervals, that way, if something goes awry, you haven't lost everything (this is mandatory anyway, I always have at least a daily backup system).
i have about 20 users who have their own access front end and write to a backend.
i need to do an update to the backend, and every time i try to do it offhours, it seems that someone is still logged on because the file is locked!
how do i get around this? i do tell the users to log off at the end of the day but a lot of them forget! is there a way to force them off?
can i disconnect someone from an access database?
Idle Detect/Inactivity Timeout
How to determine who is logged on to a database by using Microsoft Jet UserRoster in Access
I don't expect any points for my answer as Remou already gave you these. But whenever reasonable I prefer to give pages with links to the official KB articles rather thwn who knows how mangled up code can get in a forum. Including this one.