Excel VBA 質問スレ Part59

2019/02/09(土) 15:12:30.70

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512

ExcelのVBAに関する質問スレです
コード書き込みや作成依頼もOK
※前スレ
Excel VBA 質問スレ Part58
https://mevius.5ch.net/test/read.cgi/tech/1542577644/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2019/03/10(日) 19:41:28.13

3つのエクセルファイル開いて終わったら
3つともcloseしてquiteしてるんだけど
タスクマネージャみたら3つのエクセルがのこったまま
なんでー？

2019/03/10(日) 19:46:40.37

ういるすじゃね

2019/03/10(日) 19:57:44.50

>799
20代前半？

2019/03/10(日) 20:53:30.17

>>804
プロセスが残ってるってことだよね？
3つのエクセルファイル開く前はプロセス0個だった？
closeしてquiteしてるオブジェクトはちゃんと合ってる？

2019/03/10(日) 22:01:10.58

>>803
いわゆるそれなりの企業でOfficeを個々の部署で買ってるところってそんなにないだろ

2019/03/10(日) 22:37:21.73

>>808
ウチの場合各部署の上長に選択肢与える方式だから
Publisher使う広報部以外Professional選ぶとこほとんどないよ

2019/03/10(日) 23:03:17.67

>>802
論点の分かってないバカは何処にでもいるな。
つまり結論は、Access使ってるということだよ。

それにAccessと比較できるようなソフトが無い。
それが分からんからセンスがね―と言われる。
FileMaker挙げられたら分かってる奴だろうが。

>>803
そりゃ残念だったな。
Officeは部署で買うもんじゃ無いと思うぞ。
聞いたこと無いけど。
うちの会社は全員Access入ってると思うぞ。

2019/03/10(日) 23:04:10.67

>>801
センスが悪いのは対抗に成りようがないもんを挙げてるからだよ。

2019/03/10(日) 23:13:37.64

>>809
個々に発注してるの？
ボリュームライセンス使わないの？

2019/03/11(月) 00:05:51.48

AccessやめてSQLServerにしろって言われて移行の手間以外の理由で嫌がる人間がいるだろうか？
いや、いない

2019/03/11(月) 00:06:57.17

なんか他人を見下したいだけのタイプっぽくてウザいからNGしたわ
仮にこいつがAccess詳しくてもこいつから教わりたくないなって感じ

2019/03/11(月) 00:09:57.12

ＶＢＡより細かいことができて簡単でメジャーでお勧めってＪＡＶＡでいいの？
用途は個人で簡単なアプリを作る程度です。

2019/03/11(月) 00:11:11.53

Access取り上げられてManagement Studio渡されたらうにょる

2019/03/11(月) 00:12:43.40

>>813
SQLサーバーにするようなのは手間もそうだが、規模が違うだろ。
そんな話になるなら最初からExcelやAccessの話になんてなってない。

そんなこともわからね―のかよ。
自由にできる中小とは違うんだよ。

2019/03/11(月) 00:16:15.83

>>815
それは微妙だな。
細かいことは出来ない場合がかなりあるだろうな。
簡単かどうかも微妙。
難しさの方向性も違うし。

2019/03/11(月) 00:21:09.07

>>816
問題は何で組むかって話になるだろうね。
昔、MSDEで組んでた時に使ってたけど、Accessなんか競合するようなもんじゃない。
まあ、VBAでも組めるからExcelやAccessから繋いでも良いんだけど、それって本末転倒じゃね?

結局VisualStudioで組む話に成るんだろうな。

2019/03/11(月) 07:05:51.99

>>813
馬鹿はエンジン部分だけしか見ていない

2019/03/11(月) 07:19:27.24

>>813
想定の範囲内でしたね
Access以上に帳票作成が楽なソリューション出してください
あなたならできるはずです
あっ、もちろんコストは想定の範囲内でお願いしますよ

2019/03/11(月) 09:28:28.62

>>821
ExcelからSQLServerのデータをつつけばいいじゃん
このスレ的にも趣旨にあう

2019/03/11(月) 10:13:10.23

印刷に難のあるExcelで帳票作成？
わざわざ茨の道を進む提案は想定の範囲外でしたよ
次回からもう来なくていいですw

2019/03/11(月) 10:35:34.29

>>823
帳票？印刷？
そんなもんPCでやるわけないでしょ
君こそふざけてるんじゃないの？

2019/03/11(月) 10:49:41.28

>>824
えっ？

2019/03/11(月) 10:57:18.05

>>825
帳票印刷なんて古い基幹システムでやるもんだし、レガシーでつまんない仕事だからPCでやりたくないでしょ

2019/03/11(月) 11:09:41.27

>>824
一体何を言ってるんだろう… w

2019/03/11(月) 11:11:45.09

>>826
お前さん、例えばスマホとか契約した時に契約内容を記載した紙貰ってないかい？
帳票ってそう言う奴のことな

2019/03/11(月) 11:17:50.98

>>828
それをPCのアプリで出力しないでしょ？
現場のPCでやるのは出力された帳票イメージをプリンタに送ることさ

2019/03/11(月) 11:33:05.59

まあホスト側でPDFを作っちゃって、あとは印刷するだけみたいなシステムも最近は増えてるけど、
送られて来るのは印刷したい数字だけで、クライアント側で印刷イメージを組み立てるシステムだって普通にあるぞ

2019/03/11(月) 11:34:08.24

それにそんなことは営業所レベルのことじゃない？

**デフォルトの名無しさん** (ｽﾌｯ Sd32-2wIc) · 2019/03/11(月) 11:44:06.02

>>831
ここは大企業やサーバ管理者専用スレじゃないし
世の中にはパソコン1台だけで経理や発注をやってるような中小零細だってある
現実にExcelで作られた帳票は世界中を駆け巡ってる

2019/03/11(月) 12:22:04.66

>>829
お前一度帳票ソリューションとかでググってみ
いろんな形態あるから1種類だけで語ると恥かくぞ

2019/03/11(月) 12:56:27.77

>>823
印刷は確かに若干弱いがエクセル帳票は悪くないアイデアだと思う
プログラムで生成物からデータを取得できるから帳票作成のスモールテストを作りやすい
まあCIサーバーで動かないと意味がないのでVBAの出番はないけど

2019/03/11(月) 13:13:58.34

>>833
世の中全体なんて言ったらきりないでしょ
>>828が言うDOCOMOショップとかの話に反論したのさ

2019/03/11(月) 17:10:59.27

>>835
「例えば」っていう文言すら理解できないの？w
てか、話の流れでわかるだろ

2019/03/11(月) 18:08:31.25

>>836
いやいやいやいや
「帳票なんて基幹システムで出すもんでPCじゃしないでしょ」という意見に対して>>828は携帯ショップの例を出してきたんだぞ

2019/03/11(月) 18:36:20.35

>>824
ガリ版印刷かと思った

2019/03/11(月) 18:37:23.11

言わんとする事は分かるけど、
ID:tsrenNBW0 は色々と日本語おかしいぞ
入って半年の新人か、酔っぱらいが話ししているようだ

2019/03/11(月) 18:39:03.34

>>834
Excelはページ内の列に縛られるから結構大変だよ
見積書とかでお客様名称の位置を変えたら一覧表に影響するとか
特に複数の表を位置ページに収めるとかが大変すぎる

2019/03/11(月) 18:39:39.43

>>840
位置ページ ⇒ １ページ

2019/03/11(月) 18:40:36.46

>>837
そこまで言うならすべての携帯ショップの帳票システムが１種類しかないことをソース付きで示してくれ

2019/03/11(月) 18:40:41.61

>>837
帳票は基幹システムでも出すし、現場のAccessからも出します。
携帯ショップのはあくまで例えだが、アプリで出してても何らおかしくない。webからサーバで作成した帳票出してたとしても世の中全てがそうじゃない
バカはすっこんでろ

2019/03/11(月) 18:48:10.82

>>843
ああ、じゃ携帯ショップの話は例が悪かったってことで引っ張るのはやめにするよ

2019/03/11(月) 18:52:52.30

もともとAccessなんかよりSQLServer使えばいいのに、という意見に対して「センスが悪い」と評したやつがムカつくんだよね

それってただの自己擁護じゃねえの？

2019/03/11(月) 18:57:56.68

>>845
ExcelVBAスレで何言ってんだって話だよな

2019/03/11(月) 19:19:43.98

まーまー、みんなケンカするなよ。ケンカしたくてここに来てるやつはどっか行ってくれ。楽しく、とまではいかないにしても、他人の意見を尊重して、まったりと行こうぜ

2019/03/11(月) 19:25:03.45

VBAスレでイキる奴も煽られる奴もダサすぎ

2019/03/11(月) 20:02:00.38

他人からファイルが返ってきたときに印刷プレビューになってるとイラっとする

2019/03/11(月) 20:41:29.39

そんな性格だから禿げたんだな

2019/03/11(月) 20:46:16.50

>>849
自分はそれじゃなくてアレがイラッとする
だからよく ActiveSheet.DisplayPageBreaks = False
をやる

2019/03/11(月) 21:21:38.01

>>845
最初に「今Accessを使う意味」とか、言い出した奴が都合が悪くなると人のことを上から目線だとか言い出すからなあ。

そもそもの話はAccessにしちまうからExcelでDB処理することは多く無いって話から始まっている。
(実際は結構あるけどAccessと食い合うって話)

最初から、バックエンドSQLサーバーでフロントがExcelって話なら、SQLサーバーじゃなくて正にExcelでDB処理の話になって、俺の主張に一致するから反論にならん。それとも絶対にExcelフロントでAccessフロントはあり得ないって話ならもう一度センスね―と言ってやる。
Excelフロントはあり得るけどAccessフロントの方がよりあり得るわ。

いやいやそういう構成ではExcelでDB処理には該当しないというなら、ExcelでDB処理とはExcel単体でのDB処理ということになるから、それに対しての比較対象にSQLサーバー持って来たの?という話になる。
この場合もやっぱりセンスね―と言ってやる。

だからそもそもの話に反論としてSQLサーバーを挙げるってことはExcelフロントではないということを意味するんだろう。
つまりOffice系では無く、開発系で組むという話だろう。
Accessで済むようもん、場合によってはExcelで済むようもんをC#とかを使って組むの?

部署内での打ち合わせ資料をWordで作ると言ったらPagemakerの方が良いと言われた気分だわ。

2019/03/11(月) 21:56:59.54

accessが好きとか嫌いとか最初に言い出したのは誰なのかしら

2019/03/11(月) 22:03:37.96

>>852
3回読んだが意味がよく分からん
俺の最初の主張は>>729から始まってるんだが、「データはExcelじゃなくてAccessに置け」という他の意見に対して
「いや今時AccessなんかじゃなくてSQLServerでしょ」というのが意図だ。
そっからなんかこじれてるんだが、ここでの俺の前提はフロントUIはエクセルというものなんだよね。
ExcelからのSQL発行という点でUI表面上の差が大してないと考えて比較している。

2019/03/11(月) 22:45:47.44

>>854
馬鹿は死ねよ

2019/03/11(月) 23:03:46.33

>>854
フロントがExcel程度でなんとかなるデータならAccessで十分だろ
すでに大量のデータがSQLServerに溜まっているならそっち使えばいいけど
Excelでデータ入力とか考えただけでも吐きそう

2019/03/11(月) 23:17:24.96

まだやってんのかよ

2019/03/11(月) 23:24:53.12

>>856
フロントでやるのはデータ分析だろう。
データ入力は現場の仕事。
フロントと現場を混同してるだろ？

2019/03/11(月) 23:31:06.64

二人以上でAccess使うなんて想像してなかったわ。すまん

2019/03/12(火) 01:08:58.03

>>858
データ入力画面もフロントだよ。
現場でどうデータ入力させようとしてるのか書いてみろよ。

2019/03/12(火) 01:16:33.47

あの～そろそろ～

2019/03/12(火) 01:28:26.03

ID:tsrenNBW0

馬鹿は早く死ねよ

2019/03/12(火) 01:58:18.19

端から見てると何でこの人たちがVBAやらされる羽目になってるのか分かるよね

2019/03/12(火) 06:19:34.26

むしろこんな奴等に何かやらせる羽目になってる上司に同情するわ

2019/03/12(火) 07:21:53.89

弊社では無理です

**デフォルトの名無しさん** (JP 0H6e-q+B7) · 2019/03/12(火) 07:54:30.64

2日ぶりに覗いたらまだ同じ話してて草

2019/03/12(火) 08:15:48.17

うちなんかSQLServer導入して部署内誰でも使えるようにセッティングしてるのにずっとAccess使い続けてる。
Excel VBAからADOで繋げてるパターンなんで移行は手間じゃないと思うんだけど2～3人が試しに使い始めただけ。
思い通りになんていかないよ。
社内稟議通した人がお気の毒w

2019/03/12(火) 08:18:57.13

>>854
八ァ?
>>729から始まってるんだよな。
その前に「デ―タはExcelじゃなくてAccessに置け」なんて意見が何処にある?
>>729の前にAccessのことを言ってるのは>>728しか見当たらないんだが。

で、俺が言った>>728は別に「デ－タはExcelじゃ無くてAccessに置け」なんて言って無いんだが。
誰かにこうしろ等と言って無いし、データをAccessに置く等と限定してないぞ。

その上、「今時Access」?
お前は一体何様だよ。
どっちが上から目線だ?
上から目線でも回答が頓珍漢じゃなければセンスね―なんて書かね－よw

2019/03/12(火) 08:24:06.51

>>867
それはちょっと悲しいね。
まあ、ファイル単位で移動出来るメリットもあるからDBサーバーあってもAccess単体ってのもあり得るけどな。

2019/03/12(火) 10:47:16.64

>>867
それはね、ローカルに置いてる（としとこう）Accessの中に人に見せられないデータがあるからだよw

2019/03/12(火) 12:45:42.87

>>867
そもそもそれエンジンの話なのか帳票とかのデザインの話なのかはっきりしてくれ
あと人は今困ってないなら移行なんてしないよ、トラブル招くかもしれないしな
移行させたいならAccess使用禁止ぐらいしないとダメ
どうせ導入した奴もそこまで腹くくってないだろ

2019/03/12(火) 13:22:50.41

>>870
本当にあったりしてなw

2019/03/12(火) 15:31:02.26

>>867
SQLサバだとテーブル設計とか後からいじりにくいんだよな
連結フォームに全データ表示！とかも気楽に出来なくなるし

2019/03/12(火) 18:07:30.07

>>867
もしかしてクライアントサイドの管理ツールとか知らないのでは？

2019/03/12(火) 21:59:22.23

>>871
テーブルを移行して欲しいんだけどやってくれないって状況
導入した人は権力があるのでそのうち強制するかも

2019/03/12(火) 22:19:10.50

>>875
移行するメリットがないとねぇ
レコード数が少ないと速度なんてほとんど変わらないし…
100万レコードでも、きちんと作られてればAccessでも十分実用になるし…

まずは、めちゃ処理時間がかかるやつ一つを移行。ストアド作り込んで速くなるのを見せるとか。
せっかくSQLServer使うなら、ストアド使わないと勿体ない。ただレコード持ってるだけの箱になってしまう。
ストアドはとっつきにくいと思うが、レコードをこねくり回すような時間かかる処理には効果絶大。

逆に言うと、軽いデータや処理のmdbは移行後回し。（というより、そんなの移行しなくてよろしい。労力に見合わない）

2019/03/12(火) 22:41:48.72

>>876
いきなりストアドで大規模ロジックを書こうとしても、どう書くべきか（どう書くのがふさわしいか）わからないと思う。
小ロジック大量レコード処理辺りから書いていきましょう

2019/03/12(火) 22:50:26.01

>>876
自分含め誰もspとか知らない
一般的なプログラミングは割とできて、みんなVB/VBA、C#、C++、rubyとかでなんとかしようとしてる
まさにDBを箱としか見てない

2019/03/12(火) 23:05:56.66

ストアドはRDBの設計思想に反する邪悪な存在なので可能な限り避けるべきです
最適化をかけにくいのでインデックスの効いたクエリに比べて速度も遅くなります

2019/03/12(火) 23:30:38.78

>>879
マジで！？

2019/03/12(火) 23:43:55.90

Webシステムで全て開発側の手元にあるんならストアドなんか害悪しかないけど、
VBAだったらストアドやビューを最大限に活用して可能な限りDBMS側に寄せるべき
神VBAは作りっぱなしで逃げられるならいいけど、後々Excel側の変更やDB側のスキーマ変更で地獄を見ることになる

2019/03/12(火) 23:46:34.37

ExcelからAccessのデータを取得するきはこういうコードをクラス化してAccess立ち上げる必要ないようにした。
http://www.asahi-net.or.jp/~ef2o-inue/vba_o/sub05_130_030.html
他言語使ってる人の事情は知らんけど似たような感じだと思う。
SQLサーバ向けのもADOだからインターフェース変えずにできた。
せっかくツールったんだから移行しろよ！
と思ってたけどもう何がいいのかわからんくなった。

2019/03/13(水) 00:27:28.10

>>875
それエンジンだけをすげ替えろって言ってるってことだよね？
そりゃわざわざ移行しないよ
メリットないから強権発動しかないと思うよ

2019/03/13(水) 00:29:37.94

>>880
>>879はなんか勘違いしてるだけ
ストアドは簡単に言うとサーバー側でロジックが動くだけの話だからインデックスが効くかどうかはストアドが発行するSQLに依存する

2019/03/13(水) 00:41:34.27

>>884
879が批判してるのは、ストアドの中でループしたり一時テーブルを安易に多用したりするような使い方じゃないのかな

2019/03/13(水) 00:41:51.32

>>882
そのめんどくさいselect文を作るのがaccessやssmsじゃね？

2019/03/13(水) 00:46:32.81

>>884
インデックスが効かないとは言ってませんが？

SQLなら期待される結果を返す範囲で最適化して高速化する余地があります
これはSQLが宣言的な言語だからできることです
最終的な答えが同じなら途中の結合や絞り込みを入れ替えたり省略することが可能です

逆にストアドは手続き型なので基本的に定義した順に処理が逐次実行されます
全く最適化できないわけではありませんが宣言的な言語と比べるとこの順序があるという性質のせいで制約が強く最適化のかかりが弱くなります

2019/03/13(水) 00:50:37.91

>>887
理念には同意するけど、VBAスレでそれ言う？
Excel VBAこそ、本来は宣言型であるものを手続き型に落としてしまいパフォーマンスを低下させている例の最たるものだよ

2019/03/13(水) 00:52:52.41

>>885
変な使い方を前提にストアドが遅いとか言われても困る

2019/03/13(水) 00:55:59.30

>>889
実際、ぐるぐるSQLを書いちゃうような人はDBに寄せた設計になるとストアド使いたがるからね

2019/03/13(水) 00:57:03.71

>>887
だからその逐次実行を行うのがクライアントなのかサーバーなのかが違うだけでしょ
そりゃストアドと単一のSQL比べたらストアドの方が遅いだろうけどクライアントが同様の処理すること思えば全体としては（ちゃんと設計されてりゃ）速くなるでしょ

2019/03/13(水) 00:59:49.50

>>891
SQLをコンパイルする必要がないからストアードの方が速くね？

2019/03/13(水) 01:13:08.97

>>892
理論的にはそうだけど、現実にはそこは全く関係ない
SQLのコンパイル時間はサーバーとの通信のコストと比較すれば無視してよい

2019/03/13(水) 01:22:09.36

そもそもSQLの発行がパフォーマンスに響くような状況はSQLの粒度が小さすぎる
大抵そういう時はうまく纏めれば一桁速くなる

2019/03/13(水) 01:32:35.47

>>891
アプリケーションとストアドの比較をしているのではなく同じ結果をもたらすSQLとストアドの比較をして言った
そもそもアプリケーションに書かれたビジネスロジックをそのままストアドに移植する時点で論外なので比較する発想がなかった

2019/03/13(水) 04:57:47.34

>>895
> 同じ結果をもたらすSQLとストアドの比較をして言った
そりゃSQL単体で書けるならその方が速いわなw
SQL単体で書けるのにストアド使うとか普通あり得ないでしょ？

2019/03/13(水) 06:19:07.90

>>896
残念ながらありえます
しかも少なくありません
単にSQLが苦手な人
ストアドの方が速いと思ってる人
深く考えずアプリケーションコードストアドに移植してしまう人
SQLでいいのにストアドを書いてしまう人というのは何処にでも居ます

2019/03/13(水) 06:45:04.68

>>897
>>889
お前の周りのことなんか知らんよw

2019/03/13(水) 07:00:38.50

>>898
このスレッドにもいましたよね

2019/03/13(水) 07:12:08.08

何を言いたいのかさっぱりわからんw

2019/03/13(水) 08:04:29.56

煽りか

2019/03/13(水) 10:36:45.92

一体いつまで同じ話をぐだぐだ続けるつもり？
プログラマ板のどっか雑談スレでやれよ低能プログラマどもは

2019/03/13(水) 11:12:26.48

だってここ以外ではマウントとれないんだもの

2019/03/13(水) 15:18:57.45

セルA1に =aaa と書き込んで数式エラーを作っておきます

その上で
Dim ary() As Variant
ary = Activesheet.Range("A1:A10")

MsgBox ary(1, 1)

結果：
型が一致しません

ary(1, 1)をVariant型の変数に代入する場合は何も起きないので
MsgBoxに表示するときに内部的にString型に変換するため
エラーがおきるのだろうと思っています

それはともかく、ary(1, 1) からエラー値を削除したいのですが

ary(1, 1) = ""
MsgBox ary(1, 1)

とやってもダメでエラーが出ます
ary(1, 1) を何もない状態にするにはどうしたらいいですか？

ary(1, 1)はこの先いろいろな操作をすることになるため、そのたびに
どこに隠れているか分からない数式エラーをチェックするのは大変なのです