Office v2508 feature update (new vbe7.dll) breaks library compatibility with LTSC VL versions
Since the Jan 2026 updates, some `accde` or `mde` libraries built with the semi-annual enterprise channel (v2508, Build 19127.20484) can no longer be used with the volume-licensed version of Office LTSC (tested with the Jan 2026 release of Office 2024 LTSC VL, v2408, Build 17932.20638). The reason for this seems obvious: The v2508 feature update contains an updated vbe7.dll. Apparently, this change is backwards-compatible (code compiled with the old dll will run with the new dll) but not completely forwards-compatible (code compiled with the new dll might not run with the old dll, even if the new RegExp class is not used). That's a problem for us. We can't just tell our customers to upgrade, because those with an Office 2024 LTSC volume license already use the latest version available to them. Does Microsoft consider this a bug or "by design"? If the latter, what is Microsoft's recommendation for software vendors who want to build software that runs on all currently-supported versions of Access? We currently plan to work around this issue by installing v2502 of the semi-annual enterprise channel on our "build VMs" (32 and 64 bit) and use those to build our software. (Reverting dev machines to an old Office version is not an option for obvious security reasons.) Repro On a PC with v2508 or newer: 1. Create a new mylibrary.accdb with a module with the following code: Public Function GetColorCode() As Long GetColorCode = vbRed End Function 2. File/Save as/Create accde. 3. Copy mylibrary.accde to a PC with v2507 or older (for example, with the current version of Office 2024 LTSC volume license). On a PC with v2507 or older: 4. Create a new database. 5. Create/Module/Tools/References 6. Add a reference to mylibrary.accde 7. Add the following code to the module: Sub Test() Debug.Print GetColorCode() End Sub 8. Debug/Compile Expected result: The database compiles. Actual result: "Compile error: Can't find project or library". The "references" window opens automatically and highlights "mylibrary". Notes We are not library developers, but we are still impacted by this issue, since the software we ship consists of a (modifiable) startup mdb referencing an (unmodifiable) mde containing the business logic. If you want to try to reproduce this issue but don't have a volume license of Office 2024 LTSC lying around (we certainly don't), you can install a trial version with the Office Deployment Tool and the following configuration file: <Configuration> <Add OfficeClientEdition="64" Channel="PerpetualVL2024"> <Product ID="ProPlus2024Volume"> <Language ID="en-us" /> </Product> </Add> </Configuration>
DLL Hell ... Again Access 16.0.12430.20264 vs 16.0.4266.1001 Office 365 vs ACCDR RTE Project
Hi everyone first time poster long time access developer, a few years ago I had this issue, and a year or so ago I had this problem. I develop a 32bit access .accdr and distribute it via the runtime with an installer. Client has Click to Run Office 365 (32bit) 16.0.12430.20264 My version of access if Office 2016 16.0.12430.20264. When I deploy my app to their PC the run time does not install (obviously since they have 365) however when I try to run portions of my form I get errors like function is not available in expressions in query expression left([id],1) Now Other 365 users dont have this problem just this client what can I do here? Here are my references: 16.0.4266.1001 Microsoft Access 2016 - Build:16.0.4266 VBA: C:\PROGRA~2\COMMON~1\MICROS~1\VBA\VBA7.1\VBE7.DLL (7.1.10.48) Access: C:\Program Files (x86)\Microsoft Office\Office16\MSACC.OLB (16.0.4266.1001) DAO: C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE16\ACEDAO.DLL (16.0.4266.1001) SHDocVw: C:\Windows\SysWOW64\ieframe.dll (11.0.18362.657) WinHttp: C:\Windows\system32\winhttpcom.dll (10.0.18362.1) ADODB: C:\Program Files (x86)\Common Files\System\ado\msado15.dll (10.0.18362.239) ADOX: C:\Program Files (x86)\Common Files\System\ado\msadox.dll (10.0.18362.175) stdole: C:\Windows\SysWOW64\stdole2.tlb (10.0.18362.1) MSXML2: C:\Windows\SysWOW64\msxml6.dll (6.30.18362.418) Office: C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE16\MSO.DLL (16.0.4266.1001) Here are the client references: 16.0.12430.20264 Microsoft Access 2016 - Build:16.0.12430 VBA: C:\Program Files (x86)\Common Files\Microsoft Shared\VBA\VBA7.1\VBE7.DLL (7.1.10.92) Access: C:\Program Files (x86)\Microsoft Office\Root\Office16\MSACC.OLB (16.0.10730.20030) DAO: C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE16\ACEDAO.DLL (16.0.12325.20144) SHDocVw: C:\Windows\SysWOW64\ieframe.dll (11.0.18362.657) WinHttp: C:\WINDOWS\system32\winhttpcom.dll (10.0.18362.1) ADODB: C:\Program Files (x86)\Common Files\System\ado\msado15.dll (10.0.18362.239) ADOX: C:\Program Files (x86)\Common Files\System\ado\msadox.dll (10.0.18362.175) stdole: C:\Windows\SysWOW64\stdole2.tlb (10.0.18362.1) Office: C:\Program Files (x86)\Common Files\Microsoft Shared\OFFICE16\MSO.DLL (16.0.12430.20184) Deploying my app out to users who already have access almost always works as long as its all 32 bit but i've now encountered this type of issue twice where a CTR Office 365 gets dll errors running my app. Any thoughts?