ランダムなマクロ破損が発生し、ブックを開くことができません。
通知なしですべてのマクロを無効にしてから、ワークブックを開いてマクロを再コンパイルし、保存して閉じる必要があります。次に、マクロを有効にしてワークブックを開くと、ワークブックは正常に開きます。マクロを更新すると、ワークブックを再度開くのに役立つようです。いくつかのモジュールをチェックしましたが、いくつかは 64 KB を超えています。破損の原因となるモジュール サイズの制限に関する記事をいくつか読みました。
これは Excel 365 でも同じことなのか、マクロが破損する理由があるのか、確認した人はいますか?
答え1
64KB の制限はエクスポートされたファイルのサイズではなく、コンパイルされたモジュールの最大サイズです。
モジュールが 10K 行未満であれば、コンパイルできます。
重いがまだ健全なモジュールは、最大で1K行で、テキストファイルにエクスポートすると40KB程度になるようです。64KBは完全に不適切だとは思いませんが、はコードは間違いなく 1,000 行を超えており、多少の調整が必要になる可能性があります。
モジュールの名前がModule8または の場合はUtilities、凝集性それらのメンバーはすべて同じ機能に関連していますか? それとも、ランダムな関数がそこにダンプされたように感じますか?
重複したコードを探してリファクタリングします。メソッドを抽出し、パラメーター化して、すべての機能を維持しながらモジュールが消滅するのを見てください。
VBA コードの内部ストレージ メカニズムは、20 年間変更されていません。特に VBA は現在ほぼ固定されており、ストレージ メカニズムを変更すると、あらゆる場所で何百万ものものが壊れてしまうため、最近変更された理由はわかりません。
しかし、O365で最近何かが変更された可能性は否定できません（インサイダービルド？）、何かが壊れてワークブックが何らかの理由で破損しました...しかし、モジュールが64KBを少し超えている場合はテキストソースコード、関連している可能性は非常に低いです。プロジェクトがコンパイルされると仮定すると、コンパイルされたコードはそれよりもはるかに小さくなります。
答え2
制限は1回あたり64Kです手順引用：手順が大きすぎる
コンパイル時に、プロシージャのコードは 64K を超えることはできません。このエラーの原因と解決策は次のとおりです。
- このプロシージャのコードは、コンパイル時に 64K を超えます。このプロシージャとその他の大きなプロシージャを 2 つ以上の小さなプロシージャに分割します。
Access 2013 で 811 KB の VBA ファイルを使用しています。このファイルには小さなプロシージャがたくさん含まれていますが、問題は一度も発生していません。
したがって、OP の質問に答えると、プロジェクトのどこかに巨大なサブルーチンがある場合は、それを分割します。それ以外の場合は、報告するモジュール サイズを気にする必要はありません。