- ベストアンサー
エクセルのデータの処理はVB?orVBA?
エクセルのデータを処理するときVBAとVBどちらで処理することが多いですか? また、処理する理由は何ですか? 自分はVBAで処理していますが、VBAだとメモリがたりなくなったり、処理に時間がかかるので困っています。 VBAで処理する理由は、はじめに学んだからです。 VBで処理するように変えようか迷っています。 教えていただけないでしょうか? よろしくお願いします。
- みんなの回答 (8)
- 専門家の回答
質問者が選んだベストアンサー
こんにちわ >エクセルのデータを処理するときVBAとVBどちらで処理することが多いですか? >また、処理する理由は何ですか? 単純に、Excelだけで済む処理を他のアプリケーションをわざわざ導入するって、費用対効果薄くなりますよね? Excelで済むなら、Excelに付属しているVBAを使うほうがスマートだと思いますよ。 なので、Excelデータの処理する場合は、圧倒的にVBAが多いと思います。 >自分はVBAで処理していますが、VBAだとメモリがたりなくなったり、処理に時間がかかるので困っています。 >VBAで処理する理由は、はじめに学んだからです。 メモリが足りなくなるってのは、相当件数のインスタンス生成等をしてるんですかね? それとも、Excel関数をびっしり散りばめてあるとか? 私の経験上、Excelで済む範囲でこういった事象に出くわした事ないです。 処理に時間がかかるのは、大抵ロジックが悪いケースが多いです。 逆にいうと、ロジックを見直す事さえできれば、飛躍して時間の短縮が望めると思います。 今までいろんな人が作ったコードを見てきましたが、大抵無駄があります。 たとえば、関数を沢山つかってて、値参照しているセルに更新をかける際、 自動計算を手動に切り替えないとか(Application.Calculation = xlCalculationManual) 画面更新を止めないとか(Application.ScreenUpdating = False) ワークシートのChangeイベントを組んでるにも関わらず、 イベントを止めていないとか(Application.EnableEvents = False) それ以外にも沢山ありますけど、大抵そういった事がなされていないが為に遅くなっています。 それにExcelのVBAって他の言語と比べても、実はそれなりに高速ですよ。 少なくとも、VB.NETとかに比べれば、機能自体制限があるので、やはり高速ですね。 VBといってるのは、VB6でしょうか? VB6は、確かに早い部類に入ると思いますが、それもやはりロジックと処理次第です。 各言語には向き不向きがあるので、実現したい目的に応じて選択するのがベストです。 ExcelとVBAだけで実現の難しい、またはAPI等をふんだんに使用する、 描画させたり、OSの機能を引き出したいというのであれば、 VBにする、または他の言語を選択するってのは有りだと思います。 ってのは、たぶん皆同じ意見だと思うので、別の角度を用意しましょうか。 Excelは何が魅力なのかって、当然優れたスプレッド機能です。 他の言語からスプレッドを用意しようと思うと、色々手間だし、 何より自分一人で作るなんて不可能に近いぐらい、Excelのスプレッドってのは、よくできています。 豊富なExcel関数郡、オートシェイプ、直感的なUI、etc...、そこにVBAによるオートメーション。 ほぼ、最強じゃないでしょうか。 つまり、ユーザーインターフェイスとして、スプレッドを使用しないで、 ユーザーフォームに各コントロールを配置して動かすってのなら、 VBにするのは、有りだと思います。 逆に、Excelのワークシートに値を入力させたい、表示したい、Excel関数を使いたいってゆうのであれば、 VBAで作ったほうが楽だと思いますよ。 んで、大抵の場合どっちも必要って結論がでるんですが、 その為のVBAだと思って使うのがいいんじゃないでしょうか? 私は、VBAをずっと使ってますが、 これはExcelでやらせるべきではないってライン引きをして、 フォームオンリーのアプリケーションにしたり、 逆に、フォームなんてほとんど使用しないで、ExcelのスプレッドとExcel関数と簡単なプロシージャで 結果を得たりしています。
その他の回答 (7)
- Siegrune
- ベストアンサー率35% (316/895)
>エクセルのデータを処理するときVBAとVBどちらで処理することが多いですか? 使い方で決めます。 データ処理の途中で手作業が入る、特に、A列とK列とBA列を見比べてCC列の値をチェックするとか フィルタかけてチェックしてフィルタを戻して処理を進めるとか、 そういう手作業をVB.Net等でさせようと思うとちょっとやりにくい。 (EXCEL自体を画面に表示すればいいんですけどね、 その画面で勝手に保存終了されたりなんかするとVB.NET側がいささか困ったことになりかねない。) 一方で、単純にEXCELファイルから、データベースに保存するだけとか、 手作業が入らないなら、VB.Net等でさせようと思いますね。 また、利用者のレベルにもよります。 なにするかわからない利用者なら、なにもさせないようにしたVB.Net等の方がいいかなと。 ま、VBAでもIEを利用したインターネット接続やODBC等によるデータベース接続など大抵のことは できるので、何がしたいかで決めることはあまりないです。 で、 >VBAだとメモリがたりなくなったり、処理に時間がかかるので困っています。 という処理をそのまま、VB.Netへもっていってもやはり同じようにメモリ不足などはおきる可能性があります。処理に時間がかかるのが、ロジックが悪くて遅い場合はどれを使っても遅いです。 例えば、最終行の判定をせずに、65535行目まで調べていたりとか・・・。 あるいは、VB.Netへもっていったら速くなったといっても、実は、画面表示していないから速いだけで VBAでも処理中の画面更新をとめたり、再計算をOffにすると実は早かったというのはよくある話です。
お礼
ありがとうございます。
- aspnet
- ベストアンサー率79% (72/91)
「エクセルでVB」とは、エクセル内蔵のVBAではなく、Visual Studioを使用したVSTO「Visual Studio Tools For Office」を使用したOfficeアプリの開発、ということでしょうか? それならば、VBAとは完全に別物で、VB.NETを使い、Excel(やWORD等)をフロントエンドにして、.NET Ftrameworkを駆使する、さまざまな機能アプリケーション、ということになります。 Windows Formの代わりに、Excel Workbookがあるようなイメージです。 VBAのような手軽さはないですが、汎用開発環境を使用するので、ライブラリやデバッガは強力で、データベースハンドリングやコンピュータ間通信、インターネット対応など、VBAでは不可能なことも全て可能になります。 大量のデータ処理をともなうアプリケーションなら、SQL ServerやAccessなどと難なくインテグレーションできるVSTOが圧倒的に有利です。役者が違う、といった感じかな。 VB.NETをある程度理解できる方なら、仕様が一時代前のVBAより、VSTOを使うべきかもしれません。 Microsoftもそちらを推奨しています。 ただし、VB.NETは完全なオブジェクト指向言語ですし、.NETフレームワークは膨大ですからそのつもりでどうぞ。 あ、あと市販の学習書などもほとんどありません。
お礼
ありがとうございます。
- ap_2
- ベストアンサー率64% (70/109)
VBとVBAって、基本的に同じモノかと…。 また、メモリも処理速度も、セル操作など、エクセル自身の機能が原因であることが多いので、外部からエクセル操作しても変わらないかも知れないです。 ・処理速度について 今時はVB/VBAもコンパイルできるので、C言語と比べても遜色ないという噂です。ただ、エクセル自体に罠があるので、「VBA 高速化」で検索してみてください。 ・メモリ不足について VBAは動的に確保メモリを増やしていくから制限はほぼない、と聞いたことがありますが…どうなんでしょうね。「メモリ不足」は、文字数オーバーなんかでも表示され、何かが溢れた/制限を超えた感じであって言葉通りの不足だとは限らないので、要注意ですよ。
お礼
ありがとうございます。
- hallo-2007
- ベストアンサー率41% (888/2115)
>エクセルのデータを処理するときVBAとVBどちらで処理することが多いですか? ほとんどの方が同じ回答だと思いますが エクセルVBAで処理します。 >また、処理する理由は何ですか? 理由は、エクセルのシートを処理するには、便利だからです。 >VBAだとメモリがたりなくなったり、処理に時間がかかる メモリ不足がでる理由を考えるべきでしょう。 1、元々のエクセルのファイルが大きくなった。 データの部分をAccessなどデータベースに移行するべき時期の可能性があります。 2、コードの中でObjectなどメモリを使用する変数をたくさん使っている。 無駄に再計算されるような関数を配置していないか エクセルの一般機能(ピボットなど)で処理できないか VBでもエクセルのVBAでも使い方次第ということです。 データが膨大な数ということであれば、データベース(Accessあるいは SQL Serverなど)を導入 する時期になったということです。 それでも、エクセルは便利なので、処理に必要なデータだけをシートに取り込んで、集計など処理を 行って、グラフ化などできますの使っています。 もちろんVBでもデータベースに接続はできます。Officeがインストールされていないパソコンからも 処理したいというのであれば、VBで開発する必要が出てくるということですね。
お礼
ありがとうございます。
- MARU4812
- ベストアンサー率43% (196/452)
VB から Excel を操作しても、実際に動くのは Excel のライブラリに登録されている 関数です。だから処理が遅いというのはプログラムが悪いのであって、VB に変えても さほど変わらないはずです。 逆に、最新の VB である VB.NET は使った Excel オブジェクトを開放してやらないと 裏で動いている Excel.EXE のプロセスが終わらない問題があります。これは、手作業で 次回、Book を開いた時に正常に表示されないという実害があります。 私は、VB6.0 の時代からプログラミングしてますので、VBA でも十分にプログラム 出来る事を知っています。VBA だけで100万件の顧客データ(CSV)の統計処理をできる プログラムを組んだ事もあります。処理時間は40分程度掛かりますが、お客さんは 十分に評価できるスピードだと判断されました。 もちろん、開発中は何回かメモリが足りなくなるエラーも表示されましたが、修正 して安定した稼動を実現しました。 私が VB と VBA の比較から VB を選ぶとしたら、コントロールの豊富さです。 フォームをベースとした処理が多い場合は、VB を選びます。 質問は、 > エクセルのデータを処理するとき ですので、どちらで開発しても同じだと感じています。 > メモリがたりなくなったり、処理に時間がかかるので これは、VB に変えても改善されないと思います。 わざわざ外部(VB)から Excel を操作するより、内部(Excel)から Excel を操作 した方が色々と便利なので、VBA を選択すると思います。
お礼
ありがとうございます。
- imogasi
- ベストアンサー率27% (4737/17069)
質問者は、 全然論点がずれている。 エクセルVBAはエクセルのシートなどエクセルのオブジェクトを使うから、用意されているメソッドやプロパティなどを使うべきものであって、そういうのと関係ない計算(例えば円周率パイの近似値を何桁計算するなど)なら使う必要は無い。 たまたまVBAのVBの部分を利用して使える場合があるというだけだし、特定目的のCOMがあると、エクセルと関係が無いことにも、VBAでも使えるということにも見えるが、エクセルVBAの領分とはいえない。 >VBで処理するように変えようか迷っています 処理する中身による。エクセルVBAで、不要なシート画面を毎度更新したりしたらVBAでもベテランに比べれば時間がかかる。処理するアルゴリズムやロジックでも、メモリの使用度合や処理時間に差が出る。初心者がVBAだとメモリが足りないとか、処理が遅いといっても、当てにならない。よく判った人がチェックしないと、ものが言えない。 配列にデータを溜め込んだりするのは、初心者に多い。昔は使えるメモリが少なく、いかに使用メモリを少なくするか苦労があった。画像を表示するなど速度の面から実用にならなかった時代も長い。最近は様変わりしているが。
お礼
ありがとうございます。
- FEX2053
- ベストアンサー率37% (7991/21373)
そりゃ確かにVBを使ってExcel外部でCOMファイルを作って動かせば速いこと速いですけど、VBじゃ直接セルをいじることは確か出来なかった筈じゃ? VBAでも「ScreenUpDating」を上手く使うと、処理速度は上がりますよ。それと、何でもかんでもVBAでやろうとしないで、Excel自体の関数を使ってセル上で可能な限り処理すると、結構速度は上がりますけど。 http://officetanaka.net/excel/vba/speed/s1.htm
お礼
ありがとうございます。
お礼
ありがとうございます。