After applying the quality update for the latest channel (preview version) of Microsoft Access (64-bit), version 2408 (build 17928.20066) dated 8/14, the MSACCESS.EXE process won't end even after closing Microsoft Access application. The reproduction steps are as follows: Create a form named Form1. On Form1, create a command button named Command1. In the Click event of Command1, write "Application.Quit". Run the application, click Command1 on Form1 to close the application. Afterward, when you check the Task Manager, MSACCESS.EXE process won't end. This issue does not occur in the 32-bit version. I believe this is a bug. Can you advise where I should report this? Rolling back to version 2407 resolved this issue.

Hi, > I'm having the same issue... > When I try to go back to the previous build,... For our reports to Microsoft we always need the version and build number where people see the problem and if possible a version and build number where they don't see it. Servus Karl **************** Access Forever News DevCon Access-Entwickler-Konferenz AEK - 19./20.10. Nürnberg

Sorry. I'm on build 16.0.17928.20066. Trying to go back to 16.0.17830.20166, but the update process gets broken by this config: <Configuration> <Updates Enabled="TRUE" TargetVersion="16.0.17830.20166" /> </Configuration>

I had to go back to 16.0.17726.20126 to solve the problem. The two interim updates, 17830.20166 and 17830.20138, both cause an error in the update module, so I assume they have been removed for the server somehow.

Hi, > I'm on build 16.0.17928.20066. > Trying to go back to 16.0.17830.20166, but the update process gets broken by this config Have you taken into account that these are two different update channels? The first one is in Current Channel Preview, The other one is in Current Channel . I'm not sure if this works without switching to the according channel. I personally do not use a config file but have (for testing) Added a button to change the update channel, as Peter describes here in point 2 . I first change the channel there if necessary. After that I pull the desired build via the command line, as Peter describes here in method 1 . Servus Karl **************** Access Forever News DevCon Access-Entwickler-Konferenz AEK - 19./20.10. Nürnberg

hi, yes, I returned from holiday today to find most of my databases would crash very soon after opening them. I suspect it is related. I would receive a "too many databases open" message. ?DAO .Workspaces(0).Databases.Count would return several hundred databases open, instead of just 1. This also prevented the database from closing as mentioned in original comment. I believe the issue maybe caused by garbage collection of Currentdb, not closing connections when destroyed. Possibly introduced after recent fix to Linked Tables ? The issue must have been introduced very recently anyway, my version was 2408, build 17928.20114 I rolled back to the July 9th build (Current channel : 16.0.17726.20160) and that fixed it for me.

After updating Access in Office 365 to version 2408, the MSACCESS.EXE process remains after exiting Access.

Anonymous

After applying the quality update for the latest channel (preview version) of Microsoft Access (64-bit), version 2408 (build 17928.20066) dated 8/14, the MSACCESS.EXE process won't end even after closing Microsoft Access application.

The reproduction steps are as follows:

Create a form named Form1.
On Form1, create a command button named Command1.
In the Click event of Command1, write "Application.Quit".

Run the application, click Command1 on Form1 to close the application. Afterward, when you check the Task Manager, MSACCESS.EXE process won't end.

This issue does not occur in the 32-bit version. I believe this is a bug. Can you advise where I should report this?

Rolling back to version 2407 resolved this issue.

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments

97 answers

Anonymous

2024-08-23T18:03:23+00:00

Hi,

> I'm having the same issue...
> When I try to go back to the previous build,...

For our reports to Microsoft we always need the version and build number where people see the problem and if possible a version and build number where they don't see it.

Servus
Karl
****************
Access Forever News DevCon
Access-Entwickler-Konferenz AEK - 19./20.10. Nürnberg
Was this answer helpful?

0 comments No comments
Anonymous

2024-08-23T18:12:53+00:00
Sorry. I'm on build 16.0.17928.20066.

Trying to go back to 16.0.17830.20166, but the update process gets broken by this config:

<Configuration>
```
&lt;Updates Enabled="TRUE" TargetVersion="16.0.17830.20166" /&gt; 
```
</Configuration>
Was this answer helpful?

0 comments No comments
Anonymous

2024-08-23T18:52:35+00:00

I had to go back to 16.0.17726.20126 to solve the problem. The two interim updates, 17830.20166 and 17830.20138, both cause an error in the update module, so I assume they have been removed for the server somehow.
Was this answer helpful?

0 comments No comments
Anonymous

2024-08-23T19:02:23+00:00
Hi,

> I'm on build 16.0.17928.20066.
> Trying to go back to 16.0.17830.20166, but the update process gets broken by this config

Have you taken into account that these are two different update channels? The first one is in Current Channel Preview, The other one is in Current Channel. I'm not sure if this works without switching to the according channel.

I personally do not use a config file but have (for testing)
1. Added a button to change the update channel, as Peter describes here in point 2. I first change the channel there if necessary.
2. After that I pull the desired build via the command line, as Peter describes here in method 1.
Servus
Karl
****************
Access Forever News DevCon
Access-Entwickler-Konferenz AEK - 19./20.10. Nürnberg
Was this answer helpful?

0 comments No comments
Anonymous

2024-08-27T14:22:18+00:00

hi, yes, I returned from holiday today to find most of my databases would crash very soon after opening them. I suspect it is related.

I would receive a "too many databases open" message.

?DAO .Workspaces(0).Databases.Count

would return several hundred databases open, instead of just 1.

This also prevented the database from closing as mentioned in original comment.

I believe the issue maybe caused by garbage collection of Currentdb, not closing connections when destroyed. Possibly introduced after recent fix to Linked Tables ?

The issue must have been introduced very recently anyway, my version was 2408, build 17928.20114

I rolled back to the July 9th build (Current channel : 16.0.17726.20160) and that fixed it for me.
Was this answer helpful?

6 people found this answer helpful.

0 comments No comments