[[20210327213621]] 『VBA エクセルのバージョン変更による影響について』(VBA初心者) ページの最後に飛ぶ

[ 初めての方へ | 一覧(最新更新順) | 全文検索 | 過去ログ ]

 

『VBA エクセルのバージョン変更による影響について』(VBA初心者)

現在Excel2010の32bit版でVBAを使用し、
ユーザーフォームのコンボボックスとテキストボックスを組み合わせ、
データベースシートから出力シートへ必要なデータを出力しております。

事務所のパソコンが古くなってきたため、全て新調し
Excel2019の64bit版に変更を検討しておりますが、
VBAの動作で不具合が生じる可能性はありますでしょうか?

抽象的な質問で申し訳ありませんが、よろしくお願いします。

< 使用 Excel:Excel2010、使用 OS:Windows10 >


 可能性は 0% ではありません。

 >ユーザーフォームのコンボボックスとテキストボックスを組み合わせ、
 >データベースシートから出力シートへ必要なデータを出力しております。
 内部的にどのように処理しているのか解らないので、
 0%と100%の間のどれくらいかと問われると、これはわかりません。

 会社組織なら、全て新調する前に、少数だけ調達してテストし、
 問題の調査と対応を行った後に全数を入れ替えという手順を踏んでください
(´・ω・`) 2021/03/27(土) 23:49

> Excel2019の64bit版
Windows が 64bit だからといって「Excel も 64bitに」という必要性は
全くないですよ。

Excel(Office)は32bit版で大丈夫です。

Microsoft 自体が Excel(Office) は 32bit版の方を推奨しています。

Excel を64bit版にすると、
「64bit対応版をリリースしていない外部コントロール(DLL)」などが
利用できなくなるなどの問題も有ります。

(AddinBox 角田) 2021/03/28(日) 10:40


変数等にも不具合が生じる可能性を考慮すると、
想定しうる全パターンをイミディエイトウィンドウで確認するしかないでしょうか…。

32bit版でも良いとは存じませんでした、ありがとうございます。
(VBA初心者) 2021/03/28(日) 11:12


既にお読みかも知れませんが、以下が参考になります。

【64 ビット版または 32 ビット版の Office を選択する】
https://support.microsoft.com/ja-jp/office/64-%E3%83%93%E3%83%83%E3%83%88%E7%89%88%E3%81%BE%E3%81%9F%E3%81%AF-32-%E3%83%93%E3%83%83%E3%83%88%E7%89%88%E3%81%AE-office-%E3%82%92%E9%81%B8%E6%8A%9E%E3%81%99%E3%82%8B-2dee7807-8f95-4d0c-b5fe-6c6f49b8d261

64ビット版を使ったほうがよい場合が列挙されています。
私見では、かなり限定的であって、通常のユーザーではそういう可能性は低い気がします。
既に指摘いただいていますように、
少なくとも、OSが64ビットだからOfficeも64ビットで、ということでは無さそうに思います。

>Microsoft 自体が Excel(Office) は 32bit版の方を推奨しています。
とコメントいただいています。私もそういう記述を見た記憶があります。

エビデンスは、下記でしょうか。
【64 ビット版 Office について】
https://docs.microsoft.com/ja-jp/archive/blogs/office_jp/64-office
ただ、これは2010年で、10年程前の記事なのが気になりました。
最近の記事でも、同様なんでしょうか。
(γ) 2021/03/28(日) 12:44


 実体験を置いておきます。
 5MBぐらいのExcelを扱う際に、32bit版だとメモリが足りないといわれ度々落ちたので
 64bit版を入れなおしたところ事象が発生しなくなりました。
 このぐらいのファイルサイズだと64bitのほうがいいということで参考になれば幸いです。
(権兵衛) 2021/03/29(月) 11:03

 最近たまたま見た OfficeTankaさん のYouTube

 【64ビット版のExcelは、思わぬところでマクロがエラーになる】
https://www.youtube.com/watch?v=mG5yzWPSxaA&t=165s

(半平太) 2021/03/29(月) 15:30


貴重な情報ありがとうございます。
(しかも、スタート時刻の適切な設定まで、細やかな配慮ww深謝します)

64ビットExcelでLongのかわりにLongPtrを使うと、
エラーになるケースがある、という話はよく分かりました。

ところで、LongPtrを使わないと、メモリーを広く使えるというメリットは享受できないものでしょうか?
普通にLongでも享受できるのでしょうか。

もし享受できるのであれば、(APIを使用する際に、LongPtrを使うことは当然ですが)、
それ以外はLongPtrを使わなければいいだけではないかと思いました。

詳しい方からコメントいただければ幸いです。
(γ) 2021/03/29(月) 19:21


 エヘヘ。「詳しい方」でもないのに生意気にも発言。お、お許しを...^^;

 msの説明読んでみても、
 LongPtrって「種類」としては[データ型]に分類されますけど、
 その解説を読んでみると[データ型]とは表現されておらず[型エイリアス]と表現してあります。
 また、
 [Ptr]って綴りが付いてる以上、ポインタとかハンドルに使うことを想定された型なんでしょうから、
 その存在意義(というか目的というか)って
 「アーキテクチャの違いを解決する為の型ですよ」ソコ1点だけだと解釈してます。
 (私自身がPtrSafeとセット物として覚え込んでしまっているだけってのもありますが)

 実際には探せば「使い所」があるの"かも"知れませんが、
 それって要するに「用途外使用につき自己責任で」の世界になっちゃうんじゃないでしょうか? (堅い事言えば)

 使いたいんならLongLongで宣言してね。
    ↓
 こっちなら64bit版でしか使えない型にしてあるから。
    ↓
 そしたら32bit版と共用できるコードなんて組みたくっても組めないって寸法よ!
    ↓
 ね? ね? 親切でしょ?

 という感じに受け止めてます。
 msさんの親切心を無視してまでわざわざLongPtr経由で宣言して使用するぅ?   ...って感じです。

 結果
 >それ以外はLongPtrを使わなければいいだけ
 仰る通りだと思います。

 あ、ちなみに私、
 業務で毎月8万行×256列のデータをwin7(32bit)/Excel2010で取り扱ってますが、
 マクロでもそれ以外でもメモリ不足になった事はありません。
 圧縮効率の高いxlsb形式で保存しても40MB弱のファイルサイズになります。
 (たぶんxlsm形式だと80MBくらいになる筈)
 RAMだって合計3GBです。ホントにただの事務用PC。

 まあ、これくらいのデータ量になってくると、
 全データを一気に配列に取り込んでループ回してあれやってこれやって... なんて処理組む方が大変ですからね。
 結果的にメモリ不足になってないだけかも知れませんが。

 かと思いきや、別件でスパークライン160個作ったシートでオートフィルタ掛けたら、
 途端に「メモリ不足です」って信じ難いメッセージが出てくる事もありますけど。

 ...とまあ、なんか、取り留めない事をダラダラとスミマセン。
 ちゃんとしたコメント付くまでの余興だと思ってご容赦ください^^;

WinAPIの64bit化で出てくるPtrSafe、LongLong、LongPtrってなんなのさ? - えくせるちゅんちゅん
https://www.excel-chunchun.com/entry/20200809-vba-declare-ptrsafe-longlong-longptr

VBAで最速の整数型を調べてみた - えくせるちゅんちゅん
https://www.excel-chunchun.com/entry/Int_Long_LongLong

(↑別に上記と関連するリンクではないです。ちょっと目に止まったので貼っときます)

(白茶) 2021/03/29(月) 23:51


 コメントありがとうございました。
 田中さんの講義を聴いた記憶では、
 LongPtrは 64bitでは LongLongと読み替えられ、
           32bitでは Long と読み替えられる
 とのことで、おっしゃる通り、型エイリアスと思います。

 問題は、64bitで LongLongで宣言した変数を、
 Long型を想定している例えば関数 Left(s,n) の n のところで使用すると、型不一致エラーになる。

 従って、「64,32両用のために、既存のLongを全てLongPtrに単純に書き換える」という
 方針は得策ではない。エラーが出まくりになる、
 という話ですね。

 で、そんなら、もし「別に LongLong使わなくても、より広いメモリー空間を使える」のなら、
 LongLongを使わない(API関係だけに限定して使用)ことで、ハッピーじゃないの?
 という単純な疑問でした。

(γ) 2021/03/30(火) 00:07


コメント返信:

[ 一覧(最新更新順) ]


YukiWiki 1.6.7 Copyright (C) 2000,2001 by Hiroshi Yuki. Modified by kazu.