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

Heinzi

Hi Heinzi,

---

...Build 18025.20090 ... The "Properties property" issue is still present.

This was in Current Channel Preview (CCP), wasn't it? Currently there's a fix for this in CCP version 2410. If you can test it there, please report your findings.

The fix should arrive in Current Channel (CC) version 2410 next week. I'm still trying to find out for Ron when it will be in the Montly Enterprise Channel (MEC).

Servus
Karl
****************
Access Forever News DevCon
Access-Entwickler-Konferenz AEK - 19./20.10. Nürnberg

Hi,

> Version 2409 with the 1 fix you tested should be available in Current Channel with this week's Office updates.

Now available as version 2409 build 18025.20096.

Your other problem scenario with "Properties" is being investigated.

Servus
Karl
****************
Access Forever, News, DevCon
Access-Entwickler-Konferenz AEK - 19./20.10. Nürnberg

Hi Ron and Heinzi,

I'll pass your feedback on to the Access team and get back to you if there is any news.

Version 2409 with the 1 fix you tested should be available in Current Channel with this week's Office updates.

Servus
Karl
****************
Access Forever News DevCon
Access-Entwickler-Konferenz AEK - 19./20.10. Nürnberg

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

Heinzi

Hi Karl_Donaubauer ,

Thanks for the update, good to hear Microsoft has fixed this issue and asks us to test :-).

As there are two issues:

1. issue in version 2407 (Monthly enterprise) --> Re: Office update 2405 17628.20110 causes slowness in loading forms in MS Access - Page 2 - Microsoft Community Hub

2. issue in version 2408 --> Re: Office update 2405 17628.20110 causes slowness in loading forms in MS Access - Page 2 - Microsoft Community Hub

I have tested a few scenario's:

1. are the speedtest scenario's I provided

2. in our application a speedtest with a 'real life scenario'. 

I can confirm that the issue with the 2408 version is fixed (Re: Office update 2405 17628.20110 causes slowness in loading forms in MS Access - Page 2 - Microsoft Community Hub).

But I must conclude that the issue with the 2407 Monthly enterprise ( Re: Office update 2405 17628.20110 causes slowness in loading forms in MS Access - Page 2 - Microsoft Community Hub) still exists.

Did you share also that specific 2407 testcase to Microsoft?

Best,

Ron

Hi people currently affected in Sep 2024,

There is news: Microsoft is testing a new fix in the Current Channel Preview (CCP) with version 2409 build 18025.20090, which is being rolled out today. You can already request it by selecting File – Account – Update Options – Update Now.

If you have a problem/test scenario and can subscribe to CCP (see also our AFo article about channel switching), then feedback on the effectiveness of the fix in this beta channel would be very useful in order to speed up delivery to the productive channels.

Servus
Karl
****************
Access Forever News DevCon
Access-Entwickler-Konferenz AEK - 19./20.10. Nürnberg

Opening .accdb files, including empty ones, takes a long time (30 to 40 seconds), regardless of the file’s contents. My current version is Office LTSC 2021, version 2108 (Build 14332.20763). Interestingly, the same version on a client PC that is not connected to any network opens Access files quickly. The server where the issue occurs is connected to a private network.

Could this issue be related to the private network connection? Is there any workaround for this?

---

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

Heinzi

HeinziAT thanks for your comments, I agree on what you wrote.

It is correct it only appears if you use the properties. But this wasnt the case in the 2406 monthly enterprise version. And I think this is also probably the reason for the issue with the textfield in 2408 that you wrote earlier about.

We have now implemented another way to read the properties, without using properties. So we have a fix. But I think Microsoft should fix this, as it was working before. Hopefully Karl_Donaubauer  can also share my second testresultset for 2407.

Best,

Ron

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.

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

Heinzi

Dear Karl_Donaubauer thanks for providing the bugreport to microsoft.

We have now also identified the issue with the Monthly Enterprise Channel 2407 version. HeinziAT fyi.

The issue in the 2407 version is also in the current channel 2408.

The issue is with reading properties of an object. Below is a sample helper function that reads the value of a property on a form.

I have made a test database, see attached. In this test database is a FormSpeedtest with 1 control. And in the Form_Load we do 100 times a 2000 readproperty call. What we see is that this gives stable timing for 2406, but in 2407 (monthly) and 2408 (current) timings increase significantly. See attached Excel file with the timings.

The code in the attachment reads the property with the function call. But even if you read the property directly in the form_load with me.Tekst0.Properties("text").value (in stead of the readproperty call). The issue appears.

The decrease in performance of the application is permanently, untill you close and re-open the application.

Can you share this also with Microsoft?

Thanks,

Ron

Hi Ron,

I have pointed out the recurrence of the problem to Microsoft again based on the details in this discussion. They are investigating/working on it. I will also send them the information about your repro files.

Servus
Karl
****************
Access Forever, News, DevCon
Access-Entwickler-Konferenz AEK - 19./20.10. Nürnberg

Hello HeinziAT , Karl_Donaubauer,

You are right, there is a difference between 2408 Current Channel and 2407 Monthly channel.

I have tested again with the speedtest that I made when we had the issues in version 2405. WIth this form I cannot reproduce in any of these versions.

But I have found a new form which has the issue. When you have radio buttons in a grouped set. Then forms become slower. If you have the radio buttons separately, then it does not get slower.

Please find attached a test datbase. In this there is a function called Speedtest. that 50 times opens and closes a form and shows the timing for the set of 10 open-close actions.

What I see is that:

with 2406 Monthly channel, timings are stable.

with 2408 current channel, and Tabel2a (grouped radio buttons) timings increase after +/- 250 open-closes from 1,7s per 10 to 4s per 10.

With tabel2 (only radio buttons) I don't see this increase.

This is tabel2 (only radio buttons):

This is Tabel2a (grouped radio buttons):

I hope someone can pass this over to Microsoft to solve this issue.

Attached you find the speedtest access db, and an excel with timings for the 4 test-cases.

We also see issues in 2407 Monthly release, but cannot pinpoint the issue at the moment. Once we have pinpointed this one I will inform you.

Best,

Ron