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.
Related
I'm facing a strange issue in MS Access (2016). When I split my database into a frontend and a backend, and encrypt the backend, my frontend fails to open.
As I open my frontend after splitting the database and encrypting the backend, I should see linked tables, which should not open until I relink them by entering the encryption password. Instead, I'm always taken to Access's 'file open' menu (Image), as if the frontend never existed! As soon as I decrypt the backend, the frontend starts working normally, displaying the linked tables.
I tried splitting another database downloaded off the internet, and the issue did not occur. So I've singled the issue down to my database file. But I don't have a development background, so I have no idea how to fix it, or what could be going wrong.
There is some VBA code in the database, which is mostly copied off the internet. I tried searching for a similar issue, but with no luck :(.
Please help!
The database files (FE, BE and unsplit) can be downloaded here.
I just fiddled around and I think I found the answer to solve this issue.
If you have used the code to block the bypass shift key and mouse click to get access to your backend database then the following steps will work for you to fix this issue.
Go to your unsplit database and and go to table view. Then click on All Access Objects Section above the tables and click on option NAVIGATION OPTIONS then tick the boxes "Show hidden objevts " and "Show System Objects"
Now go back to your table list and try to find your hidden table that holds the code to block shift bypass key, in my case my table is cold "UsysRibbons" and then you have to delete it.
Then split your database and you will be able to open your front end database even if your back end database is relocated to other folder.
But if you still want to retain block shift bypass key functionality you have to go to your unsplit database copy this "UsysRibbons" table that holds the code to block shift bypass code and paste it to only to your split back end database don't link it to your split front end, and then everything will work as usual.
If this is not the issue why you can't enter your front end when back end is relocated to other folder then you have to look at all of those hidden system tables try to delete them one by one to figure out which table is the parasite table that causes problem.
Good luck to everyone in the future who encounters the same issue.
Thanks
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.
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 an access database on a server. it is split up into front end and back end.
people are accessing the database's front end using a shortcut from their desktop computers.
i know for a fact that multiple people are using it at the same time.
for some reason, when i created a shortcut on my computer to access the front end of this database, i can open the file no problem, but if i try to view any tables or forms i am getting:
could not use .....file; file already in use
what does this mean?
I'm unsure what your error message means specifically. I don't understand why Access would open the database file without complaint, but then spit an error when you attempt to view forms or tables. I've never encountered that situation.
However, in a general sense, I think it means you should give each user their own copy of the FE database file ... instead of allowing everyone to directly open the same FE file on a network share.
Use Tony Toews' free Auto FE Updater to manage the distribution of the FE files to your users. Then you can replace the existing desktop shortcuts with a shortcut to Tony's utility. It's a slick way to ensure all the user's have the latest version of your FE, and by giving them their own copy avoids the problems inherent in allowing everyone to directly open the very same FE database file.
Also, read this page from Tony for more detailed information: Splitting your Microsoft Access MDB into a front end and back end - Why?
Edit: Perhaps the error message is because a user has the BE database opened exclusively. They wouldn't need to open it in that mode, but when modifying a back end object, like a table design, Access will switch them to exclusive mode. However, if this were the explanation, it seems like everyone except the exclusive user would be getting the same error message as you. Are they?
Problem and about the database: Data from a record in Access 2003 database has disappeared. This database has 1 backend and 3 frontends, multiple users and is hosted on Citrix. Within this database, we have records of all clients served, ranging in the 1000s.
Background info: The form for client data entry is set up with various subforms, including both a "programs enrolled" subform and a "services" subform. A client can be enrolled in multiple programs. Once enrolled in a program, services can be entered for that program area using the services subform. There are multiple fields in the services subform, one of which is a drop-down field allowing you to choose from the programs a client has been enrolled in (the list is updated for that client whenever he is enrolled in a new program).
The problem details: For one specific record and one specific program area, the program has disappeared from the "programs enrolled" subform and all of the related services have disappeared from the "services" subform for a period of 3 months of data entry. However, other programs and services for this record did not disappear.
Questions: Is the disappearance of data a common Access 2003 problem? Are there tests in place that can be run to see if data is disappearing and catch that data? If so, what are they? If there is specific code involved, what is it? What can be done to prevent the disappearing of data (other than using a different database)?
As #HansUp says, this is not a common issue. Two things spring to mind:
Jet/ACE files do not like to be stored on file servers with replicated file systems unless the file is edited on only one side of the replication synch. That is, if two servers have a replicated volume and you have people connecting to both servers and trying to edit both copies of the database, you'll hose the data. If you're editing on only one side, there shouldn't be any issues, but I worry about this kind of thing. Another issue might be virtualization, though I don't have any definite scenario where that could be a problem.
More than 10 years ago I saw an issue that combined the old bookmark bug with On Error Resume Next that caused data to not be saved. What was happening was that turning off error reporting/handling with the On Error Resume Next was not properly going out of scope, and errors that were occuring in the departure from a record via bookmark navigation were never being reported. The result was that edits were lost. When I changed the bookmark navigation to save the record if it was dirty before changing the bookmark pointer, the problem went away. But while I was at it, I eliminated as many On Error Resume Next statements as possible.
Another guise of the second problem would be if DoCmd.SetWarnings is set to False. I never bother with SetWarnings, so it's not an issue, but it's a common novice technique, and worth looking at. The idea is that errors are happening but the report of them is not getting to the users, and thus, the edits are being lost.
I don't consider either of these very likely, but your situation is so uncommon that even unusual things like these are worth looking at.
Is the disappearance of data a common Access 2003 problem?
No. Data in any version of Access does not just disappear without cause. Unless perhaps your database file has been corrupted. More likely you have a design error in your form and/or database schema.
If you have a form/subform based on parent and child tables, make sure you have a relationship established and that you enforce referential integrity on that relationship. That is a standard practice to ensure you can't delete a parent record while you still have at least one related record in the child table.
Based on your description, it's not clear whether the data is missing from your data tables or just not appearing in your subform when you expect to see it. You might want to clarify that point.
At this point, we have determined that the missing data occurs at random and is not traceable to a specific pattern which makes it rather difficult to pinpoint a solution. We are still uncertain if the data actually disappeared or if the user assumed he had entered the data but had not. Unfortunately, our db host does not keep a series of backups that we could trace back to, but rather updates the backup at the end of each day--again raising a problem for tracing the disappearance. We will continue to investigate the various answers provided here and are grateful for your great input and suggestions.