Excelアプリの配布方法の検討

ExcelVBAで作成したシステムをサーバーに最新をおいて、みんなでそこにショートカットを、などというやり方もできるのかもしれないが、誰が何をするか分からないのでお勧めできない。

安定稼働を考えると、ExcelVBAのシステムはクライアント側に配布される必要がある。

そこで配布方法を考えることにしよう。

ユーザーにバージョンアップ作業などの、よけいな手間をかけさせないことが肝要であろう。

そのために、次のような方策をおすすめする。

・ユーザーは起動ツールを使って起動する。

・起動ツール内で最新版モジュールを取得し、起動するようにする。

ただし、同一LAN／WAN内で、外部ネットワークを経由しなくても、すべてのPCがつながっている場合ならcopyコマンドなどで済むが、相互がつながっていない場合や外部ベンダーが開発している場合など、外部を経由しないといけない場合はFTPサイトなどを用意する必要がある。

ネットワーク環境がないなら配布ツールなどで、なるだけ簡単に済むようにするべきである。CD-ROMに保存してAutorunを使う、なども手である。

こういった使い勝手は運用を始めてから初めて分かる場合が多いが、Excelを使ったシステムを開発すると決まった時点でステークホルダーに確認できた方がいいだろう。外部ベンダーならこれも提案力の一つであろう。

コンパイル時の謎のエラー その２

先日コンパイル時の謎のエラー という記事を書いたが、その続報。

どうやら「クラスモジュールを多用している」からでは？という感がある。

仮説として、２つある。

１つは、VBの流れを汲むVBAは元々スタティックな言語であるが、無理矢理？クラスモジュールの概念を導入している感があり、コンパイラがダイナミックに呼び先を解決するようなことはあまり得意ではないのではないか？というもの。

もう１つは、クラスを生成せずに参照すると当然実行時にエラーが出るのだが、コンパイル時にもチェックし、クラス生成していないがためにエラーがわんさか出て想定しているエラー数をオーバーするのでは？というもの。

他にもあるのかもしれないが、実行させていて１つエラーを解決するとまともにエラーが出てくるようになったりするところをみていると、あながち上記でも的はずれではない気がしている。

SQL Server 名前付きインスタンスの怪

サーバーを SV とすると、通常は SV のSQL Serverに接続すればよいが、例えばバージョンの異なるSQL Serverを１台にインストールすると、SV\SQL2000 とか SV\SQL2005 とか、サーバー名に識別名を付けて区別する。
こういうのを名前付きインスタンスというそうだ。

この名前付きインスタンスで、よく分からない事象が出ている。
VBで作成したプログラムで、この名前付きインスタンスのDBにアクセスできないのだ。調べるとMDACのバージョンだ、DBが動いているか、などいろいろ書いていた。
しかし、同じクライアントから同じバージョンのADOを参照設定しているにもかかわらず、VBAからだとアクセスできるのだ。
ちなみにVBは6.0 SP6、VBAはExcel2003 SP2 である。

調べるのが嫌になったので放置しているが、ご存知の方はコメントをお寄せいただきたい。