Feb 02 2022 01:36 AM
Since yesterday I noticed that in all my Access databases there is a problem when I close them.
When I close a database, it leaves a background process that can only be terminated in Task Manager. Without this, it is not possible to (re)open databases!
I have already checked some possible causes. It also concerns databases that I have not changed at all in recent months and that worked fine until this week. Therefore, I have to assume that it is a bug in an automatic update!
It seems that it has to do with a malfunction in the deallocation of allocated memory in VBA source code.
Did anyone experience the same problem? Are there already fixes or solutions available?
Feb 05 2022 02:49 PM
@Florian1290 I applied the trusted locations recommended workaround and I am still getting the 3048 error on a app that has been running for years and no updates in the last 6 months.
Feb 05 2022 03:44 PM
Hi,
Can you tell more details?
Are you sure you did the trusted location thing completely?
If the Trusted Location doesn't work, your other option is to roll back to an earlier Office build,
that doesn't have the bug (usually 14729.20260).
Servus
Karl
************
Access News
Access DevCon
Feb 05 2022 08:05 PM
Adding my database files to the Trusted Location (though successful) did NOT solve my problem with Microsoft Access failing to close completely when I exit Microsoft Access. Also, .ldb files remain undeleted. I must use Task Manager to shutdown Access, then manually delete the stuck .ldb files, and only then will my database restart and run "normally for a while" before glitches reoccur, and I just go through all of these steps again. Yes I did check "allow network folders". This all started for me on-or-about February 2, 2022. I am using Microsoft Office 2016 and 2019 on three machines. All three machines are affected in exactly the same way.
Thank you for your contribution to this forum.
Feb 06 2022 04:57 AM
try to save the database in mde
Feb 06 2022 05:56 AM
Feb 06 2022 06:20 AM
Feb 06 2022 07:37 AM - edited Feb 06 2022 07:42 AM
If by now you don't know, the solution is simple: add the folders where the front and backend are located to Trusted Locations. AND You have to do it for every single user in your network, a step I missed doing the first time and the other two users kept having the problem.
Feb 06 2022 08:48 AM
Feb 06 2022 09:28 AM
Feb 06 2022 05:06 PM
@lease forward instructions on how to revert to previous Office 365 version. Thanks.
Feb 06 2022 05:13 PM
The links to the articles have been provided over and over in this and other threads here. A quick search will turn up what you are looking for.
Feb 07 2022 12:23 AM
Feb 07 2022 12:29 AM
Feb 07 2022 03:14 AM - edited Feb 07 2022 03:21 AM
Hi,
When I post in international forums I usually remove the language part (it-it/, en-us/ etc.) from these Microsoft links. Then everyone gets the article in their browser language (or the US English original if there is no translation). The language of the page title in the link does not matter, only the Id is relevant:
However, sometimes the original US English version is more up-to-date than the translated versions or better than a (sometimes) machine-translated version.
Servus
Karl
************
Access News
Access DevCon
Feb 07 2022 07:46 AM
Feb 07 2022 08:07 AM
We are running Access runtime only for automated reports. The option for Trust Center does not exist so I added it to the registry. This didn't work. I also went to an earlier version but the Click-to-Run automatically updated the runtime again to the latest version with the bug. You cannot disable Click-to-Run. If you stop or disable it you cannot run any Access or Office program. I have waited for the auto update "fix" and it hasn't happened. Any suggestions? Does anyone know when the fix is supposed to be pushed out?
Feb 07 2022 08:24 AM
Feb 07 2022 10:03 AM - edited Feb 07 2022 11:23 AM
Suggested workaround worked on Friday, not today. Only known "change" was a PC restart. Likely something else changed too, don't know. Tried removing and re-adding trusted locations, has not helped. Also don't know if we have AMSI enabled, have question in with IT.
UPDATE - Restarted PC, workaround again seems to be working. Makes very little sense to me.
Feb 07 2022 10:06 AM - edited Feb 07 2022 11:56 AM
Function addTrustedLocation(strFolder As String, strLocationDescription As String, blnAllowSubFolders As Boolean, strOfficeApp As String, strOfficeVersion As String) As Boolean
'(developed july 2019 by Gert De Wilde)
addTrustedLocation = False
Const HKEY_CURRENT_USER = &H80000001
Dim strParentKey As String, intLocCounter As Long, objRegistry As Object, varChildKey, arrChildKeys
Dim strNewKey As String, tmpValue As String, keyAvailable As Boolean, lngStep As Long
On Error GoTo Hdl
lngStep = 10
tmpValue = ""
Select Case strOfficeApp
Case "Word"
'strParentKey = "Software\Microsoft\Office\14.0\Word\Security\Trusted Locations"
strParentKey = "Software\Microsoft\Office\" & strOfficeVersion & "\Word\Security\Trusted Locations"
Case "Excel"
'strParentKey = "Software\Microsoft\Office\14.0\Excel\Security\Trusted Locations"
strParentKey = "Software\Microsoft\Office\" & strOfficeVersion & "\Excel\Security\Trusted Locations"
Case "Access"
'strParentKey = "Software\Microsoft\Office\14.0\Access\Security\Trusted Locations"
strParentKey = "Software\Microsoft\Office\" & strOfficeVersion & "\Access\Security\Trusted Locations"
Case Else
'MsgBox("The application you specified is not covered by this procedure", , "Trusted location definition")
Exit Function
End Select
intLocCounter = 0
lngStep = 15
'objRegistry = GetObject("winmgmts:\\.\root\default:StdRegProv")
Set objRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv") '10jul19
lngStep = 20
Call objRegistry.EnumKey(HKEY_CURRENT_USER, strParentKey, arrChildKeys)
lngStep = 25
If Not isArray(arrChildKeys) Then
'the Trusted Location folder does not exist and needs to be created
' if only Acces Runtime is available, then the 'Trusted Locations' node does not yet exist
'so create this node (will not cause error if already available) and one childkey
'just to assure a childkey collection
Call objRegistry.CreateKey(HKEY_CURRENT_USER, strParentKey)
Call objRegistry.CreateKey(HKEY_CURRENT_USER, strParentKey & "\Location9")
Call objRegistry.SetStringValue(HKEY_CURRENT_USER, strParentKey & "\Location9", "Path", strFolder)
objRegistry = Nothing
arrChildKeys = Nothing
Set objRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
Call objRegistry.EnumKey(HKEY_CURRENT_USER, strParentKey, arrChildKeys)
End If
lngStep = 26
If isArray(arrChildKeys) Then
'if a key with the specified path aleady exists, delete this key to be replaced
For Each varChildKey In arrChildKeys
lngStep = lngStep + 1
Call objRegistry.GetStringValue(HKEY_CURRENT_USER, strParentKey & "\" & varChildKey, "Path", tmpValue)
'Console.WriteLine(tmpValue)
If tmpValue = strFolder Then
Call objRegistry.DeleteKey(HKEY_CURRENT_USER, strParentKey & "\" & varChildKey)
End If
Next
End If
lngStep = 30
'refresh the array in case one has been deleted
Call objRegistry.EnumKey(HKEY_CURRENT_USER, strParentKey, arrChildKeys)
'keep track of child key numbering
'missing holes should be filled so look for the first available locationX
'first look if a slot between 0 and 9 is available
If Not isArray(arrChildKeys) Then
intLocCounter = 0
keyAvailable = True
Else
If isArray(arrChildKeys) Then 'if no childkey array, skip this check
For intLocCounter = 0 To 9
keyAvailable = True
For Each varChildKey In arrChildKeys
If CInt(Mid(varChildKey, 9)) = intLocCounter Then keyAvailable = False
Next
If keyAvailable = True Then Exit For
Next
End If
End If
lngStep = 40
'else take the next available
If keyAvailable = False Then
For Each varChildKey In arrChildKeys
If CInt(Mid(varChildKey, 9)) > intLocCounter Then
intLocCounter = CInt(Mid(varChildKey, 9))
End If
Next
intLocCounter = intLocCounter + 1
End If
'now choose the key
strNewKey = strParentKey & "\Location" & CStr(intLocCounter)
lngStep = 50
Call objRegistry.CreateKey(HKEY_CURRENT_USER, strNewKey)
Call objRegistry.SetStringValue(HKEY_CURRENT_USER, strNewKey, "Path", strFolder)
Call objRegistry.SetStringValue(HKEY_CURRENT_USER, strNewKey, "Description", strLocationDescription)
If blnAllowSubFolders Then
Call objRegistry.SetDWORDValue(HKEY_CURRENT_USER, strNewKey, "AllowSubFolders", 1)
End If
lngStep = 60
addTrustedLocation = True
Exit Function
Hdl:
MsgBox ("Error creating trusted location " & strFolder & " in step " & lngStep & " : " & Err & " " & Err.Description)
End Function
@Cornelis77 You can add trusted locations with VBA code, from within your application. They can be written as registry keys. I once spent a day to create the VBA function addTrustedLocation below. In short, it checks if the specified location already exists and if not, creates it. Note that your environment may block the creation of trusted locations on the network.