ひげおやぢの備忘録

お久しぶりです。
超不定期投稿、まさに爺ぃの備忘録である本サイトですが、

恥ずかしながら？^^;以前の記事で紹介しました事案がまた発生しました(´・ω・`)

で、その時は別の方法で解決したのですが、なんと、MS様公式に解決方法が掲載されておりました！


Microsoftコミュニティ　Accessでレポートの罫線が消える


※当方PC環境 Win11Pro OSビルド 22000.795 + Access2019(x86)


皆様も苦しんでおられる様子・・・(´・ω・`)

MS様は月イチのペースでWindowsを自動更新するのですが、本当にオソロしいです(´・ω・`)

毎日暑いですねぇ(´・ω・`)

そんな中、背筋も凍る（大げさ）な事案が、
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様・・・^^;

タグ：ACCESS不具合,ACCESSレポート罫線消える

月曜日、色々あるんです。^^;

出社後、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アプリ激オソ起動改善とどのような因果関係があるのか、
当方にはお恥ずかしながら全く理解できないです(*ﾉω・*)ﾃﾍ

まぁ、結果オーライ(死語か？^^;）ということで、良しとします(*^_^*)


ＰＣ環境限定とはいえ、月曜日に久々嬉しい事が起こりました。ヽ(=´▽`=)ﾉ

ある日突然、

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: Access2016(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ファイルを開き、上記モジュールをコピペ

1. Sub TurnOffSubDataSheets()


2.     Dim MyDB As DAO.Database


3.     Dim MyProperty As DAO.Property


4.     Dim propName As String, propVal As String, rplpropValue As String


5.     Dim propType As Integer, i As Integer


6.     Dim intCount As Integer




8.     On Error GoTo tagError




10.     Set MyDB = CurrentDb


11.     propName = "SubDataSheetName"


12.     propType = 10


13.     propVal = "[None]"


14.     rplpropValue = "[Auto]"


15.     intCount = 0




17.     For i = 0 To MyDB.TableDefs.Count - 1


18.      If (MyDB.TableDefs(i).Attributes And dbSystemObject) = 0 Then


19.      If MyDB.TableDefs(i).Properties(propName).Value = rplpropValue Then


20.      MyDB.TableDefs(i).Properties(propName).Value = propVal


21.      intCount = intCount + 1


22.      End If


23.      End If


24.     tagFromErrorHandling:


25.     Next i




27.     MyDB.Close




29.     If intCount > 0 Then


30.      MsgBox "The " & propName & " value for " & intCount & " non-system tables has been updated to " & propVal & "."


31.     End If




33.     Exit Sub




35.     tagError:


36.     If Err.Number = 3270 Then


37.      Set MyProperty = MyDB.TableDefs(i).CreateProperty(propName)


38.      MyProperty.Type = propType


39.      MyProperty.Value = propVal


40.      MyDB.TableDefs(i).Properties.Append MyProperty


41.      intCount = intCount + 1


42.      Resume tagFromErrorHandling


43.     Else


44.      MsgBox Err.Description & vbCrLf & vbCrLf & " in TurnOffSubDataSheets routine."


45.     End If


46. 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

そろそろ塩梅も良くなってきたか？っと思って

更新した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様は本件を改善するつもりはないので^^;ユーザ側で対応するのみです。