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.
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 was using an Access file a colleague of mine created. They run it without issue on their computer all the time, but when I tried running it on mine, without modifying it, I had a value prompt window come up that isn't supposed to.
I think there's some sort of auto save feature on this file because even after closing it without saving, this message shows up and I'm no longer able to run the macro within the Access file. This file is stored on a shared network drive and file history isn't enabled on this drive nor on my machine. I'm not too familiar with Access and my colleague is on leave for some time. No one else seems to know Access very well either. Is there a way than I can restore the file or the queries/macro inside it to how they were before I opened it?
The basic answer is No. If something really was changed, there is no automatic history that can be used to recover changed settings or macros.
I realize it doesn't help to say anything now, but I am very surprised if there are no backups for the shared network drive. Is there no IT personnel that can assist? Regardless of whether or not you can get the file working, I would immediately make your own manual backup of the Access database file(s). (As long as you have a backup... or even better multiple backups, Access files can simply be restored from the original using file copy and paste.)
"Autosave" is an understatement with Access, because unlike a word processing document or spreadsheet which can be held completely in memory, a database file is constantly updated. There is no in-memory context for the database file as a whole. Access will almost immediately update the file once it is opened, simply because it manages things like file locks, etc. The database may have an Autoexecute macro or other code that runs automatically, but this may be accompanied by security prompts, especially if you haven't opened it on that computer before. For standard forms, changes to data on a form are saved to disk immediately and no "Save" button is required. Certain aspects of the database file should not changed unless explicitly told to do so, and these are usually design aspects not change accidentally.
As a caveat to this question I am a beginner Access 2016 programmer of 2 months, but believe I have some intermediate to relatively advanced knowledge of the software as it's just about all I've been doing at work the last two months. I also realize now that I'm asking for trouble using hyperlinked fields as most people believe they're more hassle than they're worth (at least in older Access versions, it's surprisingly a little difficult to find Access 2016 information and opinions in 2018.. at least for me cause I'm apparently incapable of using "the google machine" properly), but I'm in a little too deep now.
At the moment I am trying to deploy a new database system but have run into some issues when testing. After turning my .accdb file into a .accde file the command to "Edit Hyperlink..." vanishes entirely from the shortcut menu when right-clicking. My employer would really like this functionality to be present in the final product, as he wants to display the file name but link to the file location in a shared network drive. I also need document control at his small company to be able to edit the hyperlinks but don't want them using an .accdb file that they could inadvertently make design changes to, or god knows what.
I have attempted to make a custom shortcut menu using this VBA module, which is executed by an AutoExec Macro, running upon opening the database.
Public Function CreateCustomRightClickMenu()
Const msoBarPopup As Long = 5, msoControlButton As Long = 1
' Create a shortcut menu named "CustomRightClickMenu"
With Application.CommandBars
With .Add(name:="CustomRightClickMenu", Position:=msoBarPopup, MenuBar:=False, Temporary:=True)
' Add cut command
.Controls.Add type:=msoControlButton, id:=21
' Add copy command
.Controls.Add type:=msoControlButton, id:=19
' Add paste command
.Controls.Add type:=msoControlButton, id:=22
' Add hyperlink command.
.Controls.Add type:=msoControlButton, id:=1576
' Add edit hyperlink command.
.Controls.Add type:=msoControlButton, id:=1577
End With
End With
End Function
I can get this function to work just fine in the .accde file, but the "Edit Hyperlink..." command is still unusable - it's greyed out. Is there some way to override this?
The only information I could find as to why this is the case is because a compiled .accde file restricts all design tools. I thought this explanation was rather... lackluster. Editing hyperlinks constitutes as a design tool? How would a hyperlinked field ever be advantageous then, in an automated system? And by automated I mean one that can run freely without a DBA sitting in some back-end file all day and updating the file's address lying beneath the display text. I will be on the opposite end of the country in a month and a half and will not be able to dip my toes in the back-end anymore so to speak.
Additionally, I saw many solutions for this problem in earlier versions of Access, but not in 2016. So my question is, what is it about the 2016 version in particular that is making this so difficult?
Or, can this be done at all?
Alternatively I've thought about using attachments and was assured that they don't bloat your system because Access will compress the files. After testing this I'm relatively sure it's not the case. I attached one 900kb .pdf file to 3 separate records in a database copy, and the .accdb file's size increased ~2700kb, as is to be expected. Compact and Repair had no effect on the final file size (3,974kb). 900kb files weren't realistic for my system though, and if my math is correct I should be able to store about 11,000-13,000 records in a 2GB Access database if I have 3 50kb files per record, subtracting 1000-2000 to account for the space of my access objects. Is this a realistic calculation, and what problems will I run into if I try and go this route?
EDIT: After briefly glancing over this webpage yesterday:
https://codekabinett.com/rdumps.php?Lang=2&targetDoc=access-hyperlink-data-type
I thought about it some more and realized I could just have our Doc control enter hyperlinks in the format "DisplayText#FileFullPathway#" ignoring sub address and scroll tip text.
And so far so good.
Then something interesting happened. I sent out a beta .accde file for DC to play with today, and the Edit Hyperlink... tool was magically available when I was getting her to test something unrelated (yesterday on her same machine the command either wouldn't be there, or if I had the CustomMenu set-up then the command was greyed out). I had deleted my custom menu from the entire database, no VBA module exists for anything menu related and the form's ShortcutMenu property is now blank. You'd think I'd be relieved but this is bothering me even more now - if I didn't enable it who did, and how come it wasn't there yesterday prior to having wasted all this time coming up with a workaround? Maybe I'm supposed to have that menu command and it was just bugged yesterday, but my travels through the Googlesphere yesterday suggest otherwise. This is driving me bonkers. For now my problem is resolved but I'd still like to know what's happening here.
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.
I see Microsoft record locking file remain after i close the database. I run vba from access, if for some reason it gets not responding(while checking some code), then i close it. After that i still see record-locking file remain .
Probably because your code is interacting with a database object. That connection doesn't get closed properly when you close the application mid-execution, so it never clears up the lock file.