I have an access database split which has two different types of users. One base of users creates tables/queries on their local front-end. When they get a new version of the front end they lose those tables/queries.
I want to establish a process for retaining/transferring them to the new front end. Has anyone done this before?
So I'm thinking something like this:
Before the front-end on the local machine gets replaced, compare the tables/queries against the network copy. Any tables/queries found should be exported/imported into the new version.
Any direction or guidance would be greatly appreciated.
This is a very strange situation but this is what I would do, as long as all they are adding is tables/queries and not forms/reports/vba code.
These users can have their own Access file that they create their "personal" tables/queries and then link them to their copy of the front end. When you push a new front end all they have to do it re-link everything from their personal access file to their front end.
You can start the file by copying their current front end and deleting all forms/reports/modules but leave all tables (linked and local) and queries. Then delete these additions from their front end and link them from the copy. Train them to add new items to that copy and linking them instead of just adding them to the front end file.
Essentially give each of these users and additional data/back end file that is personal to them.
Related
Generally you can copy a file even though it is being used and paste it into a different location.
However, I am unable to copy an MS Access file when it is being used, I get an error that the file is being used by another process. Is there any way to copy an MS Access file that is being used?
Access files are shared database files.
That means, multiple users can write to and read from the same file at the same time, and Access has locks to prevent users writing things that other users are actively writing to, to prevent conflicts.
When a user starts writing, for example, by adding a row, but hasn't finished writing yet, it might leave the database in an inconsistent state (with half a row). This is a bit of a simplification, but with users actively using a database, corruption is certainly possible. It especially happens when Access needs to move stuff around, which happens when files are substantially extended (by adding tables, for example).
Other applications generally don't have multiple users working on a single file together, so can just write the data when someone saves/closes a file.
See this for some code that copies an open database file while not risking inconsistency.
Shadow copies can of course be used too, but you may very well end up with a corrupt copy.
You certainly can copy an open database file right away, but it has to be opened as shared.
However, if you open it exclusively, it cannot be copied, because Access locks the file.
You can rather split the database into the back end and front end
Give each user a copy of the front end
Then you can always copy your own copy of the front end and back end anytime
If you have any forms open that have a record source linked to a table, this will not allow the copy/paste
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.
Is there any workaround people are aware of to edit Access forms while the database is in use by someone else on the network?
Solved(?): Think I figured this out. I guess I didn't fully understand how a split database worked yet. I'm going to split the database, hide the backend in my own folder. The front end will be on the share drive for anyone to use. I can make as many copies of the front end as I want, as they'll all be linked to the tables in the backend location. I can edit the structure of the front end whenver I want and just replace the one in the share drive for people to access.
You are going to want to create a split end database. That way you can work on your copy while others are still able to use the database. You can find information about it in the following link: https://support.office.com/en-gb/article/Split-an-Access-database-3015ad18-a3a1-4e9c-a7f3-51b1d73498cc
If you already have a split database than simply just work on your own master copy and send out the updated version to whomever will be using it.
So here is the gig, I have this inventory access database that I am trying to seperate the form logic from the database itself; having the database on the server while the form is distributed to users.
I know how to seperate the database to a "front end" and a "back end" but my question becomes " is that all I need to do? Send the users the front end with the form and call it done?"
How do I ensure the database can still talk to all instances of the form?
Help, or at least a point in the right direction, would be great! Been trying to figure this out for the past week.
Based on your question "How do I ensure the database can still talk to all instances of the form?" it seems to me that you fundamentally don't understand how Access/Jet/ACE works.
The database (back end) doesn't do any "talking" -- it's just a file. Each user's PC does all the data manipulation, and as long as the linked tables in each user's front end has the right connect string, it will load the data from the shared file on the file server.
It's all "pull" -- no "push" as there's no server process running on the server to send anything back to the users.
See the "Splitting your app into a front end and back end Tips" page for more info. See the free, for basic use, Auto FE Updater utility to make the distribution of new FEs relatively painless
That is basically it. You will probably need some code to check the linked back-end tables and re-link them if any are missing. I like to keep a small set-up table that lists the expected tables and location and a start-up form. The start-up form checks a few things and either loads the menu form, if all is well, or a form to find the back-end database is all is not well.
I have created an Access file with forms and report and put it in a shared drive with full access rights. But when one user open the Access file, another user can not open the file. He clicks on the file, but no response comes... while I, at the server, am able to open it at anytime.
I am stuck. This Project is for all the users, all of them need to access the mdb file at the same time. How could it be done.
I have a lot of hope. Hope you guys help me out.
Thanks in advance.
Use the database splitter wizard to split your database into separate front end and back end components. Your forms and reports should remain in the front end. And the back end should contain only tables, indexes, and relationships. In the front end, your "tables" will actually be links to the back end tables.
Then use Tony Toews' Auto FE Updater (http://www.autofeupdater.com/) so that each user will work from their own copy of the front end database.
The approach that you're using now ... allowing multiple users to directly open the same mdb stored on a network share ... is asking for trouble. In addition to the problem you're seeing now, that approach dramatically increases the risk of database corruption. Don't do that!
Maybe one of your users is now opening the file in Exclusive mode?