Access unable to save backup or make .accde

[Petrol]

In recent weeks Access 365 (and I believe earlier versions) has become unable in certain circumstances to create a backup (File>Save As>Back up database>Save As) or create a .accde file (File>Save As>Make ACCDE>Save As). The symptoms vary depending on whether the FE has a password or not, and whether you are making a backup or a compiled version, but most of them usually end up with "file already in use".
A Google search leads to the following article from Microsoft Docs: "Unable to create an MDE, ACCDE, or ADE database" error with a database that you can't compile, dated 14 February 2022, which says the problem can be caused by either an error in VBA code or "There is a reference to an Access database (.mdb/.accdb) or an Access project (.adp)." The solution to the latter case they say is simply to remove all references to an accdb file from your VBA, or convert such files to .accde files.

Does anybody know how we can find out whether Microsoft plan to fix this problem? The above article doesn't seem to acknowledge it as a new bug, although it was only recently introduced. In my case, at least, it is a serious problem; my F/E can reference any one of 9 different departmental back ends (all .accdb), and compiling them all would be a hassle and seriously inconvenience the various users. Also, the code to access them has well over a dozen references to the .accdb back ends, so changing them all is fraught with difficulty. I can't see anything in the published specs to suggest that an Access database should not reference its own back end.

Alternatively, is there any feasible way to identify and back out the update which caused the problem, and would this mean I am stuck with no more updates forever? I'm running Microsoft 365 under Windows 11.

[NeoPa]

Hi Petrol.

I can't help much here but I did give feedback to the article referenced and explained that expecting the developer to be in control of external databases that are necessary within the project, and which would be necessary in order to follow their instructions to get around their error, is not a reasonable expectation.

The up & down thumb icons are how you can give the feedback. Negative feedback without a clear explanation are of negligible help as I'm sure you understand.

Good luck.

[Petrol]

Thanks, Ade. I had not noticed the up and down thumb icons. For us in Australia, at least, it now seems impossible to contact Microsoft with a question or bug report. Their Australian phone number, which used to have an option to get to a real person, now just tells you to use support.microsoft.com and then hangs up. Support.microsoft.com very generously asks "How can we help you?" but then issues a list of other problems and their solutions, not including the one I am concerned about. Unlike most other software suppliers, I can see no "Contact Support" option. Do MVPs have any better access path?

[NeoPa]

Yes we do. Not that I can share any contact details of course. That wouldn't be appropriate.

Nevertheless, I have flagged this up to a bunch of other MVPs & former MVPs (alumni) so let's see what we can get for you in the coming days.

[NeoPa]

Hi Petrol.

One of my MVP friends has pointed out what may be a misconception in your explanation. When you talk about referencing back ends that doesn't really make sense. References are to libraries for code. Databases can contain code and, if so they, and their code, can be used by other FE databases. Back ends are databases where data is stored. Do you have back ends or reference databases with code? The linked article from Microsoft is only relevant if you have referenced databases.

[TheSmileyCoder]

I think this is related to a recent bug.
Try to check for updates (even if it says fully updated)

If that doesn’t work, try to place the file in a trusted location

[NeoPa]

Hi Petrol.

The earlier post was from a much respected MVP alumnus Tom Wickerath. He goes on to say :

Tom Wickerath:
I think he is confusing the term [checked] reference in the VBA Editor with a link (“reference”) to a BE database.
And, you generally never compile a BE database in order to create a *.accde or *.mde BE database:.

I’m adding that, because I realized I generally have Allen Browne’s code in my JET BE databases to accomplish things generally only done in BE databases. This includes disallowing ZLS, setting Unicode Compression for text and memo fields (I still have trouble using “short text” and “long text”), disabling Name Autocorrect (although I do this in the FE as well), and setting all Subdatasheets = None. And, it should go without saying that in order for that code to run, you need to compile the code.

[NeoPa]

Hi Petrol.

Another MVP (current) replied to say :

MVP:
I will also add that I have seen this oddity on occasion over the past quite a few years. Have your poster also double check that he does not have any breakpoints checked in his code. He can from the VBA – IDE window use Debug – Clear All Breakpoints. That has sometimes been what did it for me in the past. I also advise doing a decompile, followed by a recompile, prior to building the .accde.

De-compiling can be accomplished using instructions found at How to Decompile an Access Application Or How to do a Full Fresh Compile - originally posted by another MVP friend who has also posted advice in here already TheSmileyCoder.

[isladogs]

Another cause of this is when you have empty procedures in your code i.e. nothing between the header and footer lines.
Recent versions of Access should delete such procedures automatically to prevent the issue

[Petrol]

First of all, my apologies for the long delay in acknowledging the above posts. I was under the impression I would get emails from Bytes whenever there was a post in this string, but I don't. I have checked in my Options that it is subscribed, and my email address (suggested for me, I believe, by the owner of Bytes) is correct and works. But I don't get emails. To complicate matters, I live in Brisbane and was flooded out two weeks ago and had to be evacuated to temporary accommodation, so life has been a bit complex recently and I was relying on getting email notifications if anything was posted.

Anyway, enough of that; thank you all for your helpful comments.

I may have used the wrong term when I said "reference a back end". Maybe I should have said "access a back end". The Microsoft Docs article I mentioned says "if there is a reference to an Access database (.mdb/.accdb) ...".

Essentially what I have is VBA code which does things like
* change from one back end to another by changing the connect string and executing a RefreshLink,
or by building a BE filename from scratch and executing RefreshLink
* create a backup of the current BE by executing a fso.copyfile
* Look at Dir(FileName, 2) to see whether a specified BE exists
All these use a text string containing the .accdb filename, but perhaps they don't "reference" the back ends in the technical sense. All the backends (about 9 of them, for different users of the FE) are .accdb files but contain tables only, no code.

When I make a backup of the FE by File>Save As>Back Up Database>Save As, until about two months ago it simply made the backup. Now it displays
Not a valid password.
I enter the FE PW and it opens the Save As window to conform the destination filename and type, then when I click Save it displays
Could not use [destinationbackup filename]; file already in use.

(However, it does make the backup.)

When I try to create a compiled version for release by using File>Save As>Make ACCDE>Save As, it opens the Save As window as before, suggesting the correct .accde filename, and when I click Save it immediately displays
Could not use [source .accdb filename]; file already in use
and then
Microsoft Access was unable to create the .accde, .mde or .ade file
... and sure enough, it doesn't. This means I am now unable to release any further system updates into production :(.

In terms of the suggestions offered above,
* I have always decompiled and recompiled before release. It compiles with no errors.
* The FE is in a trusted location
* I tried Clear break points as suggested, but it made no difference
* I don't believe there are any empty procedures
* I am using Access 365 with auto-update, and have manually checked for updates.

[Petrol]

Hi all. I am back again ... we were flooded out in late February and had to evacuate my home for 6 weeks, so I am only just back on deck.
Unfortunately, my faint hope that the Access problem which is the subject of this post might have gone away was not realised, but I have done some further experiments.
1. I have backups of my .accdb source code for years back. "Save As" (both "Back Up Database" and "Make ACCDE") on these old versions fails with the problem described in this post. Last year these versions were saved and compiled many times, but now they fail in exactly the same way as my latest version. So I conclude the problem is not in my VBA or any other part of my database.
2. I have had this problem since January. Obviously it is not affecting the entire Access world or it would have been fixed by now. So I gave the .accdb source to a colleague and asked him to compile it, which he did without problems.
3. Since it's not a bug in Access 365 and it's not a bug in my source code or database objects, this led me to conclude that my copy of Access must be corrupt. So I tried first repairing it, and when that didn't work, completely uninstalled Microsoft 365, rebooted, and reinstalled it. The problem is still there.
4 In desperation I have run Registry cleanup programs, but that didn't help either.

I appreciate that obviously nobody in the Bytes community has an answer to this problem, but can anyone suggest where I might turn for help next? All maintenance and development of this project is stalled, and I am unable to support my users :(.

[isladogs]

Sorry to hear of your problems with flooding. Having been through that myself I know how difficult it can be.

Do you have an older version of Access you can install in order to eliminate other possible factors as being responsible for this issue

[Petrol]

That's an interesting idea. I do have an old Office 2013 disk. I guess I'll have to uninstall 365 again to try it, but I'll give it a go.

[isladogs]

Depending on bitness, you may not need to uninstall 365 before installing 2013.
For more details, see my article: Install Multiple Office Versions

[Petrol]

Hmm, no on second thoughts I can't install 2013 ... my current computer doesn't have a disk drive, and I can't find anywhere to download Access 2013 or 2016 full version.
Where else might I be able to find help, since Microsoft themselves don't seem to be interested in helping people ...

[zmbd]

late to the party... is OP's database pre-Office365?
I've had several issues where the older databases, if they open, will mis-behave

[Petrol]

Well it was originally written in Access2013, but it's been running happily in 365 for some years now.

[zmbd]

I just had a couple of my older databases break with a recent update... not exactly the same issue you're having, just the general MS365 hates older versions.
What I had to do was create a new, blank front-end, disable the auto-rename, and then reimport everything over to the new front-end, no passwords to begin with, compile everything in VBA and then add the passwords.
From there everything seems to be working again... maybe... I'll hear about it shortly of it continues to fail.

[Petrol]

(Groan) Thank you.

[Petrol]

I think this can now be put in the UNSOLVED drawer, and none-the-less closed.
I was away from the project for another month, and during that time did not touch Access at all.
Now I find the problem mysteriously gone away. I'm sure it's nothing I have done (because I haven't done anything!), but I can now make backups and accde's.
Thanks everybody for your thoughts.

[NeoPa]

Hi Petrol.

I can say that, while I recall the details of very few, I'm aware of a number of issues that have got into the use of Access in recent months, and that these have been reported and looked at closely by the Access Team. How much of the details they share is down to them but I suspect you may find some details if you look hard enough.

Do bear in mind, though it may not be of too great interest to you when you only care about things continuing to work reliably, that Access has to work within a Windows infrastructure that is also changed on a regular basis so not all Access problems are results of changes made to the product itself (though some are of course).

I can state with conviction, from my personal awareness, that issues are noticed by MVPs and reported very promptly. Most are working closely with various Access projects on an ongoing basis, but they also have their fingers very much on the pulse from monitoring and helping in various forum sites around the web so very rarely do issues come up without their being brought to the attention of the Access Team itself in very short shrift.

The A-Team itself - as we tend to refer to them - also monitor many many sources of information so are often aware even before they are informed by any of us. The chances are that this particular issue has been identified & resolved in the time between then & now.

Lastly, I will add that when a new issue does arise, what is very often extremely helpful to them to allow them to diagnose quickly, is a (generally sanitised first) copy of a database where the issue can reliably be reproduced.

I hope that helps your understanding of why, sometimes, issues just magically go away. A great deal is going on that we don't get to see.

[Petrol]

Thank you so much, Ade, for your thoughtful and informative post. It goes a long way towards helping me understand a possible explanation for what was to me a totally baffling experience. It also helps to allay the lurking fear in the back of my mind that one day the gremlin would re-appear!

Many years ago, when I worked on software for large main frame computers, the manufacturers used to publish bug reports and, in due course, their resolutions. I do wish the shadowy A-team would come out of the woodwork and do likewise. But I guess corporate policies, these days, are driven by different parameters.

Thanks again for your help on this and numerous other issues over the years.

[NeoPa]

There are resources out there my friend, and the A-Team do share what they can about what they find. As I say, before they can comment very helpfully on a bug they have to identify it precisely - and by that time they generally have a fix out or ready - so people aren't looking for it any more. Of course the release cadence can complicate that.

Here's a link (MS Access Bugs) I can point you to that will generally be a good place to look if you think you've found a new bug. Daniel at DevHut is known for keeping on top of exactly what goes wrong where and when. Not the only one to be fair, but the first one I think of - possibly after Karl Donaubauer - and apologies for any other MVPs who keep similar logs that I may have overlooked.

NB. While it is not generally allowed to post links to other sites due to the leeching effect that may have - it is specifically allowed to post links to sites managed by the creator of the software, as well as Microsoft MVPs in the case of Microsoft software such as MS Access.

[Petrol]

Thank you once again!

[NeoPa]

Hi Petrol.

It's my pleasure to help. You may also be interested to hear how just posting this very thread has also helped, and continues to help, so many people out there - most of whom don't even need to become a member here in order to benefit. As I look now the number of Views is approaching 24,000. That compares healthily with many Article threads and some other old threads that get a lot of traffic even many years later. Considering this was only posted mid February 2022 (Not a great time globally.) that's quite extraordinary.

[Petrol]

!! :-)