ある日突然、
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先生に尋ねるしかない!MS様公式のサポートが出てまいりましたヽ(=´▽`=)ノ
Access 2002、Office Access 2003、および Office Access 2007 のリンク テーブルでパフォーマンスが低下する当方
Access2019なんですが、共有してる
DB形式はMDBのままだし、これいけるかも!?と思って試した見たところ、
まあまあの結果がでましたので、以下メモ。
手順メモ
(1)激オソ対象の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
(2)VBAエディタでイミディエイトウィドウを開き、「TurnOffSubDataSheets」を実行
(3)実行すると、下記結果が表示 ※ここでは50個のテーブルに「サブデータシート名=なし」処理。
で、以下、
MS様の説明詳細をコピペ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秒!!←微妙^^;
80病もとい秒!に比べればまし、贔屓目で「まあまあ」ですが、
やはりこの結果は「微妙」なので「△」としました(´・ω・`)
更に調べてみると、
(1)そもそも「リンクテーブル」で対象DBを共有する使用法が邪道^^;
Accessとはいえ、ADOを駆使した、本格的な?DB構成にしないと駄目。(超意訳^^;) Accees開発サポート様
(2)ネットワークOfficeファイルを開く際に、プログラムの速度が遅い、または応答が停止する (ハングする) 場合があります。 MS様
(3)PCとか通信環境が貧弱じゃね!?(意訳^^;) MS様
とか、Access(というよりOffice製品か?)で、
速度が著しく低下する事案は、
割とメジャーな不具合なようです。(´・ω・`)(1)についてはプログラムを組み直す必要があり、
効果はてきめんでしょうが、面倒なので^^;却下(´・ω・`)
(2)は、レジストリを追加するだけだから実行済。
効果はある模様( ・ิω・ิ)
(3)は、まあ、一般論ですねぇ(´・ω・`)
【まとめ】とりあえずは、
・サブデータシートのリレーション「無効」
(TurnOffSubDataSheets 関数の実行)
(80秒→11秒)
・レジストリを追記し、ファイルキャッシュを「無効」
(11秒→8秒)
の組合せで、まあ、許容できる起動時間となりました。^^;なにか、劇的な改善方法があれば、是非教えてくださいm(_ _)m
※Access2013とか2016に戻すとかは無しで^^;
【追伸・言い訳】
あくまでも当方の環境での結果ですので、お試し頂いて効果が出なくても
当方は一切関知いたしませんので、ご容赦願いますm(_ _)m