Another Access 365 bug

[isladogs]

Just when you thought it was safe to go back in the water ...

After the debacle of the query is corrupt bug, there is another serious bug caused by the 1912 update to Access 365.
This affects databases with SQL Server backends and has now been acknowledged by MS https://support.office.com/en-us/article/access-does-not-recognize-the-identity-column-in-a-linked-SQL-server-table-ae418bbf-2658-453a-82f1-7e043812d60d

Any linked SQL tables with a PK field with IDENTITY INSERT ON should be treated by Access as autonumber fields but for any tables newly linked or refreshed the fields are now being wrongly treated as Number.

Why this matters is clearly explained in this post which first alerted me to the issue https://social.msdn.microsoft.com/Forums/en-US/abd458eb-bf5b-4a89-b831-3d90e7e5d266/the-1912-update-to-access-20162019365-breaks-the-way-linked-sql-server-tables-with-identity?forum=accessdev

For affected users, until MS release a fix, the advice is not to update to 1912 or if already done, to revert to 1911.

 

[isladogs]

I can confirm the issue with new or refreshed tables in my own Access 365 applications.
Luckily I mainly use A2010 which isn't affected

As an experiment I created a new A2010 database and linked several SQL tables with autonumber fields.
I then reopened that app in A365 - the autonumber fields were still correct (as long as you don't refresh the links in A365)

If you do that in reverse - link in A365 then open in A2010 THEN refresh the links, the autonumber datatype is once again correctly identified.

So that's an additional work-round that may help some people until MS do a proper fix.
You just need a retail version of MS Access (2019 or earlier) as none of these were affected by this latest flawed update

 

[Thales750]

Access 365 2016
The same confirmation.
On versions created prior to 1-21-2020 where the SQL Server Table were linked. It reports autonumber for the primary key.

Recent ones are Number Fields.

 

[Thales750]

When removing patches using the following Microsoft procedure.

https://support.microsoft.com/en-us/help/2770432/how-to-revert-to-an-earlier-version-of-office-2013-or-office-2016-clic


1. The Version Numbering is a little confusing.

This is the format to use in the Config file to revert back to 1911.

<Configuration>
<Updates Enabled="TRUE" TargetVersion="16.0.12228.20364" />
</Configuration>

This will turn on Auto-Updates. You will need to turn them off again

 

[isladogs]

Thanks for passing on the additional info on this issue

I've just discovered that the bug fix (build 12325.20344) has been available since yesterday (22 Jan):
https://docs.microsoft.com/en-us/officeupdates/monthly-channel-2020#version-1912-january-22

You should get it within the Office update cycle or actively download it with "Update now".

Depending on your application you may have to refresh or rebuild the link to the SQL Server tables in order to have the Identity columns recognized again.

This page may also be useful: https://docs.microsoft.com/en-gb/OfficeUpdates/office365-proplus-security-updates

NOTE: If, like me, you are an Office insider, you may need to first remove the later 2001 version (build 12430.20120) or 2002 version (build 12508.20000) in order to implement this. :banghead:

I find an easier method of reverting Office 365 to an earlier version is to run a command like this from an elevated command prompt replacing the build number in RED with the appropriate build needed:

cd %programfiles%\Common Files\Microsoft Shared\ClickToRun
officec2rclient.exe /update user updatetoversion=[I][B][COLOR="DarkRed"]16.0.12130.20272[/COLOR][/B][/I]