ExcelのデータベースをAccessのそれに変更すべきか Excelについては、グラフ・関数・テーブル・VBAなどをだいたい理解しています。Accessについては、全くの素人です。

Excel | Microsoft Access60閲覧xmlns="http://www.w3.org/2000/svg">500

ベストアンサー

0

回答ありがとうございます。Accessの値を参照するのであればExcel側の負荷が減りそうですね。そこが最も気になっていた点でした 。Accessへの移行を検討してみます。

その他の回答(5件)

0

有る回答者が >ExcelでできることはAccessですべてできる。 と言っていますが、私はそうは思いません。 エクセルが持っている豊富な関数はアクセスには有りません。 VBAを使い自前で関数を作る(高精度の演算は難しいです)か エクセルを下請けにした処理させる必要が有ります。

回答ありがとうございます。ExcelとAccessでは得意分野が違うようですから、Accessを使ったとしても両者で管理する予定です。 計算用のExcelファイルには、すでにさまざまな関数を使用した式が組み込まれているので、それら全てをAccessに移行させると相当な手間がかかるでしょうから、そのつもりはありません。

0

>① データベース用のExcelファイルがある これが、「今後、複数人数(台数)で共有してレコード追加・削除や修正などをしたい」ということでしたら、今がちょうど替え時、かもしれません。 逆に、「自分一人でしか使ってない」ということでしたら、シートの再計算を頻繁に行わないようにすれば、結構、引っ張れるのでは? ワークシート関数を一切使わないシートでも、列数にもよりますが、10万件くらいを超えると開くのだけでも時間がかかるので、その遅さがガマンならなくなったらAccessを併用するとき、のような気がします。 Accessを併用する際は、①だけに使い、 ②以降は、Excel側(計算用のブック)で、③の部分だけを、以降の(a)~(d)の方法を単独・あるいは・併用で使えば、今のままでいいと思います。 (a)フィルタをやめてMicrosoftQuery(Accessの「クエリ」と同等の20年前からExcelで使える機能。簡易SQL生成機能)を使ってみる (b)フィルタをやめて、PowerQueryを使ってみる。(SQLは基本、使わない) (c)フィルタをやめて、QueryTableオブジェクト+VBA+ODBC接続+SQL、でやる (d)フィルタをやめて、CopyFromRecordset+VBA+ADO+OLEDB接続+SQL、でやる ※「SQL」とは、Excelのフィルタ機能と自動集計機能を同時に1発で行えるような機能というか、理論というか、命令語句というか、そういうモノです。 ※「SQL」を使う場合(つまり(b)以外)に限っては、(c)が一番エラーが出ずに、クエリのクエリのクエリ、みたいにネスト的なことがラクにできます。それは、(a)でもやれないことはないですが、エラーが出やすいです。 現行のAccessはバージョン2019ですが、ピボットテーブルが使えません。 (Access 2013 で廃止されました) また、Accessは昔から縦罫線の多い帳票作成(帳票の連続印刷)は苦手です。(逆に、横罫線だけでいい帳票の連続印刷ならExcelの50倍はラクちん) あと、「フォーム(ユーザーフォーム)」については、 「基本、定型事務作業に限っては、AccessのソレはExcelのソレの50倍は効率的」ですが、ただ、 「逆に定型事務作業ではない場合、ドラッグやデザインを多用したフォームに限っては、基本、作れないと思っていい」 です。 例えば、通常の売上入力やその他のデータ入力やフィルタフォームなどの作成はすごく効率的なんですが、一方、ガントチャートやグループウェアのようなものは、(一応はムリにやれば作れますが)、実用的にするにはOCXだか何だかを自作しないとショボいものしか作れません。 その場合、Excelでシートをフォームに見立てて作る方がまだマシです。 イレギュラーなレイアウトの表やクロス集計表の計算、グラフ処理、縦罫線の多い帳票の連続印刷、などは、Excelを使うほうが手間がかからないと思います。 あるいは、グラフやピボット的なものであればPowerBIDesktopを使うとか。 Accessの得意、Excelの得意、は、それぞれがちょうど「デコ」と「ボコ」になっていて、 「Accessの得意はExcelの苦手」 「Excelの得意はAccessの苦手」 という風になっています。 高速データ処理や蓄積、表の紐付け(VLOOKUP的なこと)や縦結合、データ共有、複雑な条件でのデータ抽出やリストアップなどはAccessが得意で、 その先のさらに細かい計算やグラフ処理、シュミレーションなどは、Excelのほうが得意です。 「オートメーション」の機能を使えば、お互いのVBAプログラムからお互いを自動操作もできます。 つまり、AccessとExcelは「2つでひとつ」という兄弟ソフト(姉妹ソフト)と捉えたほうがよく、そういう「お互いに助け合う・補い合う」のが一番コスパがいいです。 「全てをAccessでやる」、というのはコスパ無視のバカがやることです。 すべてにおいてのコスパ最悪。(構築、データ入力や管理、機能追加や修正、集計その他、引継ぎ、すべてのコスパ。) どちらかで統一したほうが確かに見た目はいいしスッキリしますが、でもそれだけです。 操作性もいいように一見・見えますが、でも、管理が犠牲になり、無駄ばかり増えます。 Access・Excel混在、だと、見た目がゴチャゴチャして汚いように見えるかもしれませんが、結局、「それぞれを使う場所の見極め」がちゃんとできていれば、そのほうが色んなコスパが2~5倍は良くなると思います。 (もちろん、「すべてのAccessでの処理・VBA作成、縦罫線帳票作成、その他諸々」を、数秒か20分以内に終わらせられる、という超人的な方なら全部Accessでやってもいいのかもしれませんが・・・・。) ※同様に、データ量が増えてつらくなってきたときに、Accessの費用をケチって「全部Excelでやる」というのもあまり良くはないことです。なので、質問者様の今のお考え・将来に対する想定?備え?は正しいということになります。 なお、セキュリティはお互いショボすぎるので、捨てるほうがかえっていいです。(開くときにパスワードかけるくらいのことでとどめる) ただ、Accessで、同時アクセス数・3台以上でデータ共有する場合は、データファイルが壊れないようにする工夫が必要なので、注意が必要です。 Accessの良さである「連結フォーム」「連結××」を使わないようにして、一時テーブル(ワークテーブル)などを使って、クエリ(SQL)データの追加や削除、修正をするようにします。 あと、サーバ側でOplockのレジストリ設定も必要になるかも?です。 (特にmdbは。accdbはわかりませんけど・・・・。) >・ExcelとAccessを接続すれば、③の工程は不要になるのでしょうか? そもそも現在の仕様がわからないので、そこまでは誰も判断できないと思います。不要になるかもしれないし、ならないかもしれません。 >・データベースとして利用したExcelの限界はどのあたりという目安はあるのでしょうか? これも現在の仕様やデータ量(特に列数、シート数など)が不明なので誰も判断できないです。データベースと称されているファイルを共有する・しない、によっても違うでしょうし・・・ でも「今」、「遅い」「ストレスだ」とお感じなら、今、現時点の状態が「めやす」とうことだと思います。 あまり動きが遅くなると、誤操作でデータを破壊しそうです。 パソコンの起動ドライブをSSDにしてもそうなら、なおさら、今、現時点の状態が「めやす」ということだと思います。

なお、 (a)~(d)のうち、一番簡単なのは(a)です。 あと、AccessのSQLとExcelのSQLは少し方言が異なるので注意が必要です。 そのため、Accessからのシンプルなデータ吸込みなら(a)が一番ラクです。方言を気にしなくてもいいので。 また、もしSQLを覚えたくないなら、PowerQueryでもフィルタしながらプログラミングすることなく、Accessからデータを吸い込ます。こちらのほうが(a)よりも情報が多いことは多いです。 なお、(a)~(d)のどれでやるにしても、計算用のブック(③をやるブック)は、デスクトップやユーザーフォルダ、マイドキュメント、OneDriveフォルダなどに置かないでください。 エラーが出やすくなります。 Dドライブか、Cドライブに専用のフォルダを作って、その中に計算用のブック(③をやるブック)を格納してください。

0

>データベースとして利用したExcelの限界はどのあたりという目安 不安に感じた時、つまり今。 ①~④がACCESSの中で何かといえば、ざっくりコレ。 ①テーブル ②③は①を元にした選択クエリとそこでの式 ④フォーム・さらなる選択クエリ