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
Related
I have two Access database linked together on my desktop, in the same folder, but I keep getting the message:
"(some random path that isn't even on my PC) is not a valid path. Make sure that the path is spelled correctly and that you are connected to the server on which the file resides."
I've tried using this line of code in VBA... DoCmd.DeleteObject acTable, "Table". I've also used the Link Table Manager process and same issue.
It just deletes the link, then when I reconnect the link to the correct database, it shows the same message again. I've been at this for 2 days and could really use some help please.
A lot of these issues came up after i set a password on the database I'm linked to. I've since removed the password, but still get asked to enter it every time I open up the database it's linked to.
I never solved the source of the problem, but did find a work around solution. I had to create a new database, import the queries, forms, modules, etc... one at a time, then re-link all of the tables. No more ghost link issues.
I am building an application that connects to a mysql database. I set up the data connections and data source (data set) and have begun working on development, going back and forth between adding tables and views to the database and adding forms and components to the application.
I have up to now used the "Configure Data Source with Wizard" wizard to refresh the dataset in the application. Sometimes it takes a couple click throughs to get it to fully load the changes, but that's not the end of the world.
Today, without me knowingly changing anything, when I click on the wizard button, the frame of the wizard opens and closes instantly.
My data is accessible, and the parts of the application already developed work just fine, but I don't know how to add new tables and views to my project. My worry is that something went screwy in one of the auto generated dbDataSet.* files.
I'm happy to provide more information if that will help.
To answer my own question for whomever comes here next:
I came across this solution:
https://stackoverflow.com/a/4749044/7640114
It links to a microsoft.com page that is no longer available, but copies the relevant information. Finding the corresponding files is not hard, but knowing what the wrong Provider is may not be so simple.
Mostly because of a lack of patience, I just went with the second option and deleted the entire folder, which may have been overkill. It worked, and I have access to the wizard again and can continue development, but it also wiped out my workspace layout which I now have to rebuild from my memory.
Win some/loose some. In the end, I suggest being more delicate and removing lines of code from DefaultView.SEView first, and then moving on to trying to delete the file and the folder if nessasary.
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 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.
I'm working on a MS Access database. I've made some changes to one of the modules. I want to go out for lunch, but when I try closing the database, I get the following message:
"You do not have exclusive access to the database. Your design changes cannot be saved at this time. Do you want to close without saving your changes?"
I'm pretty sure nobody else on the network has the database file open, and I don't have any other Access databases open. I'm probably missing something obvious, but would really appreciated some help!
Update:
In the end I copied all the code, closed the database without saving, re-opened it and pasted the code back in. I was then able to save the database. I'm not sure if this was a one off, but I'll report back if it happens again.
If you're sure no one else is in the db but you, it's an additional connection to your db from your own pc. You can verify this with the LDB viewer, downloadable in the free JetUtils.exe download from Microsoft:
http://support.microsoft.com/kb/176670
Look through your code and check if you have two separate database objects in the default workspace or another database object in a separate workspace. That will cause this problem.
To fix it, make sure the database objects are set to nothing before they go out of scope, and if you opened the database object in code, you also need to close it before setting the database object to nothing.
=============================================
Update in August 2022:
The MS link above no longer works. The document remains available on Archive.org, but is outdated. A document that appears to provide the current version of its information is at:
https://learn.microsoft.com/en-us/office/troubleshoot/access/determine-who-is-logged-on-to-database
This provides VBA code for a sub to obtain a list of users. The writer of this update has tested that code successfully in Access 2019.
If you close the database and are sure nobody else has it opened, check to see if there is a .ldb file (it will have the same name as your database file). If the file is there, then there is a good chance it is still in use.
Is it being access by a service, like a website?
You could copy the database to another sub-directory and make your changes. If that doesn't work, I will have to look that up. Of course there is always the database tool, "repair and compress database..."
Is the file located on a file server? If so check to see if any users have a file handle to it.
If it still doesn't work, update your post with your new information and we'll go further.
UPDATE (9/26):
Another thing I do when having strange issues with access databases with contain vba code is decompile. I don't know if this is documented yet, I haven't looked in years, but it's was (at least) an undocumented switch to msaccess.
From a cmd line:
change directory to where msaccess.exe is located.
Run the following command
msaccess \path to access file\databasefile.mdb /decompile
usually runs very quick then opens the database. Open any module and compile.
Doesn't always work, but sometimes can remove strange happenings.
Did you ever trying to copy the database to another directory and making your edits? That should of worked; you could then rename the original and copy the file back.
Anyway, I am glad you are working again.
If even a word mail merge is linked to the access database, that counts as an access connection.
Very simple.
Close all of your MSaccess files.
Open task manager (by right click on task bar).
Select Processes tab in that.
If the list has a msaccess*32 process close that by clicking on End Process.
This worked for me. I think it closes all the recordset which we have not closed in the codes or which is closed forcefully.