エクセルのVBAで販売実績データをプログラミングする事になった（その４）の続きと言うか、エクセルの欠陥と言うか最大の課題の話となるのかも知れない。以前エクセルの関数を利用して効率化を図ろう！の中や、エクセル（データベース関数ＤＳＵＭ関数とＳＵＭＰＲＯＤＵＣＴ関数）でエクセルのセルの型の話を掲載しているが、ＶＢＡでプログラムを組む時に、結果的にエクセルでのセルの型が最大の問題となってくる。これは、当社のデータベースでも、大きな課題となるのだが、プログラミングやセル埋め込み型関数処理を行なう上で、課題となっている。
前回、エクセルのVBAで販売実績データをプログラミングする事になった（その４）でアルゴリズムを考えても結局、業務の流れを知らないと、その処理は出来ないと言う話を掲載したが、今回もと言うかエクセルでの最大の問題は、レコードの各フィールド（つまり各セル）の、型が何になっているかに尽きる。
複数のシステムからデータを抽出できるが、大抵問題となりそうなものは、ＶＢＡの問題ではなく、データベースの構築であるが、そのデータベースの構築がなされていても、ＣＳＶやエクセルのデータにメインフレームからダウンロードした時に、その各フィールドがどの形式になるかである。当社の販売売上げシステムの各フィールドを見ていくと
- 受注番号はアルファベットが含まれので、文字列となる為、ＶＢＡでもそのセルを設定するなら、Ｓｔｒｉｎｇとなる。
- 受注番号に付く枝番（子番号：納期や納入場所が異なる為、同じ発注番号でも、分けて管理される）は、００から０１、０２と追加されるが、これはあるＤＢではＳｔｒｉｎｇであり、一方では数値（つまりＩｎｔｅｇｅｒかＬｏｎｇ）となる。
- 日付データは、日付データであるが、日付データとなっているのか？これはエクセルの関数を調べて見ると、文字型か数値型であり、ＶＢＡで処理する時には、Ｓｔｒｉｎｇか数値（ＩｎｔｅｇｅｒかＬｏｎｇ）となる。
上記は一例に過ぎないが、ＶＢＡでプログラムを組む上で、エクセルのバグに等しい数値と文字型が目で見ても区別できない、仕組みに最大の課題が残されており、これはＶＢＡを使っても同じ課題となった。
最もセルに埋め込む関数処理型と異なり、ＶＢＡでは上記を認識していればどうにでも、処理は出来ると言う事はわかった。この辺はエクセルの関数の限界でもあり、致命的バグでもあるが、それを認識してさえいれば、ＶＢＡではどうにでも処理出来る事は、関数処理との大きな差でもあるのだろう。
一番大きな事は、指定の列や行のデータを書き換える事が出来る、もちろん削除も含めてであるが、この差は余りにも大きい。
一方で、ＶＢＡでプログラムを組める人間が社内、親会社を含めてどれだけいるか？殆どいないと考えた方が良さそうでもある。
※コメント投稿者のブログIDはブログ作成者のみに通知されます