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.
Related
I have an Access database, split into two. One is the front end with all objects, linked to the other database - containing the tables. Both are in the same folder. Locally, the drive is G:. In our other office in another city, the drive is also G:. However, when a colleague in the other office opens the front end database, he gets an error message that it cannot connect locate the G:\ drive for the linked tables. I think there's a difference in the drive name. I know I can add VBA upon the database opening to change the link to that of the current folder. However, if two people in different offices are using the database at the same time, I think that will cause problems as each user would need a different link. Any suggestions will help!
Thanks,
Jeff
You need to map the tables to the explicit folder path. Or the UNC address. It would start with \servername\folder...
I have done this several times, but, access will run very slowly across large distances and outside of a LAN. I would reccomend importing the table if it is used for reference, and create a copy within the front end. Of course, have the front end located on the users PC for fastest accessibility and response. If you are actively working with records in the table, use a query to add and edit records in the table instead of a bound form. Otherwise everything will slow down.
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.
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 am putting my php /mysql website up and this is my scenario
The users are grouped into sites each site with their own unique database.
There will be about 40 users per site.
the two options I'm trying to decide between are
have a central website running the php and directing the users off to their own database
using sub domains for each user each with their own php in htdocs
I dont even know if 2 is possible/stupid but if it was, would it make any difference to performance as they're all being run by the same server. Any other ideas/ advice much appreciated as I want to organise it the best way from the start
At login, you won't know where to direct them as they haven't identified themselves yet. After login, you can easily customise it for them.
You could create two separate PHP login files, and give different links to each set of users, but a simple clean login page and then a customised front end after login seems the best way.
1 would definitely be the right idea, you only have one copy of the code to worry about and you don't waste disk space on extra copies of the same code.
You could use 1 with wildcard subdomains and use .htaccess to change the subdomain into a posted parameter. That way you get one copy of the script and subdomains all in one go.
One thought, why dont you use a single database with an extra 'accounts' table, this may simplify things!
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?