お久しぶりです。
超不定期投稿、まさに爺ぃの備忘録である本サイトですが、
恥ずかしながら？^^; 以前の記事
で紹介しました事案がまた発生しました(´・ω・`)
で、その時は別の方法で解決したのですが、なんと、MS様公式に解決方法が掲載されておりました！
Microsoftコミュニティ Accessでレポートの罫線が消える
※当方PC環境 Win11Pro OSビルド 22000.795 + Access2019(x86)
皆様も苦しんでおられる様子・・・(´・ω・`)
MS様は月イチのペースでWindowsを自動更新するのですが、本当にオソロしいです(´・ω・`)
2022年09月07日
2022年07月02日
Windows11 21H2 OSビルド22000.778に更新するとAccess2019レポート罫線が消えて歯抜けになる事案が発生(´；ω；｀)
毎日暑いですねぇ(´・ω・`)
そんな中、背筋も凍る（大げさ）な事案が、
Windows11の更新で発生しましたので、メモ(´・ω・`)
なんといいますか、 MS様が更新を誘うので、
Windows11 Pro 22000.739 から、
2022/6/23リリースの22000.778 にバージョンアップしたところ、
何故かAccess2019のレポート中の罫線（特に横）が、
歯抜け（勝手に消えてしまう状態）になり、
業務に支障が出る事案が発生しました(´；ω；｀)
で、復旧方法ですが、
【その１】システムの復元で元のビルドに戻す。
Windows11 22000.778に復元(´・ω・`)
腹立たしいので、自動更新を5週間一時停止しました（#^ω^）
【その２】最新版Accessランタイム（Office365 Accessランタイム）を削除し、Access2016 ランタイムに変更。
何故か、従来どおりにレポートが表示されました(´・ω・`)
※検証環境：OS:Win11 Pro ・Accessは32ビット版・PC2台
もう、何がなんだかですが、
対応に追われた時間を返してください！！ MS様・・・^^;
そんな中、背筋も凍る（大げさ）な事案が、
Windows11の更新で発生しましたので、メモ(´・ω・`)
なんといいますか、 MS様が更新を誘うので、
Windows11 Pro 22000.739 から、
2022/6/23リリースの22000.778 にバージョンアップしたところ、
何故かAccess2019のレポート中の罫線（特に横）が、
歯抜け（勝手に消えてしまう状態）になり、
業務に支障が出る事案が発生しました(´；ω；｀)
で、復旧方法ですが、
【その１】システムの復元で元のビルドに戻す。
Windows11 22000.778に復元(´・ω・`)
腹立たしいので、自動更新を5週間一時停止しました（#^ω^）
【その２】最新版Accessランタイム（Office365 Accessランタイム）を削除し、Access2016 ランタイムに変更。
何故か、従来どおりにレポートが表示されました(´・ω・`)
※検証環境：OS:Win11 Pro ・Accessは32ビット版・PC2台
もう、何がなんだかですが、
対応に追われた時間を返してください！！ MS様・・・^^;
2021年04月19日
MS-Access激オソ環境がWinodws10のアップデートで元の起動速度に戻る事案が発生^^;
月曜日、色々あるんです。^^;
出社後、PCを起動すると、Windows10を再起動せよとの指示が・・・(´・ω・`)
素直に再起動して、
例の、起動速度が激オソとなり、
速度改善の為、姑息化もとい高速化に四苦八苦した^^;
MS-Access業務アプリ を起動すると・・・
な、なんと！元の起動速度に戻っている！！ヽ(=´▽`=)ﾉ
今までの苦労 はなんだったんでしょうか・・・^^;
で、「 winver 」でバージョンを確認すると
Windows10 バージョン 20H2 (OSビルド 19042.928 )
おもむろに バージョンアップされている！(*^_^*)（ 旧 19042.867→19042. 928 ）
何が変わったん(?_?)
早速、 Google先生にお尋ね すると・・・
検索結果1行目 MS様公式
2021 年 4 月 13 日 - KB5001330 (OS ビルド 19041.928 および 19042.928)
以下、MS様のコピペ
アラーム
Microsoft は、2021 年 3 月にサポートが切れ中の Microsoft Edge レガシ デスクトップ アプリケーションを削除しました。 この 2021 年 4 月 13 日リリースでは、新しい Microsoft Edge をインストールします。 詳細については、Microsoft Edge レガシを 4 月の Windows 10 Update Tuesdayリリース に置き換える新しい Microsoft Edge を参照してください。
ハイライト
・Windows で基本的な操作を実行する際のセキュリティを強化するための更新プログラム。
・マウス、キーボード、ペンなどの入力デバイスを使用する場合のセキュリティを向上させる更新プログラム。
Edgeが新バージョンに更新された事ほか、諸々の改善が、
Access2019アプリ激オソ起動 改善とどのような因果関係があるのか、
当方にはお恥ずかしながら全く理解できないです(*ﾉω・*)ﾃﾍ
まぁ、 結果オーライ (死語か？^^;）ということで、良しとします(*^_^*)
ＰＣ環境限定とはいえ、月曜日に久々嬉しい事が起こりました。ヽ(=´▽`=)ﾉ
出社後、PCを起動すると、Windows10を再起動せよとの指示が・・・(´・ω・`)
素直に再起動して、
例の、起動速度が激オソとなり、
速度改善の為、姑息化もとい高速化に四苦八苦した^^;
MS-Access業務アプリ を起動すると・・・
な、なんと！元の起動速度に戻っている！！ヽ(=´▽`=)ﾉ
今までの苦労 はなんだったんでしょうか・・・^^;
で、「 winver 」でバージョンを確認すると
Windows10 バージョン 20H2 (OSビルド 19042.928 )
おもむろに バージョンアップされている！(*^_^*)（ 旧 19042.867→19042. 928 ）
何が変わったん(?_?)
早速、 Google先生にお尋ね すると・・・
検索結果1行目 MS様公式
2021 年 4 月 13 日 - KB5001330 (OS ビルド 19041.928 および 19042.928)
以下、MS様のコピペ
アラーム
Microsoft は、2021 年 3 月にサポートが切れ中の Microsoft Edge レガシ デスクトップ アプリケーションを削除しました。 この 2021 年 4 月 13 日リリースでは、新しい Microsoft Edge をインストールします。 詳細については、Microsoft Edge レガシを 4 月の Windows 10 Update Tuesdayリリース に置き換える新しい Microsoft Edge を参照してください。
ハイライト
・Windows で基本的な操作を実行する際のセキュリティを強化するための更新プログラム。
・マウス、キーボード、ペンなどの入力デバイスを使用する場合のセキュリティを向上させる更新プログラム。
Edgeが新バージョンに更新された事ほか、諸々の改善が、
Access2019アプリ激オソ起動 改善とどのような因果関係があるのか、
当方にはお恥ずかしながら全く理解できないです(*ﾉω・*)ﾃﾍ
まぁ、 結果オーライ (死語か？^^;）ということで、良しとします(*^_^*)
ＰＣ環境限定とはいえ、月曜日に久々嬉しい事が起こりました。ヽ(=´▽`=)ﾉ
2021年04月16日
MS-Accessの起動が激オソになる事案が発生(´・ω・｀)
ある日突然、
MS-Accessのリンクテーブルを使用した 業務アプリの起動時間が激オソになり、
な、 なんと1分以上！ かかる事案が発生しました(´・ω・｀)
※【参考】激オソ対象環境
PC：Corei5(10400)+メモリ8GB+256GSSD
OS:Win10 Pro (x64･20H2)
Office: Access2019 2019 MSO(16.0.13901.20148)32bit
対象：アプリ本体：ACCDB形式+リンクテーブル先DB：MDB形式
まあ、年度末でなんかバタバタで、「 壊れたんじゃないか！？ 」ってくらい起動時激オソでも、
一度起動してしまえばフツーに動くもんだから、しばらく放置プレイ状態・・・(;^_^A
もう一台のPC
PC：Corei5(9400)+メモリ8GB+256GSSD
OS:Win10 Pro (x64･20H2)
Office: Access 2016 (32bit版）
では、通常の速度で起動する状況・・・
Accessのバージョンの違いなのか？ Win10OSの問題なのか？
手持ち環境で検証すると以下の結果・・・（※Accessは全て32bit版)
◯ 2013ランタイム：Win10Pro(x64･20H2)Corei7(7th) 1.5秒
◯ 2016ランタイム：Win10Pro(x64･2004)Corei5(9th) 2秒
◯ 2016通常版 ：Win10Pro(x64･20H2)Corei5(9th) 2秒
?2019通常版 ：Win10Pro (x64･20h2) Corei5(10th) 80秒!!←激オソ(´・ω・`)
といった状況・・・
こんなときは、やっぱり Google先生に尋ねる しかない！
ＭＳ様公式のサポートが出てまいりましたヽ(=´▽`=)ﾉ
Access 2002、Office Access 2003、および Office Access 2007 のリンク テーブルでパフォーマンスが低下する
当方 Access2019 なんですが、共有してる DB形式はMDBのままだし、これいけるかも！？ と思って試した見たところ、 まあまあの結果がでました ので、以下メモ。
手順メモ
（１）激オソ対象のAccessファイルを開き、上記モジュールをコピペ
（２）VBAエディタでイミディエイトウィドウを開き、「 TurnOffSubDataSheets 」を実行
（３）実行すると、下記結果が表示
※ここでは50個のテーブルに「サブデータシート名＝なし」処理。
で、以下、 ＭＳ様の説明詳細をコピペ
Office Access 2007、Access 2003、Access 2002、および Access 2000 では、サブデータシート内にテーブルの関連レコードを表示できます。この機能は、Access 97 では使用できません。 主テーブルと関連テーブルとの間のリレーションシップを管理するために、システムで追加のオーバーヘッドが必要になり、これにより応答時間が長くなる可能性があります。特に、データベース内に数多くのリンク テーブルが存在し、それらのテーブル間に多くのリレーションシップがある場合に影響が顕著になります。
一対多リレーションシップの主テーブル ("一" の側のテーブル) では 、"サブデータシート名" プロパティを [なし] に設定できます。 この場合、サブデータシートは表示されません。また、この テーブルの "サブデータシート名" プロパティは特定の関連テーブルの名前に設定するか、[自動] に設定することもできます。このプロパティが [自動] に設定されている場合は、主テーブル内でレコードの展開インジケータをクリックしたときにレコードを表示する関連テーブルを選択できます。このプロパティを [自動] に設定すると、パフォーマンスが著しく低下する可能性があります。これは特に、コンピュータが古く、データベースで数多くのリンク テーブルが使用されている場合に顕著になります。 この現象は、テーブルがすべて同じデータベース内にある場合には発生しません。
効果のほどは？？？
◯ 2013ランタイム：Win10Pro(x64･20H2)Corei7(7th) 1.5秒：効果なし
◯ 2016ランタイム：Win10Pro(x64･2004)Corei5(9th) 2秒：効果なし
◯ 2016通常版 ：Win10Pro(x64･20H2)Corei5(9th) 2秒：効果なし
△2019通常版 ：Win10Pro (x64･20h2) Corei5(10th) 11秒!!←微妙^^;
８０ 病 もとい秒！に比べればまし、贔屓目で「まあまあ」ですが、
やはりこの結果は「微妙」なので「△」としました(´・ω・`)
更に調べてみると、
（１）そもそも「リンクテーブル」で対象DBを共有する使用法が邪道^^;
Accessとはいえ、ADOを駆使した、本格的な？DB構成にしないと駄目。(超意訳^^;） Accees開発サポート様
（２）ネットワークOfficeファイルを開く際に、プログラムの速度が遅い、または応答が停止する (ハングする) 場合があります。 MS様
（３）ＰＣとか通信環境が貧弱じゃね！？（意訳^^;） MS様
とか、Access（というよりOffice製品か？）で、
速度が著しく低下する事案は、
割とメジャーな不具合なようです。(´・ω・`)
（１）についてはプログラムを組み直す必要があり、
効果はてきめんでしょうが、 面倒なので^^;却下(´・ω・`)
（２）は、レジストリを追加するだけだから実行済。
効果はある模様( ･?ω･?)
（３）は、まあ、一般論ですねぇ(´・ω・`)
【まとめ】
とりあえずは、
・ サブデータシートのリレーション「無効」
（TurnOffSubDataSheets 関数の実行）
（８０秒→１１秒）
・ レジストリを追記し、ファイルキャッシュを「無効」
（１１秒→８秒）
の組合せで、まあ、許容できる起動時間となりました。^^;
なにか、劇的な改善方法があれば、是非教えてくださいm(_ _)m
※Access2013とか2016に戻すとかは無しで^^;
【追伸・言い訳】
あくまでも当方の環境での結果ですので、お試し頂いて効果が出なくても
当方は一切関知いたしませんので、ご容赦願いますm(_ _)m
MS-Accessのリンクテーブルを使用した 業務アプリの起動時間が激オソになり、
な、 なんと1分以上！ かかる事案が発生しました(´・ω・｀)
※【参考】激オソ対象環境
PC：Corei5(10400)+メモリ8GB+256GSSD
OS:Win10 Pro (x64･20H2)
Office: Access2019 2019 MSO(16.0.13901.20148)32bit
対象：アプリ本体：ACCDB形式+リンクテーブル先DB：MDB形式
まあ、年度末でなんかバタバタで、「 壊れたんじゃないか！？ 」ってくらい起動時激オソでも、
一度起動してしまえばフツーに動くもんだから、しばらく放置プレイ状態・・・(;^_^A
もう一台のPC
PC：Corei5(9400)+メモリ8GB+256GSSD
OS:Win10 Pro (x64･20H2)
Office: Access 2016 (32bit版）
では、通常の速度で起動する状況・・・
Accessのバージョンの違いなのか？ Win10OSの問題なのか？
手持ち環境で検証すると以下の結果・・・（※Accessは全て32bit版)
◯ 2013ランタイム：Win10Pro(x64･20H2)Corei7(7th) 1.5秒
◯ 2016ランタイム：Win10Pro(x64･2004)Corei5(9th) 2秒
◯ 2016通常版 ：Win10Pro(x64･20H2)Corei5(9th) 2秒
?2019通常版 ：Win10Pro (x64･20h2) Corei5(10th) 80秒!!←激オソ(´・ω・`)
といった状況・・・
こんなときは、やっぱり Google先生に尋ねる しかない！
ＭＳ様公式のサポートが出てまいりましたヽ(=´▽`=)ﾉ
Access 2002、Office Access 2003、および Office Access 2007 のリンク テーブルでパフォーマンスが低下する
当方 Access2019 なんですが、共有してる DB形式はMDBのままだし、これいけるかも！？ と思って試した見たところ、 まあまあの結果がでました ので、以下メモ。
手順メモ
（１）激オソ対象のAccessファイルを開き、上記モジュールをコピペ
- Sub TurnOffSubDataSheets()
- Dim MyDB As DAO.Database
- Dim MyProperty As DAO.Property
- Dim propName As String, propVal As String, rplpropValue As String
- Dim propType As Integer, i As Integer
- Dim intCount As Integer
- On Error GoTo tagError
- Set MyDB = CurrentDb
- propName = "SubDataSheetName"
- propType = 10
- propVal = "[None]"
- rplpropValue = "[Auto]"
- intCount = 0
- For i = 0 To MyDB.TableDefs.Count - 1
- If (MyDB.TableDefs(i).Attributes And dbSystemObject) = 0 Then
- If MyDB.TableDefs(i).Properties(propName).Value = rplpropValue Then
- MyDB.TableDefs(i).Properties(propName).Value = propVal
- intCount = intCount + 1
- End If
- End If
- tagFromErrorHandling:
- Next i
- MyDB.Close
- If intCount > 0 Then
- MsgBox "The "
& propName & " value for "
& intCount & " non-system tables has been updated to "
& propVal & "."
- End If
- Exit Sub
- tagError:
- If Err.Number = 3270 Then
- Set MyProperty = MyDB.TableDefs(i).CreateProperty(propName)
- MyProperty.Type = propType
- MyProperty.Value = propVal
- MyDB.TableDefs(i).Properties.Append MyProperty
- intCount = intCount + 1
- Resume tagFromErrorHandling
- Else
- MsgBox Err.Description & vbCrLf & vbCrLf & " in TurnOffSubDataSheets routine."
- End If
- End Sub
（２）VBAエディタでイミディエイトウィドウを開き、「 TurnOffSubDataSheets 」を実行
（３）実行すると、下記結果が表示
※ここでは50個のテーブルに「サブデータシート名＝なし」処理。
で、以下、 ＭＳ様の説明詳細をコピペ
Office Access 2007、Access 2003、Access 2002、および Access 2000 では、サブデータシート内にテーブルの関連レコードを表示できます。この機能は、Access 97 では使用できません。 主テーブルと関連テーブルとの間のリレーションシップを管理するために、システムで追加のオーバーヘッドが必要になり、これにより応答時間が長くなる可能性があります。特に、データベース内に数多くのリンク テーブルが存在し、それらのテーブル間に多くのリレーションシップがある場合に影響が顕著になります。
一対多リレーションシップの主テーブル ("一" の側のテーブル) では 、"サブデータシート名" プロパティを [なし] に設定できます。 この場合、サブデータシートは表示されません。また、この テーブルの "サブデータシート名" プロパティは特定の関連テーブルの名前に設定するか、[自動] に設定することもできます。このプロパティが [自動] に設定されている場合は、主テーブル内でレコードの展開インジケータをクリックしたときにレコードを表示する関連テーブルを選択できます。このプロパティを [自動] に設定すると、パフォーマンスが著しく低下する可能性があります。これは特に、コンピュータが古く、データベースで数多くのリンク テーブルが使用されている場合に顕著になります。 この現象は、テーブルがすべて同じデータベース内にある場合には発生しません。
効果のほどは？？？
◯ 2013ランタイム：Win10Pro(x64･20H2)Corei7(7th) 1.5秒：効果なし
◯ 2016ランタイム：Win10Pro(x64･2004)Corei5(9th) 2秒：効果なし
◯ 2016通常版 ：Win10Pro(x64･20H2)Corei5(9th) 2秒：効果なし
△2019通常版 ：Win10Pro (x64･20h2) Corei5(10th) 11秒!!←微妙^^;
８０ 病 もとい秒！に比べればまし、贔屓目で「まあまあ」ですが、
やはりこの結果は「微妙」なので「△」としました(´・ω・`)
更に調べてみると、
（１）そもそも「リンクテーブル」で対象DBを共有する使用法が邪道^^;
Accessとはいえ、ADOを駆使した、本格的な？DB構成にしないと駄目。(超意訳^^;） Accees開発サポート様
（２）ネットワークOfficeファイルを開く際に、プログラムの速度が遅い、または応答が停止する (ハングする) 場合があります。 MS様
（３）ＰＣとか通信環境が貧弱じゃね！？（意訳^^;） MS様
とか、Access（というよりOffice製品か？）で、
速度が著しく低下する事案は、
割とメジャーな不具合なようです。(´・ω・`)
（１）についてはプログラムを組み直す必要があり、
効果はてきめんでしょうが、 面倒なので^^;却下(´・ω・`)
（２）は、レジストリを追加するだけだから実行済。
効果はある模様( ･?ω･?)
（３）は、まあ、一般論ですねぇ(´・ω・`)
【まとめ】
とりあえずは、
・ サブデータシートのリレーション「無効」
（TurnOffSubDataSheets 関数の実行）
（８０秒→１１秒）
・ レジストリを追記し、ファイルキャッシュを「無効」
（１１秒→８秒）
の組合せで、まあ、許容できる起動時間となりました。^^;
なにか、劇的な改善方法があれば、是非教えてくださいm(_ _)m
※Access2013とか2016に戻すとかは無しで^^;
【追伸・言い訳】
あくまでも当方の環境での結果ですので、お試し頂いて効果が出なくても
当方は一切関知いたしませんので、ご容赦願いますm(_ _)m
2020年11月30日
ショック！Access2013業務アプリがWindows10 20H2で物故者となる！(´・ω・｀) も なんとか蘇る！！ヽ(=´▽`=)ﾉ
そろそろ塩梅も良くなってきたか？っと思って
更新した Windows10 20H2(2020年10月更新版）
そこには、とんでもない罠がありました(´・ω・｀)
今まで更新すると、
日本語入力が変になったり、社内の特定NASにアクセスできなくなったりと、
Windows10の更新には毎度恐怖を感じておりましたが、またもや出てしまいました。^^;
当方、 Windows10 2004(20H1)については上記問題が発生し、1909に戻した苦い経験がありました。
喉元すぎればなんとやらで、今回はまあ、枯れてきたから大丈夫じゃね？(*^_^*)
って気持ちで更新したら、でました！(´・ω・｀) Accessで開発した業務アプリが見事全滅・・・
すぐに グーグル先生 に助けてもらったら、
Windows 10 バージョン 2004 (20H1) / 20H2 上で 半角カナのフォームを含んだ Access ファイルでエラーが発生する (；´∀｀) ※
という事象がWindows10 2004(20H1)/20H2で発生することが確認できました。(´・ω・｀)
対策方法は、コマンドプロンプト（管理者）で、上記サイトのコマンドのコピペでとりあえず動作できましたが、MS様は改善する気はなさそうです(´・ω・｀)
以下、MS様のコピペですが、復旧までの手順をメモ・・・
【手順その１】：互換性トラブルシューティングを実行
※設定変更方法 (MSI版 Office の場合。詳細は MS様のココ を確認してください^^;）
・エクスプローラー上から、MSACCESS.EXE を右クリックし、「互換性のトラブルシューティング」を選択します。
・「推奨設定を使用する」を選択する。
・Windows 互換モード : Windows 8 となっていることを確認し「プログラムのテスト」ボタンをクリックします。
・Access アプリケーションが起動したら×ボタンで閉じて「次へ」ボタンをクリックします。
・「はい、このプログラムのこの設定を保存します」を選択します。
・「閉じる」ボタンでトラブルシューティングツールを閉じます。
【手順その２】：レジストリを書き換え旧バージョン動作環境に変更する
3-3. OS 観点 – Windows OS の NLS バージョンを 6.3 から 6.2 に変更する
問題の発生しない NLS バージョン 6.2 (以前の OS で利用されていたバージョン) を利用することで本問題は発生しません。レジストリを変更して対処する必要があります。
<レジストリ NLS\Version の値の変更手順>
- 以前の NLS バージョンに戻す場合 (Access のエラーを回避する)
キー : [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Sorting\Versions]
名前 : 既定
値 : 0006020F
コマンド) REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Nls\Sorting\Versions /ve /d 0006020F /f
※管理者として起動したコマンドプロンプトで実行ください。
【手順その３】：今後のことを考え、Accessフォーム名を半角カタカナ（拗音促音）をやめて全角にする^^;
最初に起動するフォーム名を昔から、「 i_ｽﾀｰﾄｱｯﾌﾟ 」という名称で作成しておりました^^;
これが 「半角ｶﾀｶﾅ」＆「゜」までつく始末^^;
※言い訳ですが、仕事柄ｶﾀｶﾅが多く(決して英単語じゃない^^;）表示数を稼ぐための慣習が仇となってます(´・ω・｀)
で、ジジイは考えるのが面倒なので、そのまま全角カタカナの「 i_スタートアップ 」に変更。
以上の作業手順で、Access2013/2016環境で動作する自社開発アプリはWindows10 20H2環境でも、 ひとまず動作 する事となりました。めでたしめでたし。
上記の手順１〜３を実行し、Win10 20H2の状態で、Access2013が動作しました。（一安心）
半角カタカナのフォーム名の^^;修正が終われば、元のレジストリ設定に戻し、他PCでも動作を確認し、作業は終了です。
たいてい週明けって何かおこるんですよ(´・ω・｀) それにしてもWindows10をはじめMS-Accessは奥深い^^;
※今後MS様は本件を改善するつもりはないので^^;ユーザ側で対応するのみです。
更新した Windows10 20H2(2020年10月更新版）
そこには、とんでもない罠がありました(´・ω・｀)
今まで更新すると、
日本語入力が変になったり、社内の特定NASにアクセスできなくなったりと、
Windows10の更新には毎度恐怖を感じておりましたが、またもや出てしまいました。^^;
当方、 Windows10 2004(20H1)については上記問題が発生し、1909に戻した苦い経験がありました。
喉元すぎればなんとやらで、今回はまあ、枯れてきたから大丈夫じゃね？(*^_^*)
って気持ちで更新したら、でました！(´・ω・｀) Accessで開発した業務アプリが見事全滅・・・
すぐに グーグル先生 に助けてもらったら、
Windows 10 バージョン 2004 (20H1) / 20H2 上で 半角カナのフォームを含んだ Access ファイルでエラーが発生する (；´∀｀) ※
という事象がWindows10 2004(20H1)/20H2で発生することが確認できました。(´・ω・｀)
対策方法は、コマンドプロンプト（管理者）で、上記サイトのコマンドのコピペでとりあえず動作できましたが、MS様は改善する気はなさそうです(´・ω・｀)
以下、MS様のコピペですが、復旧までの手順をメモ・・・
【手順その１】：互換性トラブルシューティングを実行
※設定変更方法 (MSI版 Office の場合。詳細は MS様のココ を確認してください^^;）
・エクスプローラー上から、MSACCESS.EXE を右クリックし、「互換性のトラブルシューティング」を選択します。
・「推奨設定を使用する」を選択する。
・Windows 互換モード : Windows 8 となっていることを確認し「プログラムのテスト」ボタンをクリックします。
・Access アプリケーションが起動したら×ボタンで閉じて「次へ」ボタンをクリックします。
・「はい、このプログラムのこの設定を保存します」を選択します。
・「閉じる」ボタンでトラブルシューティングツールを閉じます。
【手順その２】：レジストリを書き換え旧バージョン動作環境に変更する
3-3. OS 観点 – Windows OS の NLS バージョンを 6.3 から 6.2 に変更する
問題の発生しない NLS バージョン 6.2 (以前の OS で利用されていたバージョン) を利用することで本問題は発生しません。レジストリを変更して対処する必要があります。
<レジストリ NLS\Version の値の変更手順>
- 以前の NLS バージョンに戻す場合 (Access のエラーを回避する)
キー : [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Sorting\Versions]
名前 : 既定
値 : 0006020F
コマンド) REG ADD HKLM\SYSTEM\CurrentControlSet\Control\Nls\Sorting\Versions /ve /d 0006020F /f
※管理者として起動したコマンドプロンプトで実行ください。
【手順その３】：今後のことを考え、Accessフォーム名を半角カタカナ（拗音促音）をやめて全角にする^^;
最初に起動するフォーム名を昔から、「 i_ｽﾀｰﾄｱｯﾌﾟ 」という名称で作成しておりました^^;
これが 「半角ｶﾀｶﾅ」＆「゜」までつく始末^^;
※言い訳ですが、仕事柄ｶﾀｶﾅが多く(決して英単語じゃない^^;）表示数を稼ぐための慣習が仇となってます(´・ω・｀)
で、ジジイは考えるのが面倒なので、そのまま全角カタカナの「 i_スタートアップ 」に変更。
以上の作業手順で、Access2013/2016環境で動作する自社開発アプリはWindows10 20H2環境でも、 ひとまず動作 する事となりました。めでたしめでたし。
上記の手順１〜３を実行し、Win10 20H2の状態で、Access2013が動作しました。（一安心）
半角カタカナのフォーム名の^^;修正が終われば、元のレジストリ設定に戻し、他PCでも動作を確認し、作業は終了です。
たいてい週明けって何かおこるんですよ(´・ω・｀) それにしてもWindows10をはじめMS-Accessは奥深い^^;
※今後MS様は本件を改善するつもりはないので^^;ユーザ側で対応するのみです。
