【先着1,000名様!】1,000円分をプレゼント!

Access2003を使用しています。
メンテナンス後保存をしたり、検索をかけたときとても時間がかかるので、データベースからテーブルだけを切り離す方法を試みてみようかと考えています。
テーブルとそれ以外のデータベースオブジェクトを分割する方法です。
試しにコピーをとったファイルで行ってみましたがあまり速度が速まったように感じません。
参考書を読むと、「大量のデータを蓄積するデータベースに威力を発揮する」と書いてあり、見本は300Mバイトになっています。
私がメンテナンスをかけているファイルは65MB程度です。
これぐらいの大きさだと分割する効力は低いのでしょうか?
他の方法を試みたほうがいいのでしょうか?
ちなみにCPUはあまり高くありません。
どなたかこの方面にお詳しい方がいらっしゃいましたらご教示ください。
よろしくお願いいたします。

このQ&Aに関連する最新のQ&A

A 回答 (8件)

>MDBファイルを全部上書きすることになっているために時間がかかっているのかもしれません。


「なっているため」という言葉遣いは正しくなかったかもしれません。
「なるのかもしれないので」位の意味でした。 申し訳ありません。

No6の回答は憶測で書いています。(何の根拠もありません。)
コンピュータやプログラミングの専門家でもありませんし、
私のアクセスの経験もかわいいものですので、(97から)
「こう考える素人がいる」というくらいにとってください。

ちょっと考えてみましたが、mdbのデータファイルの構造は以下のようになっているそうで、
http://www.mrdb.ne.jp/technic/se_guide/d_fkouzo. …
最適化を行うと
・データ部分のブロックが減る
・インデックスによる順番付けがなされる
ので検索に対するパフォーマンスがあがるということには異論はないと思います。

問題はフォームやレポートをいかに保存しているかですが、
やはり決まった単位のブロックを用意して、オブジェクトを書き連ねているのかなと思います。 
(前言を撤回することになりますが)そうだとすると、データ部分を切り離すことと
フォームのサイズを小さくすることは関連性がないということになり、
フォームをセーブするときの時間も、データを切り離したところでフォームを最適化しないと、
あまり変わらないということにもなりそうです。
データ部分のみが最適化されたmdbと、すべてのオブジェクトが
最適化されたものの保存時間を比べてみればヒントはつかめそうですが、、、
そのような実験にあまり意義を感じません。(そこまでアクセスを愛していません。) 

いろんなDBがありますが利用する際は定期的に最適化を行わないといけないのではないかと思います。
アクセスも例外ではないということです。

>テーブルは必ず別mdbにして、「閉じるときに最適化」していますので
これを行っていれば、保存に関してこれ以上の効率化は難しいと思います。(コーディングを変えない限り)
逆にこの状況で何らかの問題があるなら、
・データ構造は適正か?
・データにどうアクセスするか?
・コードをどう記述するか?
・ハードウエア(通信環境含む)は適正か?
これと共に、
・DBは適正か?
を診断しなくてはいけないと思います。

質問者さんに対してのアドバイスは、
・実運用中のものを開発する際は、別ファイル(コピー)を作りそちらに手を加える。(実データで開発を行うことは望ましくないと思う。)
・手を加えたものをリリースする前に最適化をする。
・実運用中のものには定期的(期間はdbの更新頻度やつくりにもよる)に最適化を行う。
・データに関しては、何らかの形で定期的にバックアップをとる。
以上のような行為が必要で、
それを怠ると、いつかきっと痛い目にあう(かもしれません。)
データとその他の部分を切り離すと、
・データファイルが破損する可能性が低くなる。
・上記のようなメンテナンスが行いやすくなる。
・他のdbへの移行がやりやすくなる。
というメリットがあります。
    • good
    • 0

No.5です。


この場をお借りして、No.6さんにお尋ねします。
----------
>>フォームのデザインを変えた時に保存をかけると30秒....
>MDBファイルを全部上書きすることになっているために時間がかかっているのかもしれません。
----------
 とすれば、データが増えると、チョッとした修正であれば、保存の方が時間が掛かることになりますねェ‥‥
私は、テーブルは必ず別mdbにして、「閉じるときに最適化」していますので、そういう経験はない‥‥と言うことになりますかぁ~
    • good
    • 1

No1です。



データを分割させることについての必要性については、皆様がおっしゃっておられるとおりです。(必須です)
>フォームのデザインを変えた時に保存をかけると30秒....
(実験していないので、ただの憶測ですが)MDBファイル自体が小さくなるので、データを分割すると早くなる可能性はあります。
MDBファイルを全部上書きすることになっているために時間がかかっているのかもしれません。
>新規レコードを追加したときはそれほどでもありません。
これまた憶測ですが、追加の際にはファイルの末尾にデータを加えている(appendしている)だけなので速いのかもしれません。 
    • good
    • 0

No.2のogohnohitoです。


 No.4さんはAccess1.aから使っていたのですね。私はその頃「桐」を使っていたはずです。桐の「大遅刻」でAccess2.0に移行しましたぁ~

 質問者さんは、
> 分割させる方法は意味がないようなのでやめることにしました
と言っておられますが、決してそんなことはありません。むしろ「分割すべき」です。
 私は「中間テーブル」を使う方(たぶん)なので、データテーブルと中間テーブルは必ずmdbを分けています。結果として3っのmdbで一つのシステムになります。その目的は、No.4さんの云う「保守性、拡張性」です。
息の長いシステムにするには「分割すべき」です。
    • good
    • 0

Accessで、アプリケーション・システムを構築する場合は分割するのが当然と考えます。


Access1.a~Access2000頃まで10年近く、Accessでシステムを構築してきましたが、
分割してある方が、保守性、拡張性が高いと言えます。非分割型に比べると、
最初にテーブルを開く時に遅いことが欠点ですが、2回目以降はファイルが
開いているので、処理速度の劣化はありません。但し、非分割型より速いかと言うと、
目覚しい向上は期待できません。
尚、DBを最適化すると、処理速度が向上しますが、分割している場合はVBAで処理可能です。
http://www.geocities.jp/cbc_vbnet/kisuhen/mesodo …
    • good
    • 1

その本で書かれているのが、「速度が速くなる」目的なのか判断しかねますが、単純に分けたからといって早くなることは無いと思います。


が、ネットワーク環境でファイル共有にしている場合は、分けることによってネットワーク トラフィックを少なくできるので その意味では早くなります。
複数ユーザーで利用する場合には、データのMDBだけを共有するのが(リンクテーブル)いいですね。
あとは、1ファイルで処理しているより ファイルが壊れた時のトラブルを回避できる点や、開発中でも完全に分離していると テンスと環境等も作成しやすい面があります。
    • good
    • 0

No.1さんの言うとおりで、「テーブルの最適化」と「適正なインデックス」に懸かっていると思います。


更に、テーブル以外のmdbを(閉じる時に)最適化したりmde化すると、体感はありませんが速くなる方向にあります。
    • good
    • 0

専門家ではないので、はずしているかもしれませんが、


>テーブルとそれ以外のデータベースオブジェクトを分割する方法
これによって、パフォーマンスが大きく変わるとは思えません。
(大きなアクセスファイルを使う上では必須の行為だと思いますが)
検索の速度はどのようなテーブル(フィールド数、レコード数)から、
どういう形で(どのフィールドに対して、どういう形の)検索を行っているのかによります。
抽出の速度を上げるためには(1)テーブルの最適化と(2)適正なインデックスの作成がメインだと思います。
それを行ったうえでのパフォーマンスに不満があるなら、
検索方法の見直し、テーブル構造の見直しやDBMSの変更を視野に入れるべきだと思います。
保存に時間がかかるというのは、意味がはっきりとわからないのですが、
何らかの形でバックアップなどを取るときに遅いということでしょうか? 
それとも、レコードを挿入するのに時間がかかるということでしょうか?
レコード挿入についてでしたら、これまたどのような形でレコードを挿入されているかにかかってきます。

この回答への補足

補足ですが、保存に時間がかかるというのは、フォームのデザインを変えた時に保存をかけると30秒ほどかかります。
新規レコードを追加したときはそれほどでもありません。意外と早いです。
これはどうしてなのでしょうか?
よろしかったら教えていただけないでしょうか。

なお、分割させる方法は意味がないようなのでやめることにしました。
教えていただいたテーブルの最適化と適正なインデックスの作成を見直してみようと思います。

補足日時:2008/05/12 11:12
    • good
    • 1

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人はこんなQ&Aも見ています

関連するカテゴリからQ&Aを探す

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

QAccessのRefresh・Requery・Repaintの違い

Requeryはもう一度ソースレコード(テーブル)を読み込むようです。このとき、テーブルの先頭レコードに移動してしまいます。
Refreshは最新のレコード(テーブル)を再表示するような気がします。レコードの移動は起こらない気がします。
Repaintは、VBAでキャプションなどを変更したとき使っています。
でも、よくわかっていません。
どんなときにどんなメソッドを使えばいいのでしょうか?
詳しい方、よろしくお願いいたします。

Aベストアンサー

たびたびすみません。
調べてたらこんなのがでてきました。
http://www.nurs.or.jp/~ppoy/access/access/acF007.html

参考URL:http://www.nurs.or.jp/~ppoy/access/access/acF007.html

QアクセスVBAのMe!と[ ]

基本的なことですみません。

アクセスのイベントプロシージャで、Me!ってありますけど、これはどういう意味なんでしょうか?

また、Me!の後に、Me!.~~と書く場合と、Me!.[~~]と書く場合がありますが、どこが違うのでしょうか?

Aベストアンサー

>プロシージャ内で[]を使う場合は、そのフォーム外のオブジェクトを使う場合と考えてよろしいでしょうか?
別のオブジェクトを使う場合だけではありません。
Hensu = Me![Text1]のようにHensuという変数に自身のTest1の値を代入する場合のように。
[]で括られているのがオブジェクト名やコントロール名だよという事。
クエリの抽出条件に存在しない[?]とすれば?というコントロール等が参照できないので?というダイアログが表示されるように?というオブジェクトやコントロールは何?と聞いてくるように。
>フォーム内のオブジェクトの場合はあくまでMe!で良いのでしょうか
Forms.[フォーム名]![コントロール名]やForms![フォーム名]![コントロール名]が構文。
アクティブなフォームが自分自身ならForms![フォーム名]の変わりにMeでもOKですという事。

と言う解釈の方が良いと思います。

QAccess サブフォームでの選択行の取得

こんにちは。

Access初心者です。

サブフォームでテーブルの項目を表示させていますが、
選択された行を取得する方法はありますか?
サボフォームの下の方に現在選択されているレコード数が表示されてますが、その値でかまいません。

調べているのですが、なかなか検討がつきません。
宜しくお願い致します。

Aベストアンサー

フォーム名がフォーム1、サブフォームコントロールの名前がサブフォーム1だとすると、

Forms!フォーム1!サブフォーム1.Form.CurrentRecord

で取得できます。
(「Forms」と「Form」がありますのでご注意下さい)


また、フォーム1にコードを記述する場合であれば

Me!サブフォーム1.Form.CurrentRecord

サブフォーム1へのコード記述であれば

Me.CurrentRecord

という構文によっても、それぞれ取得が可能です。

QAccessを開くと「排他モードじゃないので変更しても保存できない」との旨の表示が出てしまう。

「Access 2000」を使用して顧客管理用のデータベースを作成し、複数のパソコンで使用できるように原本を共有ドキュメントに入れて、ネットワーク上の他のパソコンではショートカットを作成し、それぞれがそのデータベースを開いたり編集したり出来るようにしています。

しかし、特定のパソコンだけそのデータベースを開く際に「現在、このデータベースは排他モードでアクセスしていません。変更しても、後で保存できない可能性があります。」と表示され、中身を編集したり保存出来ないようになっています。

たしかに、「規定の開くモード」は「共有モード」になっており、排他モードにはしていないです。

この設定で会社の大多数のパソコンでは上記メッセージが出ることなくちゃんと編集ができるのに、どうして特定のパソコンだけこのようなメッセージが表示されて編集を保存できないのでしょうか?
現在の設定のまま使えるようにするための方法はありますでしょうか?

まだAccessを使い始めたばかりで、記載した情報も少ないかもしれませんが、何か分かりましたら教えてください。

「Access 2000」を使用して顧客管理用のデータベースを作成し、複数のパソコンで使用できるように原本を共有ドキュメントに入れて、ネットワーク上の他のパソコンではショートカットを作成し、それぞれがそのデータベースを開いたり編集したり出来るようにしています。

しかし、特定のパソコンだけそのデータベースを開く際に「現在、このデータベースは排他モードでアクセスしていません。変更しても、後で保存できない可能性があります。」と表示され、中身を編集したり保存出来ないようになっています。

...続きを読む

Aベストアンサー

> 特定のパソコンだけそのデータベースを開く際に「現在、このデータベースは排他モードで
> アクセスしていません。変更しても、後で保存できない可能性があります。」と表示

<可能性・1>
ご質問の「特定のパソコン」の『既定の開くモード』が「共有モード」で、「大多数のパソコン」では
「排他モード」になっているのだとすると、「現在の設定のまま」というのは難しいと思います。
(逆にいうと、ご質問の現象が『既定の開くモード』に起因したものなら、その設定の変更で対応
 できるはず、ということ)

なお、Accessの「排他モード」には、私が知る限り少なくとも2種類あります。
で、『既定の開くモード』で指定する「排他モード」であれば、Access2000では、実際には他の
人が使用中であっても、同じファイルを開くことができたと思いますので、まずはその設定を
変更することで問題が解決できないか、確認されてみてはいかがでしょうか。

2種類の排他モードについての参考として、以前の回答へのリンクを載せておきます:
http://oshiete1.goo.ne.jp/qa3688575.html
※念のため今回再試したところ、『既定の開くモード』の「排他モード」でも、重複起動させると
  「使用できませんでした」とのメッセージが返されました。(Access2003にて確認)
  もしかしたら、Office2003 SP2でこの辺りは修正が掛かったかもしれません。
  ただ、今回のご質問のAccess2000では、従来の動作のままのはずですので、試してみる
  価値はあるかと思います。


<可能性・2>
他の大多数のパソコンでも『既定の開くモード』が「共有モード」だとすると、上記の話は
成り立ちません。
・・・というより、同時に使用している場合、他のパソコンでも「後で保存できない可能性が」
とのメッセージが出るはずの状況です。(Accessの仕様として、そうなっているはず、と)

この場合は、念のため、他のパソコンのショートカットのリンク先が、本当にネットワーク上の
原本を開く形になっているか、確認してみてください。
というのは、Accessによるの運用方法として、「データを保存するテーブルのみのファイル」と
「フォームなど、テーブル以外のものからなるファイル」の二つを作成して、後者から前者に
テーブルのリンクを張る(リンクテーブル)、というものがあり、他のパソコンのショートカットが、
実は各パソコンにコピーされたファイル(フォームなど+リンクテーブル)にリンクしたもの、
という可能性が考えられるためです。
※これは、shocola_ttさん以外の方がそのデータベースを作成されたと想像しての回答です。

この構成の場合は、「特定のパソコン」にその原本のコピーを作成して、作業はこのファイル
で行う、という形にすれば、問題が解決すると思います。
(上記の通りなら、原本内にあるのはテーブルではなくリンクテーブルなので、入力/編集の
 対象となるデータ自体は共有されていることになります)

> 特定のパソコンだけそのデータベースを開く際に「現在、このデータベースは排他モードで
> アクセスしていません。変更しても、後で保存できない可能性があります。」と表示

<可能性・1>
ご質問の「特定のパソコン」の『既定の開くモード』が「共有モード」で、「大多数のパソコン」では
「排他モード」になっているのだとすると、「現在の設定のまま」というのは難しいと思います。
(逆にいうと、ご質問の現象が『既定の開くモード』に起因したものなら、その設定の変更で対応
 できるはず、というこ...続きを読む

QAccessリンクの仕方によるフロント速度違い

 小規模の会社で、Accessによるデータベースとフロントシステムを作っています。
この度、Access2003から2013へ変更するにあたり、システムを再構築するので、今よりも利用頻度が増えても、快適に動くようにしたいと考えています。
 そこで、データベースにしたAccessからのリンクの仕方と速度に関係があるかの質問です。
 前提条件として、データベースにするAccessはServer上にあり、フロントのAccessはクライアントPCにあります。フロントのPCから、ベースAccessにリンクを張って使用するのですが、多様な業務から、複数のベースAccessが存在し、1つのフロントから、主たるベースAccessのほかに他業務のベースAccessにもリンクを張るようになります。
 このケースで、ベースAccess側で、リンクテーブルを作り、フロントAccessからは、1つの主たるAccessにリンクを張るほうが、フロントの速度が上がるのか、それとも、現在と同じように複数のベースAccessにリンクを張るほうが速度が上がるのか、リンクの張り方が速度に関係することが無いのかを知りたいと思っています。
 ご存知の方いらっしゃいましたら、教えてください。
 よろしくお願いします。

 小規模の会社で、Accessによるデータベースとフロントシステムを作っています。
この度、Access2003から2013へ変更するにあたり、システムを再構築するので、今よりも利用頻度が増えても、快適に動くようにしたいと考えています。
 そこで、データベースにしたAccessからのリンクの仕方と速度に関係があるかの質問です。
 前提条件として、データベースにするAccessはServer上にあり、フロントのAccessはクライアントPCにあります。フロントのPCから、ベースAccessにリンクを張って使用するのですが、多様な業...続きを読む

Aベストアンサー

やったことはないけど、間にリンクテーブルだけのmdbを置くことは、パフォーマンス向上にはつながらないと思う。 これまたやったことないけど、パフォーマンスがあがる可能性としてはリレーションを組まないでよいテーブルは別のサーバに置くことじゃないかな? 同じPCに複数MDBをおいても意味はないと思う。(テーブルを結合させたSQLを発行する場合は、テーブル同士が別サーバーにあるとローカル処理になるので、これは避けたいところ)

一般的な流れとしては、
・dbはなるべく一つとしておいたほうが、管理が簡単。 (スケールが小さい場合はサーバーを分散させるより、機能を高めたほうが費用がかからないことが多い。)
・パフォーマンスを向上させるには、ハードウエア(サーバー・クライアント)、DBシステム、ネットワーク、データベースの正しい設計を行なう、などなど。 これらは、ユーザー数やトランズアクション数をあらかじめ想定した上で、どれだけ費用をかけてどのようなものを作るか考えるべき。
・DBは定期的にメンテナンスを行なう。 (アクセスだと、レコードの削除がある場合は最適化など)
・アクセスはユーザー数とトランズアクション数によっては、時々変なことが起きるので、データベース部分は早めに他のDBに切り替える。(簡単にSQLサーバとかにアップスケールできたと思う。)

やったことはないけど、間にリンクテーブルだけのmdbを置くことは、パフォーマンス向上にはつながらないと思う。 これまたやったことないけど、パフォーマンスがあがる可能性としてはリレーションを組まないでよいテーブルは別のサーバに置くことじゃないかな? 同じPCに複数MDBをおいても意味はないと思う。(テーブルを結合させたSQLを発行する場合は、テーブル同士が別サーバーにあるとローカル処理になるので、これは避けたいところ)

一般的な流れとしては、
・dbはなるべく一つとしておいたほ...続きを読む

QAccessで検索を高速化

顧客データの検索画面をAccessで作成しています。
テーブルの数は全部で9、各テーブルのレコード数は約1万、
各テーブルのフィールド数は多くて20くらいです。

テーブル用のAccessをサーバに置いておいて、
検索画面フォームのAccessはそれぞれの社員のローカルに置いています。
テーブルを参照している社員数は20弱です。

Accessのバージョンは2007や2010、Runtimeを使っている社員もいます。

氏名フリガナと電話番号で検索できるようになっていて、
下の□のなかに、各テーブルの該当のものが抽出されるようになっています。

この検索画面の動きが最近著しく悪いです。
もっとサクサク動くようにしたいです。
色々調べてはみたのですが
・テーブルをSQLサーバに置いてリンクしなおしてみたのですが
余計動きが遅くなりました。
・「ある程度絞り込んでから検索をかける」というのが高速化のポイントらしいですが
常に全件が検索対象なので、それができません。
・テーブルのレコードについては常に全社員が新規作成、変更等できる状態でなければならないです。

動きを高速化させる知恵はないでしょうか?
ご教授ください!

顧客データの検索画面をAccessで作成しています。
テーブルの数は全部で9、各テーブルのレコード数は約1万、
各テーブルのフィールド数は多くて20くらいです。

テーブル用のAccessをサーバに置いておいて、
検索画面フォームのAccessはそれぞれの社員のローカルに置いています。
テーブルを参照している社員数は20弱です。

Accessのバージョンは2007や2010、Runtimeを使っている社員もいます。

氏名フリガナと電話番号で検索できるようになっていて、
下の□のなかに、各テーブルの該当のものが抽出されるように...続きを読む

Aベストアンサー

ミスリードが怖いので今回限りとします。
バックエンドの顧客データファイルをローカルにおいて再リンク。
これで試した場合に
共有フォルダに置いた場合とさほど処理時間が変わらなければ
Accessでの処理が限界にきていると推察されます。
両者とも他に誰も使用していない状況で試す必要があります。
差が格段に大きければネットワーク上に置いてあるために
問題が発生していると考えても良いのではないかと思います。

じわじわと遅くなったのではなければ
昨年くらいからWindows Update でいろいろとOSにも修正が入っているので
MSさん何かまずい事していない?と疑いたくなります。

以下は随分と昔なのですが調べた中で関係ありそうなのをピックアップしました。

[ACC2003] 複数のユーザーでリンク テーブルにアクセスするとパフォーマンスが落ちる
http://support.microsoft.com/kb/838670/ja

ネットワーク共有上のファイルを開いたとき、開くのに時間がかかる、読み取
り専用で開く、あるいはエラー メッセージが表示される
http://support.microsoft.com/default.aspx?scid=kb;ja;814112

Windows Vista を実行しているコンピュータで Microsoft Office Access デ
ータベースを開いたとき、または使用しているときに発生することがある問題
http://support.microsoft.com/kb/935370/ja

あとは、アンチマルウェアが足を引っ張っているとか・・・。

いずれにしろ、常時20人弱が頻繁に更新・新規レコード作成を行うのですから
Accessには荷が重すぎるように思います。
デッドロックに乗り上げたりファイル破損の可能性が常に付きまとうので
念には念を入れて作りこまないと・・・。
それに9万レコードのデータがLANを流れるわけですから。
以上、ご参考まで。

ミスリードが怖いので今回限りとします。
バックエンドの顧客データファイルをローカルにおいて再リンク。
これで試した場合に
共有フォルダに置いた場合とさほど処理時間が変わらなければ
Accessでの処理が限界にきていると推察されます。
両者とも他に誰も使用していない状況で試す必要があります。
差が格段に大きければネットワーク上に置いてあるために
問題が発生していると考えても良いのではないかと思います。

じわじわと遅くなったのではなければ
昨年くらいからWindows Update でいろいろとOSにも修正...続きを読む

Qアクセスをネットワークでリンクさせると非常に遅い!?

自分のマシンから、ネットワーク環境にあるデータベースファイル.mdbのテーブルへリンクさせる機能のあるアクセスファイルを作ったのですが、開くのに非常に時間がかかってしまいます。

それで、仕方なくテーブルもクエリーもフォームも1つにまとめたデータベースファイル.mdbをネットワーク環境において多人数で共有させています。

これっていいのでしょうか?

よろしくお願いします。

Aベストアンサー

まず、ネットワークでリンクすると遅い,ということですが、これは仕様です。

相手が MDB でなく SQL Server でも、Access のリンクでは、いったん自分の MDB(マシン)に、データを持ってきて処理を行います。たとえば10万件のテーブルから検索を行おうとすると、自分のマシンに10万件分持ってきて、検索します。遅いわけですね。



->それで、仕方なくテーブルもクエリーもフォームも1つにまとめたデータベース
->ファイル.mdbをネットワーク環境において多人数で共有させています。

あまりお勧めしませんね。運用で使えないこともないですが、トラブルの元にしかならないと思います。


改善策としては、SQL Server等を置くことが良いのですが、安く済ますなら MSDE(たしか Accessを持っていれば無料)で、パススルークエリを使って構築,がいいでしょうね。

QAccessのDAO.ExecuteとDoCmd.RunSqlの違いについて

アクションクエリを実行する際、表題の2つを検討しています。
最重要な違いに同期と非同期であることをネットで検索して分かりました。
非同期だとどのような問題が発生するのか具体的に教えて頂けると助かります><

Aベストアンサー

DoCmd.RunSQL ですが、「非同期」であると幾つかのHPで見かけましたが、実際試してみると「同期」実行している感じです(Access2000で実験)。

実際「非同期」なんでしょうか?
オフィシャルなサイトに「非同期である」と言う記述はありますか?

------------検証プログラム------------
Sub local_test()
 Dim SQL(4) As String
 Dim t As Double

 SQL(1) = "UPDATE T1 SET Data = '0';"
 SQL(2) = "UPDATE T1 SET Data = '1';"
 
 SQL(3) = "UPDATE T2 SET Data = '0';"
 SQL(4) = "UPDATE T2 SET Data = '1';"
 
 '初期化
 CurrentDb.Execute SQL(1)
 CurrentDb.Execute SQL(3)

 'DoCmd.RunSQL テスト--------------------------------------------
 DoCmd.SetWarnings False
 t = Timer()
 DoCmd.RunSQL SQL(2)
 Debug.Print "DoCmd.RunSQL " & Format(Timer() - t, "0.00000")
 DoCmd.SetWarnings True

 'DAO.Execute テスト--------------------------------------------
 t = Timer()
 CurrentDb.Execute SQL(4)
 Debug.Print "CurrentDb.Execute " & Format(Timer() - t, "0.00000")
End Sub
---------------------------------------------------------

T1 T2 とも、3万件程度のテストデータが入っています。
DoCmd.RunSQL の方も処理が終わるまで返ってきません(同期実行では?)

DoCmd.RunSQL は SetWarnings を設定しないと、確認メッセージが出でます。
DoCmd.RunSQL が同期実行だとすると、これ以外に大きな違いは無いのかも知れませんね。


##########################################################
今度はADOを使って無理やり非同期実験
別のmdbにファイルにADOでアクセスしています。

------------検証プログラム------------
Sub ado_test()
 Dim cnn(2) As New ADODB.Connection
 Dim SQL(6) As String
 Dim dbName As String
 Dim t As Double

 dbName = "c:\temp\db1.mdb"

 SQL(1) = "UPDATE T1 SET Data = '0';"
 SQL(2) = "UPDATE T1 SET Data = '1';"
 SQL(3) = "UPDATE T1 SET Data = '2' WHERE Data = '1';"
 
 SQL(4) = "UPDATE T2 SET Data = '0';"
 SQL(5) = "UPDATE T2 SET Data = '1';"
 SQL(6) = "UPDATE T2 SET Data = '2' WHERE Data = '1';"
 
 cnn(1).Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & dbName & ";"
 cnn(2).Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & dbName & ";"
 
'初期化
 cnn(1).Execute SQL(1)
 cnn(1).Execute SQL(4)

'同期実行テスト--------------------------------------------
 t = Timer()
 cnn(1).Execute SQL(2)
 cnn(1).Execute SQL(3)
 Debug.Print "同期実行  " & Format(Timer() - t, "0.00000")

'非同期実行テスト--------------------------------------------
 
 t = Timer()
 cnn(1).Execute SQL(5), , adAsyncExecute
 cnn(2).Execute SQL(6), , adAsyncExecute
 Debug.Print "非同期実行 " & Format(Timer() - t, "0.00000")
End Sub
---------------------------------------------------------
非同期の方が明らかに速いです。(処理を待たずに返ってくるので)
非同期の方は正しく更新できてません。

この検証プログラムが正しいのか?、あまり自信はありません(^^;
参考程度にして下さい。

##########################################################
補足
DAOかADOか?

http://www.naboki.net/access/heaven/heaven_14.html
http://homepage2.nifty.com/inform/vbdb/daoado.htm

DoCmd.RunSQL ですが、「非同期」であると幾つかのHPで見かけましたが、実際試してみると「同期」実行している感じです(Access2000で実験)。

実際「非同期」なんでしょうか?
オフィシャルなサイトに「非同期である」と言う記述はありますか?

------------検証プログラム------------
Sub local_test()
 Dim SQL(4) As String
 Dim t As Double

 SQL(1) = "UPDATE T1 SET Data = '0';"
 SQL(2) = "UPDATE T1 SET Data = '1';"
 
 SQL(3) = "UPDATE T2 SET Data = '0';"
 SQL(4) = "UPD...続きを読む

QACCESSでExcelにデータ出力、高速化

ACCESSのVBAを使ってテーブルのデータを
既存ブックに出力し、別名で保存をしたいのですが、
どうも、処理が遅くて困っています。
改善点がありましたら教えてくださいお願いいたします。

Dim objExcel As Excel.Application
Dim xlWrkbk As Excel.Workbook
Dim xlWrksh As Excel.Worksheet
Dim rs As DAO.Recordset
Dim strFilename As String

strFilename = CurrentProject.Path & "既存ブック名.XLS"

Set objExcel = New Excel.Application
Set xlWrkbk = objExcel.Workbooks.Open(Filename:=strFilename, ReadOnly:=True)
Set xlWrksh = xlWrkbk.Worksheets("シート名")

Set rs = CurrentDb.OpenRecordset("テーブル名", dbOpenSnapshot)

With objExcel
xlWrksh.Range("A:N").Clear
xlWrksh.Range("A2").CopyFromRecordset rs
xlWrkbk.SaveAs Filename:=CurrentProject.Path & "新しいブック名.xls"
xlWrkbk.Close
.Quit
rs.Close
End With

Set rs = Nothing
Set objExcel = Nothing
Set xlWrkbk = Nothing
Set xlWrksh = Nothing

ACCESSのVBAを使ってテーブルのデータを
既存ブックに出力し、別名で保存をしたいのですが、
どうも、処理が遅くて困っています。
改善点がありましたら教えてくださいお願いいたします。

Dim objExcel As Excel.Application
Dim xlWrkbk As Excel.Workbook
Dim xlWrksh As Excel.Worksheet
Dim rs As DAO.Recordset
Dim strFilename As String

strFilename = CurrentProject.Path & "既存ブック名.XLS"

Set objExcel = New Excel.Application
Set xlWrkbk = objExcel.Workbooks.Open(Filename:=strFilename, R...続きを読む

Aベストアンサー

内容吟味しないで申し訳ないですけど、既成のマクロでスプレッドシートにエクスポートするマクロが
あるので、それをつかったらどうでしょうか。
多分、レコードを1つづつ呼び出して書き込むよりかは早いかと。

ヘルプを見たところVBAでは、
docmd.TransferSpreadsheet(TransferType, SpreadsheetType, TableName, FileName, HasFieldNames, Range, UseOA)
を使うようです。
使い方の詳細は、ヘルプから参照して速さを比較してください。

Qデータベースの最適化をマクロでしたい

お世話になります。

Accessのマクロのコマンドで
データベースの最適化をしたいのですが、
「マクロまたはVisual Basicコードの実行中に、開いているデータベースを最適化することはできません。」とういうエラーメッセージが出て最適化されません。

マクロの一連の流れの最後で、データベースの最適化をしたいと
思っていますが、具体的にどのようにすれば、
データベースの最適化を実行できるのでしょうか?
※直前に「データベースを閉じる」的な物をいれられるのでしょうか?

素人で大変申し訳ございませんが、具体的に教えて頂ければ助かります。

Aベストアンサー

> マクロの一連の流れの最後で、データベースの最適化をしたいと
> 思っていますが、具体的にどのようにすれば、
> データベースの最適化を実行できるのでしょうか?

一連のマクロの最後に最適化するということなら可能だと思いますが、
一連の流れの途中に入れるは原理的に不可能だと思います。
最適化はいったんデータベースファイルを閉じますので。


方法は下記を参照ください。

Access2003以前の場合
開いているデータベースを最適化する(Access VBA)
http://www.ka-net.org/office/of05.html

Access2007
開いているデータベースを最適化する(Access 2007 VBA)
http://www.ka-net.org/office/of06.html

VBAになりますので、上記の Sub を Function に書き換えて、マクロの「プロシージャの実行」で呼び出します。


このQ&Aを見た人がよく見るQ&A

人気Q&Aランキング