User Profile
HeinziAT
Iron Contributor
Joined Nov 10, 2021
User Widgets
Recent Discussions
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>55Views0likes0CommentsThe return of the performance leak - this time with subreports
Anyone remember the v2405 bug that caused loading and closing forms to become slower over time? We found something similar in the current release (tested with semi-annual 2508 (19127.20484)), just with sub reports instead of forms. Here are the repro instructions: Repro instructions Table 1. Create a "numbers" table with a PK field "nr" (Long Integer). 2. Fill it with the numbers from 1 to 100: Dim i For i = 1 To 100 CurrentDb.Execute "INSERT INTO numbers (nr) VALUES (" & i & ")" Next i Sub report 3. Create a new empty report in design view, using the "numbers" table as the record source. 4. In the detail section, add two text boxes "Text1" and "Text2" next to each other, both with the "nr" field as their control source. 5. Reduce the size of the detail section to one "row", containing just the two text boxes. Remove the page header/footer. 6. Add an Format event handler to the detail section with the following content: Me.Text2.Visible = False 7. Save the report as "sub". Main report 8. Create another report "main", which contains nothing but the "sub" report as a subreport in its detail section. Set the record source of "main" to "SELECT * FROM numbers WHERE nr <= 10" Reproduce problem 9. Create the following method in a module: Sub report_loop() Dim i As Long Dim start_time As Single Dim report_name As String Dim path As String report_name = "main" For i = 1 To 40 path = Environ("Temp") & "\testreport.pdf" start_time = Timer DoCmd.OpenReport report_name, acViewPreview DoCmd.OutputTo acOutputReport, report_name, acFormatPDF, path DoCmd.Close acReport, report_name Debug.Print Timer - start_time Next End Sub 10. Run report_loop. Observe that each report export gets slower and slower. Analysis Compare the first and last number in the immediate window: on my machine it's 0.4s for the first report and 2.3s for the last. Note that if you run report_loop again, it will start slow! In other words, each report export causes MS Access to "leak performance" that is only regained after restarting Access. We were able to reproduce this issue with Microsoft 365 semi-annual channel, Version 2508 (19127.20484). I'll do more tests tomorrow and try different older versions to find out when this bug was introduced. Workarounds If you move the visibility code from the Format event to the Print event, the problem still occurs, but slower (0.4s -> 0.72s instead of 0.4s -> 2.3s). The workaround that worked for us was to use =IIf(...) in the control source instead of modifying the visibility. Obviously, that only works for text boxes, not for lines or other controls.85Views1like2CommentsRe: The return of the performance leak - this time with subreports
As promised, I tested different MS Access versions and was surprised to discover that this bug has been in the codebase for approximately 1.5 years: We can reproduce the bug with Current Channel v2407 17830.20138 and later versions. We cannot reproduce the bug with Current Channel v2406 17726.20160 and earlier versions.34Views0likes0CommentsRe: Office update 2405 17628.20110 causes slowness in loading forms in MS Access
Servus Karl! Looks good to me! Here are my test results regarding the "Properties property" issue: 16.0.18025.20160 (CC): can reproduce 16.0.18129.20100 (CC Preview): cannot reproduce Thank you! Looking forward to seeing this in CC. Best regards Heinzi125Views1like0CommentsAn obscure (low-severity) bug involving AutoKeys, MouseMove and RunCommand
Setup 1. Create a new database. 2. Create a new module with the following content: Function myPaste() DoCmd.RunCommand acCmdPaste End Function and save it as "Module1". 3. Create a new macro with the following content: Submacro: ^b RunCode =myPaste() and save it as "AutoKeys". 4. Create a new Form with - a text box "Text0" and - a button "myButton" and save it as "Form1". 5. Add two event handlers ([Event Procedure]) to myButton with the following code: Private Sub myButton_Click() Text0.SetFocus DoCmd.OpenForm "Form2" End Sub Private Sub myButton_MouseMove(Button As Integer, Shift As Integer, X As Single, Y As Single) ' Deliberately empty End Sub 6. Create a new Form with - a text box "Text0" and save it as "Form2". Repro Copy text into the clipboard (for example, the word "test"). Open Form1. Click on the button. Don't do anything after clicking the button. In particular, do not move the mouse for a few seconds (so that it still hovers over the space where the button was while the new form opens). Hit Ctrl-b Expected result Text0 in Form2 now contains the content of the clipboard. Actual result Text0 in Form1 now contains the content of the clipboard. Notes This bug is more of a curiosity than a real problem. It can be reproduced with the current channel of Microsoft 365 (v2409, 18025.20160) and with various older versions of 365, but not with Access 2007, so it was probably introduced at some time during the last 17 years. There are more important bugs to fix in Access, so it's probably not worth investing more time in it, but I still felt the need to document this issue. On workaround to prevent the bug from happening is to add an (empty) KeyDown handler to either Text0 in Form2 or, after enabling Key Preview, to Form2 itself. The MouseMove event handler on the button is required to reproduce the bug. We discovered this issue because our applications use a "Ctrl-v" AutoKey that sanitizes the clipboard (replace tabs with spaces, remove unprintable characters, replace line breaks with spaces if the target is a single-line textbox) before executing the paste operation. One might assume that Text0.SetFocus is part of the problem, but it isn't. It just helps to demonstrate the issue. If you remove it, Access will try to paste the text on the button in Form1 instead of the text box in Form2.173Views0likes0CommentsRe: Office update 2405 17628.20110 causes slowness in loading forms in MS Access
Karl_Donaubauer Thank you! I was able to test Build 18025.20090 and I can confirm rkessels' findings: The "group radio button" issue is fixed. I can no longer reproduce a "performance leak" (for lack of a better name) by just repeatedly opening and closing a form. The "Properties property" issue is still present. Repeatedly accessing control properties via the Control.Properties property causes a permanent (= until the next restart) performance problem when closing forms. Best regards Heinzi293Views0likes4CommentsRe: Office update 2405 17628.20110 causes slowness in loading forms in MS Access
rkessels wrote: [...] But I think Microsoft should fix this, as it was working before. [...] Definitely! If I suggest workarounds, it's only to help those who cannot wait for an official bug fix or switch to a more stable Office channel. Constantly rewriting your code to work around the current bug-of-the-month is not a viable long-term strategy. 😉 Best regards Heinzi890Views0likes1CommentRe: Office update 2405 17628.20110 causes slowness in loading forms in MS Access
rkessels I can also confirm the "properties" issue in the Monthly Enterprise Channel. Some observations: The issue only occurs when accessing the property via the `Properties` property (hehe). In other words, `x = myTextBox.Properties("Visible").Value` causes trouble, `x = myTextBox.Visible` doesn't. Both `x = Eval("Forms!" & formname & "!" & controlname & ".Visible")` and `x = CallByName(myTextBox, "Visible", VbGet)` work fine as well, which might be possible workarounds, if you need to specify the property name dynamically at run-time. Setting (instead of getting) the property value via the `Properties` collection also causes trouble. (That's bad news for us, because it breaks our current "UI customization" code.) For setting the property value, `CallByName myTextBox, "Visible", VbLet, True` works fine, so that's again a possible workaround. I can't reproduce the issue with the Semi-Annual Enterprise Channel (v2402, 17328.20588), so it's apparently not affected yet.927Views3likes3CommentsRe: Office update 2405 17628.20110 causes slowness in loading forms in MS Access
rkessels Thanks for the detailed analysis, that was very helpful. I can confirm your results regarding the Current Channel issue: If we remove all radio button groups from our test form (plus one text box, more on that below), the problem disappears. There seems to be an additional issue, though. Remember the text box I mentioned earlier? It's control source is an expression referencing another control, e.g. something like `=Iif([someStatusCheckBox]=True,"Done","")`. We also needed to remove that text box (after removing all the radio button groups) to make the "performance leak" disappear. Creating a minimal example for that issue is harder than usual, since the removal of other, non-related controls from the form also makes the problem disappear, so I'll only that do if someone requests it. Best regards Heinzi930Views3likes0CommentsRe: Office update 2405 17628.20110 causes slowness in loading forms in MS Access
rkessels Are you sure? Can you reproduce the bug in the Monthly Enterprise Channel? I just did some tests myself (using a form with a lot of controls and a script similar to yours), and I get the following results with Access x64: Current 2408 (17928.20156): can reproduce the bug Monthly 2407 (17830.20210): can not reproduce the bug1.1KViews0likes15CommentsRe: Office update 2405 17628.20110 causes slowness in loading forms in MS Access
I can also confirm that this particular problem reappeared for (at least) one of our customers on the Current Channel with the Aug 1 update. Unfortunately, the Aug 13 update did not fix it (yet).1.3KViews0likes20CommentsRe: Feb 2024 updates: Access->SQL Server performance issues in the Monthly Enterprise Channel
Thanks for the reminder! It's only been a month and I already forgot about the Jan 2024 issue. I just tried the old repro instructions we had for the Jan 2024 issue, and - voilà - that issue can be reproduced in the Feb 2024 Monthly Enterprise Build. So, yes, it seems that your intuition got it right and this is indeed the same problem. Let's hope Microsoft can do a fix-by-feature-gate-switch here as well. Oh, and by the way, the instructions in your blog on how to enable the "Choose Update Channel" button were extremely helpful in debugging this issue. 🙂4.6KViews0likes5CommentsFeb 2024 updates: Access->SQL Server performance issues in the Monthly Enterprise Channel
The February 2024 updates apparently introduced an issue that causes a severe performance problem with DAO recordsets, linked SQL Server tables and the legacy MDAC/WDAC SQL Server driver. Here are the full repro steps: Create large (300,000 rows) SQL Server table CREATE TABLE _test (a int PRIMARY KEY); WITH cte AS ( SELECT 1 AS nr UNION ALL SELECT nr + 1 FROM cte WHERE nr < 300000 ) INSERT INTO _test SELECT nr FROM cte OPTION (MAXRECURSION 0); Attach the table to Access (don't forget to modify the connection string) Sub attach_table() Dim td As TableDef Set td = CurrentDb.CreateTableDef() td.Name = "_test" td.Connect = "ODBC;Driver={SQL Server};SERVER=...;Database=...;Trusted_Connection=yes" td.Attributes = dbAttachSavePWD td.SourceTableName = "_test" CurrentDb.TableDefs.Append td End Sub Reproduce the problem Sub repro_problem() Dim t As Double Dim rs As DAO.Recordset Set rs = CurrentDb.OpenRecordset("_test") t = Timer rs.MoveLast Debug.Print Timer - t End Sub On my system, repro_problem takes 13 seconds with the Monthly Enterprise Channel (v2312, Build 17126.20190), but 0.2 seconds with the Semi-annual Enterprise Channel (v2308, Build 16731.20550) and 0.2 seconds with the Current Channel (v2401, Build 17231.20236) Notes: This issue can be reproduced with the legacy MDAC SQL Server ODBC driver, but not with the new ODBC Driver 17 (didn't test 11, 13 and 18). The issue only occurs if the SQL Server table has a primary key. On a personal note, this issue is particularly embarassing for us, since we recently told all our customers to switch from the Current Channel to the Monthly Enterprise Channel to avoid the frequent Access bugs introduced by feature updates. That worked out well... The code above is sample code to reproduce the problem, not production code. I know that there are more efficient ways to query SQL Server data from Access. I tried to format the code snippets above as "code samples", but that causes the techcommunity editor to reject my posting since it contains "invalid HTML". Oh, well...Solved5.4KViews0likes13CommentsIs there any chance of getting the report pagination bug fixed (or get a reliable workaround)?
This is a bug that has been around for a long time. In a nutshell, it sometimes causes the content of text fields being "cut off" horizontally in the middle of the line when a page break happens in a report. It's more likely to happen with rich-text fields than with plain text fields, and it's more likely to happen with certain fonts than with others, but there's no (known) way to avoid the problem altogether. There have been numerous reports about this, e.g. SuperUser: Truncation of Calibri rich text in preview/PDF mode on a report StackOverflow: Access: Text is truncated in display of a textbox with Can Grow=Yes in report MSDN: Bug: Rich Text Box with CanGrow = True cut off in Access Report I also opened a support ticket 9 years ago (114032111284860), in which the bug was confirmed, but a hotfix was denied, since nobody dares touching that old legacy code. Now that Access is being actively developed again, I'd like to ask for this decision to be reconsidered. I understand that you want to avoid changes in pagination behavior that existing applications rely on, but that could be solved by having, e.g., a new property "PaginationLogic" for Reports that defaults to "Legacy" (for existing databases). Thanks in advance, best regards Heinzi PS: If that bug is no longer in your internal systems, I can provide a repro example accdb.441Views0likes0CommentsWhat's the future of RDLC ("client-side SSRS", aka "ReportViewer")?
This is the information I could gather so far: Getting an RDLC renderer for .NET 5+ is currently the fourth highest-voted feature on the SQL Server user wishlist. Unfortunately, there are currently no plans to do that (see the comments here). There are some enthusiast ports/recompilations floating around on github and nuget, but they are not official. The SQL Server Reporting Services Team Blog is dead, the last entry is from 2018. There's a third-party company providing an RDLC renderer, but Microsoft acquired them in 2018. Nothing has been heard since. There is currently no ReportViewer designer for Visual Studio 2022. Getting one is currently the fourth highest-voted feature on the Visual Studio 2022 wishlist. From a business perspective, I can totally understand that Microsoft is not giving this highly-loved feature the resources it needs. After all, they are basically giving away a great reporting engine for free, undermining their own SQL Server and Power BI sales. And they are not even hiding the fact that they'd rather have people purchase Power BI subscriptions, which is perfectly fine. They are a company, not a charity. Unfortunately, adding a dependency to a third-party cloud service is a no-go for many software development scenarios. Thus, I would like to start a discussion on the following points: It seems to me that MS no longer wants people to use their RLDC reporting engine in new projects. Is this observation correct? If you have a large repository of RDLC reports in your project, what are your migration plans? Are there drop-in replacements from third parties? Would Microsoft consider open-sourcing the RLDC engine, so that the community can "keep the product alive" for legacy scenarios and prevent this from being a blocker in .NET 5+ migrations? Best regards Heinzi12KViews10likes1Comment
Recent Blog Articles
No content to show