There are two cases where Access autosaves changes:
When the user enters data into a form, this data is autosaved to the linked table
When the form developer modifies a query, form design view, table definition, etc. these changes are autosaved after exiting the editor
I'd like to know how to change the second point so that Access only saves the file if I hit CTRL+S, similar to Word and Excel.
Though Access does ask if I want to save changes when I exit (for example) the form design view, the only way to test changes is to exit design view, which saves the file and clears the undo button. It can be very inconvenient because I have to undo everything manually if I want to revert changes.
I've found threads discussing older versions of Access, but nothing for Access 2013. Is there a way to do this?
Forms, Reports, and Queries can be tested without saving - just switch view.
Tables cannot. If you wish to check out design changes, first create a backup of the database or at least the table.
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.
We work with a large Access database and we want a few users (max. 5 to 6 at the worst) to be able to edit tables at the same time by using forms. We have split the database into front end and back end. The BE is placed on a NAS and each user has an offline copy of the FE on his own desktop.
All users have full permissions and we switched the options (client settings -> Advanced) to the following settings:
Default open mode: Shared
Default record locking: Edited record
Open databases by using record-level locking: yes
Encryption method: use legacy encryption (good for multi-user databases).
In the forms we also changed the property ‘record locks’ to ‘edited record’.
What we want to achieve is that when a user change a certain record in a form, other users can’t change the same record until the changes of the first user are saved. We also want to see a lock icon in the selector bar, as mentioned in this forum:
Instantly "locking" a record in multi-user Access environment
For the moment we have done several tests, but we are unable to generate any “Writing conflict” when implementing the above, contrary to the numerous reports on the opposite behaviour one can find reported in the internet and the documentation of Access. The first user changes a record and the second user is still able to change it, without any particular notification in the sense of a selector bar icon or a “writing conflict”, and the user that closes the database the latest takes it all (all changes by the first user are overruled).
Can anyone explain me what we are doing wrong.
You have to set the locking on a form by form basis. So changing the client settings to "edited" record will ONLY become the default for new forms you create.
So, to set locking for a form to edited record, you MUST set EACH form you have to Edited record. Once you do this, then additional users attempting to edit the same reocrd will see + receive a lock icon in the selector bar. They only will see this bar WHEN they attempt to start editing, but if you set form to "edited" record, then this should work fine.
The "over all" settings you are playing with don't change anything here (well except the option to open databases as shared - but that's already the default and already a given since more then one user is able to edit the data.
So change the form in question locking setting to "edited" record. You now have record locking setup for that one form. Settings for record locking are a form by form setting - the other settings really don't matter.
When working with an Access .accdb, every time I open the file, I see that the 'date modified' in the filesystem changes to now. This makes me nervous. I want it to stop.
I can't be the only person who has ever saved a working db, and opened it a few weeks or months later to an error. Sure, I probably have backups, and backups to my backups, and table data saved separately from my code, and version history taking up multiple gigabytes of the filesystem or in emails or where ever... but it still makes my heart jump a little whenever I see the date modified update on open, when I haven't touched the DB in some time.
Have I flipped a switch somewhere that makes it do this? Is this expected behavior? How can I stop it?
To replicate this, create a new accdb, save and close. Put something in it, nothing, or close it only a second after creating it. Open an windows explorer for the directory the accdb is saved in, and note the date modified value. Open the file at least a minute after the displayed date modified file. alt-tab back to the explorer window, and you see the date modified has changed.
That's the default behaviour, even with a native Access MDB file. They don't work like a normal file that you have to explicitly modify to update the date - it does some things when you open it up, whether you want it to or not.
Just did a quick test - if you set the database file to read-only, it doesn't update itself.
I construct my MS Access Applications into front end and a back end. The Front end database is made up of all the the application objects like the Queries, Forms, Reports, and Modules. The back end database is made up of the tables and links to other data sources.
Many people consider this a Microsoft Access Generally Accepted Best Practice.
So much so that Microsoft includes a Wizard to do the split for you. Shown here
10 Reasons to Split an Access Database
Once the database has been split, It makes is a whole lot more manageable. The Front End can be marked read-only. The Back End remains writable.
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 split my DB and now when I try to change some information on a few queries, I can't access them. I have a front end and a back end and understand that I should make changes to queries/forms via the front end, but they are grayed out and inaccessible.
At this point, I tried unsplitting the DB (which I believe I did), but I still can't edit those queries or forms.
I can click on the query/form and see the result of it, but I can't get to design view to edit it.
I'm taking a shot in the dark and saying that in the process of splitting your database, you either created your front-end in an accdr or accde format (a runtime application). The purpose of this is that you shouldn't be able to open queries or forms or tables in design view on the front end. You can just open your database and save it again as an accdb file and continue as normal.
If you're having other problems with the linked tables, I suggest you open the Linked Table Manager and refresh the links (if you moved the backend file, this is necessary).
I would recommend trying to proceed as normal by using Shift Bypass just to be sure. ( Hold the shift key when you start the database. Then attempt to modify in design view).
If these fail, I would attempt to copy the queries and /or forms if possible and create new ones.