User Profile
HeinziAT
Brass Contributor
Joined 5 years ago
User Widgets
Recent Discussions
Re: 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 Heinzi98Views1like0CommentsAn 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.159Views0likes0CommentsRe: 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 Heinzi281Views0likes4CommentsRe: 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 Heinzi868Views0likes1CommentRe: 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.915Views3likes3CommentsRe: 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 Heinzi918Views3likes0CommentsRe: 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 https://www.accessforever.org/post/demystifying-microsoft-365-update-channels 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.1KViews0likes13CommentsIs 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: https://superuser.com/q/455782/14517 StackOverflow: https://stackoverflow.com/q/10612364/87698 MSDN: https://social.msdn.microsoft.com/Forums/en-US/648dd3a2-28c1-4f0d-853c-ef932c58519f/bug-rich-text-box-with-cangrow-true-cut-off-in-access-report?forum=accessdev 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.421Views0likes0CommentsWhat'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 https://feedback.azure.com/d365community/idea/ec1af842-4d25-ec11-b6e6-000d3a4f0da0. Unfortunately, there are currently no plans to do that (see https://devblogs.microsoft.com/dotnet/announcing-net-5-0-preview-6/). There are some enthusiast ports/recompilations floating around on github and nuget, but they are not official. The https://docs.microsoft.com/en-us/archive/blogs/sqlrsteamblog/ is dead, the last entry is from 2018. There's a third-party company providing an RDLC renderer, but https://docs.microsoft.com/en-us/archive/blogs/sqlrsteamblog/microsoft-acquires-report-rendering-technology-from-forerunner-software. Nothing has been heard since. There is currently no ReportViewer designer for Visual Studio 2022. Getting one is currently the https://developercommunity.visualstudio.com/search?space=8&sort=votes&q=2022. 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