Forum Discussion
Feb 2024 updates: Access->SQL Server performance issues in the Monthly Enterprise Channel
Hi,
Microsoft fixed the problem last night. There's no new build. You just have to restart Access to restore normal performance with the "SQL Server" driver.
I have also updated our documenting blog article. As written there, it would be good if affected users could briefly report back whether the fix works for them.
HeinziAT Extremely bad luck with this unusual order of appearance of the bug. S*** happens. At least you contributed to a quicker fix by reporting it here.
Servus
Karl
****************
Access Forever
Access News
Access DevCon
Access-Entwickler-Konferenz AEK
Hi,
Microsoft has confirmed the problem and that we can expect a fix soon.
This time, however, I have written a separate blog article about it to inform those affected and make them aware when the problem is fixed and that they will then have to update or more likely restart Access.
Servus
Karl
****************
Access Forever
Access News
Access DevCon
Access-Entwickler-Konferenz AEK
Hi,
Microsoft fixed the problem last night. There's no new build. You just have to restart Access to restore normal performance with the "SQL Server" driver.
I have also updated our documenting blog article. As written there, it would be good if affected users could briefly report back whether the fix works for them.
HeinziAT Extremely bad luck with this unusual order of appearance of the bug. S*** happens. At least you contributed to a quicker fix by reporting it here.
Servus
Karl
****************
Access Forever
Access News
Access DevCon
Access-Entwickler-Konferenz AEK
Karl_Donaubauer How could Microsoft have fixed the issue remotely without some kind of release? This makes it sound like they have remote access to our systems?
Is there a support article about this?
Hi,
> How could Microsoft have fixed the issue remotely without some kind of release?
Microsoft uses a technique that's quite common in modern SW development and is known under different names: feature toggle, change gate, feature gate etc.
> This makes it sound like they have remote access to our systems?
Yes.
> Is there a support article about this?
No. Mike Wolfe wrote about it a few times:
https://nolongerset.com/office-featuregates/
https://nolongerset.com/office-feature-gates/
Servus
Karl
****************
Access News, Forever, DevCon
Access-Entwickler-Konferenz AEK - 19./20.10. NürnbergKarl_Donaubauer my apologies for the confusion, as I had meant a support article about the bug, not about turning it off.
Thank you for the information. I do appreciate the clarity on how this works.
So the reality of this is that Microsoft didn't reach out to our systems to adjust them, but instead our systems reach out to Microsoft to see if any new features should be disabled. Of course that would not work in environments where the user does not have access to the internet.
The reason I am asking about this is because I have recently encountered what seems to be the same issue using "10.00.19041.4717" of the SQL Server driver.Just for transparency so you can confirm that, the symptoms I experience matches this bad behaviour, I am including them here: An application uses ADODB and the MSJet 4.x engine sends an INSERT INTO ... SELECT ... to an mdb file pushing data into an ODBC linked table from a specific source table with direct column to column mapping. That command is transformed into multiple INSERT INTO ... VALUES ... statements on SQL Server (which sounds normal). The performance of these is a bit slower than expected, but functional, until the default timeout of 30s is reached. If the ADODB.Connection has the "Jet OLEDB:ODBC Command Time Out" property set to say 300, it will continue, otherwise it will fail with a generic ODBC error. With the extended timeout, the submission of the VALUES commands slows down to about 1/min for several commands and then will speed up again, slowing down again after another 30s. This will continue until the command completes, sometimes taking longer than the 5m command timeout set on the connection (Connection.CommandTimeout property).
I tried to use the "ODBC Driver 17 for SQL Server" instead as it was indicated that this does not have that issue, but that does not seem to be compatible with the MSJet engine 4.x provider. We are currently limited to using that because we have a 32-bit app and we cannot guarantee the 32-bit ACEDB drivers are installed. Unfortunately, it seems like the latest version of the ACEDB driver (Office 2021) is not downloadable.
Note that Office is not actually installed on the affected machine.
I will ask our IT to investigate the feature flag functionality to ensure that isn't blocked.
If you have any additional information that you feel would be helpful, or can direct me to useful resources, I would appreciate it.Thank you
