I have an access application that displays data from our database and does some operations on that data. My problem is that I did not create this app, and when I try to add command buttons to a form, those buttons are not visible when deployed. Any idea what might cause this?
To summarize: I add a button with VBA behind it, it works, but when I copy the App to another computer and run it, all of my changes are not visible.
Any suggestions would be greatly appreciated.
I've had an issue where I was using a short cut to launch the Access application. However, when I replaced the MDB, I deleted the original MDB. This only put it in the trash. The shortcut automatically updated to point at the file in the trash. It worked that way for weeks until I found it (under similar circumstances).
Try emptying your trash. And/Or double check the shortcut.
Related
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.
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 am in a pickle! I was attempting to relink my tables to my frontend, but accidentally missed one. That one table is important for my startup form, and since it is missing, the database just opens straight to the welcome screen.
If I can access the vba, I could change the on open event, or if I could change the start-up form, but I can't get to either of those options. What can I do to get this fixed so I can get back to development?
I've tried holding the shift key, still nothing. Can't get the list of tables that are in there. And the access options > current database features are disabled.
Thanks so much!
Figured it out! WOO-HOO. Instead of holding down the shift key, I held down 'F11'. This brought up a message saying that the table was not there, when I clicked okay, I was then able to press 'F11' again, that opened the Navigation Panel. I had access to the VBA and to the ribbon, and so I was able to just go add the linked table that was missing, and it solved my problem.
I was real nervous about losing 3 hours of work. I backed it up this morning, but I guess I need to do it more often. Thanks for the suggestions!
The database that I am working on (in MS-Access XP) seems to have become corrupted somehow. It no longer supports any events - clicks, change, update events, nothing seems to work. This is the error that I get:
The expression On Change you entered as the event property setting produced the following error: Object or class does not support the set of events.
What can I do to make events start working again? I have tried Tools->Database Utilities->Compact and Repair Database..., but it didn't help at all. Also, it hasn't been like this the whole time - events were originally working, but now nothing works, not even the auto-generated command buttons.
Compact and repair generally won't solve problems that happens in objects other than tables and indexes. Importing usually fixes those but maybe try a decompile and then an import. Decompile or how to reduce Microsoft Access MDB/MDE size and decrease start-up times
I encountered the same problem once and documented my trouble shooting steps here. The expression On Click you entered ...
Also see Corrupt Objects within a Corrupt Microsoft Access MDB
Long discussion summarized.
One page that might have a solution that might help is Errors using multiple versions of Access under Vista/Windows 7 This is basically a permissions problem into the registry.
Another suggestion is to to repair the Office 2003 installation in control panel. A2003 then reverts to using Version 11 of the library, but only until A2007 is used again, then the problem reappears.
The original poster stated "Okay, after a few restarts, it seems that removing the 2007 runtime did fix the problem for me. "
Tony alluded to this in his long string of comments, but this sounds exactly like the dueling Access registration problem. I hadn't used A2007 until recently (I had the runtime installed to test if a database developed in A2003 could be deployed under it -- it could -- but hadn't used it since that testing was completely), and when I run A2007 after I've been using A2003, it has to reconfigure itself. The other day, something went wrong during the A2003 reconfiguration (after having last run A2007) and I got errors similar to yours. Running A2007 (to re-register everything as A2007) and then running A2003 (to re-register everything as A2003) fixed the problem.
The key is that when the re-registration fails, Access doesn't necessarily know it the next time it runs, so you end up running in an environment that is partly registered for A2003 and partly for A2007. The way to restore it is to run the other version of Access. That is, if A2003 is launching without the reconfiguration notice, then close it down and run A2007 so it reconfigures itself and re-registers itself as the real Access. Then when you run A2003 next, it will re-register itself as the authoritative version of Access and your A2003 app should have all of its references in proper shape.
Yes, this is very annoying.
And time-consuming.
I don't know why MS seems to think this is something that doesn't need to be fixed. While I know they don't give a rat's ass about developers who need to run A2003 and A2007 side by side, there are plenty of end users who might have an A2007 runtime app installed but also have A2003 installed as part of their base Office installation.
This has been going on forever, so I doubt it will ever be fixed.
I have encountered the same problems many times in Access 2013. From a page on MS web site, I found the answer which solved my problem. I am sharing it here.
I copied the code safely somewhere else outside Access, in the Notepad++.
Then I deleted entire vent Procedure, with its code, which was not firing.
Created fresh Event procedure, and restored the code from Notepad++ to the newly created Event Procedure.
The event earlier not firing started without any glitch. The issue got solved.
I don't know why the problem appears. This problem has come up many times and every time it is resolved with the same solution.
Try it.
Try to decompile and recompile the database.
If that does not work, I usually create a new database and import everything from this one to the new one. If something is corrupted, I will encounter issues at that time and be able to fix it.
Can you see the code in your code modules? If so, cut and paste it somewhere safe. Then flip the HasModule setting for each form to false, repair the database, and restore the code to newly created code modules.
You decompile the database by adding the flag /decompile to the start-up options i.e.
msaccess.exe “C:\my_folder\mydb.mdb” /decompile
I find that solves most of my problems. If not then another one is to re-secure the database by running the security wizard. This basically makes a new db and imports all the objects for you
I had a similar problem. When it started I created a new version of the code by copying the database. This did not help. However, deleting the form from the new database and importing it from the original solved the issue. I did not receive any warnings of corrupted code or other. It simply just worked without any changes to the VBA etc. Bit weird all in all
I compacted the database (Access 2010) into a new one. No joy. Deleted the form that was not working and imported it from the old database. No joy. Recompiled. JOY! Not sure why it quit and why it now works. I suspect a problem with a large amount of text in a linked text box on the form.
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.