エクセルのカレントバージョン変更 [システムトレード]
1台のパソコンに複数のバージョンのエクセルをインストールしている場合、例えばVBScriptからエクセルを起動する際に、バージョンを選択する必要が生じることがあります。
例えばＫＦシステムクリエイターにおいて並列実行を行う際には、より高速なエクセル2003を使用した方が、当然、処理速度が速くなります。
しかし、これを明示的に指定することは、かなりやっかいです。いろいろと調べたところ、エクセル起動時に、末尾にバージョン番号を指定すれば良い、という解説がありました。
これは、例えばエクセル2007と2003が共存する環境において、VBScriptからエクセル2003を起動したい場合は、次のように記述すれば良いというものです。
Set objExcel = CreateObject("Excel.Application.11")
末尾の'.11'の箇所が、エクセルのバージョンを表し、この場合はエクセル2003を指します。もしもエクセル2007を起動したい場合は、末尾の数字を'12'にします。
しかし、これを実際に行なってみると、いずれの数字を指定しても、特定のバージョンのエクセルしか起動できないことが分かります。
インストールされていないバージョンの番号を指定した場合はエラーとなり、インストールされているバージョンの番号を指定した場合は、エラーにこそならないものの、常に同一バージョンのエクセルが開いてしまうわけです。
私のGatewayマシンには、エクセル2003と2007とがインストールされているのですが、VBScriptを用いた並列実行を行なうと、常にエクセル2007が開いてしまうわけです。
ご存知のように、大きくて複雑なブックに対しては、エクセル2007の起動処理は異常に遅く、エクセル2003が使える環境であればそちらを使いたいところです。
このように常に優先的に実行されるバージョンを、カレントバージョンと呼ぶようなのですが、これは通常、エクセルをインストールした順番で決定されます。
すなわち、最後にインストールしたバージョンがカレントバージョンとなり、他のバージョンよりも優先的に起動されるわけです。
一般的には、より新しいバージョンが一番最後にインストールされるわけですから、それがカレントバージョンになります。
すなわち、私のような環境では、カレントバージョンはエクセル2007になってしまうわけです。
エクセルファイルをダブルクリックした際に起動するエクセルのバージョンは、ファイルの関連付けから任意に設定できるのですが、VBScriptなどから起動されるエクセルのバージョンは、カレントバージョンに限られてしまい、通常は変更できません。
VBScriptの記述そのものを工夫して、エクセル2003を起動する方法もあるのかもしれませんが、手っ取り早くカレントバージョンをエクセル2003に変更できれば、それでも十分に目的を果たすことができます。
カレントバージョンがエクセル2003になったからといって、エクセル2007が使用できなくなるという訳ではなく、あくまで外部アプリケーションから起動されるエクセルが2003になるということであり、エクセル2003を通常用いている場合にはむしろ好都合です。
ということで、カレントバージョンをエクセル2003に変更することにしたのですが、実は、エクセルを再インストールすることなく変更が可能であることが分かりました。
それは、「アプリケーションの自動修復」を行うという方法です。
エクセル2003を開き、ヘルプメニューの「アプリケーションの自動修復」を実行すると、カレントバージョンをエクセル2003に変更することができます。
これは、アプリケーションの自動修復という作業が、エクセルの再インストールと同等であるためと考えられます。
すなわち、アプリケーションの自動修復を実行することで、最後にインストールしたエクセルのバージョンを、自動修復したエクセルのバージョンに変更できるわけです。
これによって、エクセル2007がインストールされた環境でも、エクセル2003をカレントバージョンにすることができます。
何はともあれ、これでGatewayマシンにおいて4つの自動実行マクロを並列実行した際に、4つのエクセル2007が起動してしまうという問題を回避することができました。
4つのエクセル2003上で、それぞれ21個（計84個）のシステムのセットアップから最適化、性能一覧作成までを自動実行してみました。
詳細結果については後日ご報告いたしますが、それらの処理が全て完了するのに要した時間は、丁度2時間ほどでした。
これは、1システム当り86秒（1分26秒）ほどで処理が完了したことを示します。今まで一晩以上掛かっていた処理が、クアッドコアの寄与もあるとはいえ、大幅に短縮されたわけです。
なお、並列実行時のセットアップマクロにおいて、基準（元）システム読み込みの際に確認メッセージが出て、処理が中断してしまうという問題が見つかりました。
これについては、改定版セットアップマクロを明日中に公開する予定です。
例えばＫＦシステムクリエイターにおいて並列実行を行う際には、より高速なエクセル2003を使用した方が、当然、処理速度が速くなります。
しかし、これを明示的に指定することは、かなりやっかいです。いろいろと調べたところ、エクセル起動時に、末尾にバージョン番号を指定すれば良い、という解説がありました。
これは、例えばエクセル2007と2003が共存する環境において、VBScriptからエクセル2003を起動したい場合は、次のように記述すれば良いというものです。
Set objExcel = CreateObject("Excel.Application.11")
末尾の'.11'の箇所が、エクセルのバージョンを表し、この場合はエクセル2003を指します。もしもエクセル2007を起動したい場合は、末尾の数字を'12'にします。
しかし、これを実際に行なってみると、いずれの数字を指定しても、特定のバージョンのエクセルしか起動できないことが分かります。
インストールされていないバージョンの番号を指定した場合はエラーとなり、インストールされているバージョンの番号を指定した場合は、エラーにこそならないものの、常に同一バージョンのエクセルが開いてしまうわけです。
私のGatewayマシンには、エクセル2003と2007とがインストールされているのですが、VBScriptを用いた並列実行を行なうと、常にエクセル2007が開いてしまうわけです。
ご存知のように、大きくて複雑なブックに対しては、エクセル2007の起動処理は異常に遅く、エクセル2003が使える環境であればそちらを使いたいところです。
このように常に優先的に実行されるバージョンを、カレントバージョンと呼ぶようなのですが、これは通常、エクセルをインストールした順番で決定されます。
すなわち、最後にインストールしたバージョンがカレントバージョンとなり、他のバージョンよりも優先的に起動されるわけです。
一般的には、より新しいバージョンが一番最後にインストールされるわけですから、それがカレントバージョンになります。
すなわち、私のような環境では、カレントバージョンはエクセル2007になってしまうわけです。
エクセルファイルをダブルクリックした際に起動するエクセルのバージョンは、ファイルの関連付けから任意に設定できるのですが、VBScriptなどから起動されるエクセルのバージョンは、カレントバージョンに限られてしまい、通常は変更できません。
VBScriptの記述そのものを工夫して、エクセル2003を起動する方法もあるのかもしれませんが、手っ取り早くカレントバージョンをエクセル2003に変更できれば、それでも十分に目的を果たすことができます。
カレントバージョンがエクセル2003になったからといって、エクセル2007が使用できなくなるという訳ではなく、あくまで外部アプリケーションから起動されるエクセルが2003になるということであり、エクセル2003を通常用いている場合にはむしろ好都合です。
ということで、カレントバージョンをエクセル2003に変更することにしたのですが、実は、エクセルを再インストールすることなく変更が可能であることが分かりました。
それは、「アプリケーションの自動修復」を行うという方法です。
エクセル2003を開き、ヘルプメニューの「アプリケーションの自動修復」を実行すると、カレントバージョンをエクセル2003に変更することができます。
これは、アプリケーションの自動修復という作業が、エクセルの再インストールと同等であるためと考えられます。
すなわち、アプリケーションの自動修復を実行することで、最後にインストールしたエクセルのバージョンを、自動修復したエクセルのバージョンに変更できるわけです。
これによって、エクセル2007がインストールされた環境でも、エクセル2003をカレントバージョンにすることができます。
何はともあれ、これでGatewayマシンにおいて4つの自動実行マクロを並列実行した際に、4つのエクセル2007が起動してしまうという問題を回避することができました。
4つのエクセル2003上で、それぞれ21個（計84個）のシステムのセットアップから最適化、性能一覧作成までを自動実行してみました。
詳細結果については後日ご報告いたしますが、それらの処理が全て完了するのに要した時間は、丁度2時間ほどでした。
これは、1システム当り86秒（1分26秒）ほどで処理が完了したことを示します。今まで一晩以上掛かっていた処理が、クアッドコアの寄与もあるとはいえ、大幅に短縮されたわけです。
なお、並列実行時のセットアップマクロにおいて、基準（元）システム読み込みの際に確認メッセージが出て、処理が中断してしまうという問題が見つかりました。
これについては、改定版セットアップマクロを明日中に公開する予定です。
コメント 0