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.

Kathleen, you can go back to an earlier version of Office. Search the net for "How to revert to an earlier version of Office" and you should encounter a detailed procedure to return office to a previous version. I carried out this process on my version (365) and it worked. My database works smoothly without errors. Best of luck.

I can't go back to a prior version. I can use Task Manager to end Access then manually delete the lock file. But that doesn't solve the other issues including the ERROR - 3408. I'm also unable to run the function to repair and compress the database. So it's just getting larger and larger every time I try to test code arounds. The locking issue is creating as many issues as ERROR - 3408. When are they going to fix this issue?

MS Access 2019 Version 2408 (Build 17928.20114 Click-to-Run) not functioning properly, previous version of 2407 functioned correctly. Behavior started on 8/27/2024. I had another machine with MS Access Version 2019 and 2021 Version 2404 (Build 17531.20152 Click-to-Run) which do not experience the issues. It does the following: Opening the application with the shift key so no code executes on startup and exiting MS Access does not produce an error. Accessing only an internal Access table within the application and exiting MS Access does not produce an error. Opening a linked table in MS Access results in an error. Opening the application in the normal method which accesses a linked table to trigger the login screen to the external database always results in an error. There are two versions of the application. The older uses SQL Server Native Client 11.0 to SQL Server 2019. The newer version uses ODBC Driver 18 for SQL Server to Azure SQL Server. The error observed is on application close the application task terminates in Task Manager and a background task starts for MS Access. The background task never terminates. Unless the background task is manually terminated, MS Access will not restart the application and no error message is thrown. If the application is set to compact on close, once the application terminates, the background task attempting to compress the database throws an error that a user has already locked the application. Additional observations, after opening and "saving as" several queries, MS Access will no longer save the queries and throws no error. Running on Windows 10 Pro Version 1H1 OS build 19043.2364

Hi, We have published a documenting article on AFo with information about the planned fix by Microsoft. Servus Karl **************** Access Forever, News , DevCon Access-Entwickler-Konferenz AEK - 19./20.10. Nürnberg

We've starting having this with several customers this week but it hasn't been consistent. I have the same version on my computer and am unable to reproduce. Could it be related to rights? Trusted? Is there a workaround besides rolling back the update? We would have hundreds of people to adjust so it's not a great option.

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-09-01T19:39:05+00:00

Kathleen,

you can go back to an earlier version of Office.

Search the net for "How to revert to an earlier version of Office" and you should encounter a detailed procedure to return office to a previous version. I carried out this process on my version (365) and it worked. My database works smoothly without errors.

Best of luck.
Was this answer helpful?

0 comments No comments
Anonymous

2024-09-01T19:23:33+00:00

I can't go back to a prior version. I can use Task Manager to end Access then manually delete the lock file. But that doesn't solve the other issues including the ERROR - 3408. I'm also unable to run the function to repair and compress the database. So it's just getting larger and larger every time I try to test code arounds. The locking issue is creating as many issues as ERROR - 3408. When are they going to fix this issue?
Was this answer helpful?

0 comments No comments
Anonymous

2024-08-31T22:31:29+00:00
MS Access 2019 Version 2408 (Build 17928.20114 Click-to-Run) not functioning properly, previous version of 2407 functioned correctly. Behavior started on 8/27/2024. I had another machine with MS Access Version 2019 and 2021 Version 2404 (Build 17531.20152 Click-to-Run) which do not experience the issues.

It does the following:
1. Opening the application with the shift key so no code executes on startup and exiting MS Access does not produce an error. Accessing only an internal Access table within the application and exiting MS Access does not produce an error.
2. Opening a linked table in MS Access results in an error.
3. Opening the application in the normal method which accesses a linked table to trigger the login screen to the external database always results in an error. There are two versions of the application. The older uses SQL Server Native Client 11.0 to SQL Server 2019. The newer version uses ODBC Driver 18 for SQL Server to Azure SQL Server.
4. The error observed is on application close the application task terminates in Task Manager and a background task starts for MS Access. The background task never terminates. Unless the background task is manually terminated, MS Access will not restart the application and no error message is thrown.
5. If the application is set to compact on close, once the application terminates, the background task attempting to compress the database throws an error that a user has already locked the application.
6. Additional observations, after opening and "saving as" several queries, MS Access will no longer save the queries and throws no error.
Running on Windows 10 Pro Version 1H1 OS build 19043.2364
Was this answer helpful?

1 person found this answer helpful.

0 comments No comments
Anonymous

2024-08-31T22:00:37+00:00

Hi,

We have published a documenting article on AFo with information about the planned fix by Microsoft.

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

1 person found this answer helpful.

0 comments No comments
Anonymous

2024-08-31T18:46:49+00:00

We've starting having this with several customers this week but it hasn't been consistent. I have the same version on my computer and am unable to reproduce. Could it be related to rights? Trusted?

Is there a workaround besides rolling back the update? We would have hundreds of people to adjust so it's not a great option.
Was this answer helpful?

0 comments No comments