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
【このカテゴリーの最新記事】
- no image
- no image
-
- no image
