テンポラリファイルのための空き容量が不足しています

アクセスでクエリーを実行すると、上記の警告が発生しクエリーがとまってしまいます。
tmpファイルのことかな？と考え、ディスクのクリーンアップは行いましたが、状況はかわりません。
もともと正常に作動するアクセスのファイルをコピーしまして、そのなかのクエリーのひとつを少々変更して実行しているのですが、コピーをしなおしたりしても、上記の警告が必ず発生します。（コピー元やその他のファイルは正常に作動します）
原因がわからず困っております。宜しくお願い申し上げます。
当方W98　アクセス95、です。

No.6 ベストアンサー 回答者： yanmaa 回答日時： 2001/12/13 18:27

じゃあそろそろ最後にしようかな。

基本的な話をしましょう。
検索条件になっている項目についてはインデックス(索引)があるかないかによって検索する件数が異なってきます。

５万件あるデータに関して現在のような検索をすると５万件全て検索します。

ですからインデックスを作成して等しいか(＝)という判断条件にすることによって検索する件数を最小限にすることが出来ます。

但しインデックスをつけると追加や更新の速度が遅くなります。

またジョインは大きな表を作ることになりますのでその為メモリを大量に消費します。

このためメモリ消費を押さえる為、ジョインはできるだけ少なくするとか、事前に必要分だけワークテーブルに格納してからジョインするとかの対策をとります。
プログラムを作ってねと言う意味(VBAで良いですよ)

またWindwows98ですよね。メモリは64Mか128M程度かなと予測しますが、これでは非常に危険ですね。そもそもwindows98系はメモリの使い方が下手なので大量データを扱うには向いていないのです。

だから件数とファイルサイズを聞いたのです。２回目の回答の参考URLはご覧になりました？いや実際壊れたら目も当てられない状況になりたくないならバックアップ＆まともなDBMSにすることをお勧めします。

それはさて置き
追加件数が125000ですよね。ベースになるテーブルは47000件ですので増加されていますよね。

125000件×31項目×20バイト(平均項目のバイト数)とすると77.5MB程度の作業領域が必要になりますね。実際にはこれより多かったりしますがいいのですかこんなに毎月増えて？
また経験から実メモリの２倍から３倍のスワップファイルサイズになるような場合は非常に不安定な状況になります。

ここから質問＆回答タイム
ykkw_2001>確信はないですが、クエリ式がこれだけ長くなると、SQLサーバーに渡すときとかヤバくないかな？なんてね
ところでyukiko5さんSQLServeなんてお使いなのですか？
そういった記述はないのでDBはAccess95だと思っているのですが...

yukiko5>軽くする（という表現があっているかはわかりませんが）
あってますよ。

yukiko5>なんだか全部ちからワザ
いや1回きりのものならそういうのもありなのですが毎月使うようなものでかつデータ量が増えるような場合はやっぱり力技だけでなく技がいりますね。

yukiko5>問題は解決しましたが、すっきりしません。
ykkw_2001>Ｍ＄の製品はそういうのが多いですね。
ykkw_2001>　「ゲイツ病」と言うそうです。
いやはや全くその通りですね。頭が痛いですね。いつものことだから諦めています。これもＭｓ製品との付き合い方一つです。

お暇ならこのサイトで過去質問をみるのもいいでしょう。

最後に
ykkw_2001>手元にAccess97 しかないので確認取れませんが、以前のAccessでクエリ実行後、MDBに残りカスが蓄積されていったことがあります。

トランザクションログ周りですかねこれは削除/更新をすると作業中の内容を覚えておき、何かあったときに戻せるようにする仕組みが働くのでこの関係かな。Access2000では閉じる時に最適化が出来るようになりましたね。

それではMSのサイトや各種参考書を片手にがんばってよいものを作ってください。

この回答へのお礼

>基本的な話をしましょう。
ありがとうございました。とても参考になりました。

>２回目の回答の参考URLはご覧になりました？
はい。ちょっと怖くなりました。
バックアップはこまめにとっております。

>いいのですかこんなに毎月増えて？
この請求明細にかんしてだけは、
月ごとのファイルを別々にしておりますので、大丈夫です。
（じゃナゼ請求月を検索しているのか？
　ムダに思えますが、私の前任者の趣味のようでして、
　ほとんどそういう方式をとっているようです。
　慎重といえば慎重なのですが。。。）


>ところでyukiko5さんSQLServeなんてお使いなのですか？
>DBはAccess95だと思っているのですが...
使ってません。意味もわかってませんでした。
アクセスは95です。
ちなみにVBAも未開の地です。今後開拓したいです。

>>軽くする（という表現があっているかはわかりませんが）
>あってますよ。
ありがとうございます。

>やっぱり力技だけでなく技がいりますね。
今回、皆様の指摘により痛感しました。
軽くする工夫から始めたいと思います。

>サイトや各種参考書を片手にがんばってよいものを作ってください。
長々とお付き合い頂きまして、本当にありがとうございました。

お礼日時：2001/12/14 10:58

No.8 回答者： ykkw_2001 回答日時： 2001/12/13 21:51

あ、それから

入金済みのレコードを引き落とす（削除する）とか、請求月ごとに別テーブルにするとか
根本的な流れの対策もお忘れなく。

この回答へのお礼

はい、わかりました。
ありがとうございました。

お礼日時：2001/12/14 11:09

No.7 回答者： ykkw_2001 回答日時： 2001/12/13 21:40

おこんばんわ、ykkw_2001です。

＃でも、yukiko5さんは、朝か・・・

＞ykkw_2001さんのご意見も
　と言われるほどのものはないです。

＞全部ちからワザで、えいやー！
で、できてしまうのが、Accessのいいとこで、悪いとこでもありますね。

＞47000件です。
＞最終的に125000件

　ぐえ。

　そらあんさん、「えいやー！」って、やり過ぎでっせ。

＞ほかにもコレ級のファイルがちらほらありまして、、、
　Win98で！！
　おめでとう。レコード件数では、私の知る限り最高記録達成です。
勇者の称号と栄光を授けます。

んで。

要は、yanmaaさんのおっしゃるような対策ですな。

とりあえずローテクな私としては、
＞事前に必要分だけワークテーブルに格納してから
てのが、おすすめです。

指針としては、
いっぱいJOINされている中心的なテーブルから、該当する請求月のレコードだけのテーブルを一時的に作成する。必要なフィールドだけね。
そのテーブルに各マスタから、何段階かに分けて、必要なフィールドをつけてゆく。
最後に請求明細に追加。かな。
できれば、別の一時的なMDBファイル上でやりたいです。

＃SQL全部見てませんけど
相当遅くなると思いますが、「落ちる」よりはいいでしょう。

あとは、
＞バックアップ
　ぜぇーったい、やりましょうね。
＃やってなかったら、「勇者」から「挑戦者」に格上げします。

＞まともなDBMSにする
　Oracleあたりでも、大丈夫なのかなぁ。

yanmaaさん江
＞トランザクションログ周りですかね
　嗚呼、そーだったんかぁ。

＞Access2000では閉じる時に最適化が出来るようになりましたね。
　おお、こいつぁいいことを教えてもらった。
ありがとうございます。

＃回答欄にお礼を書いたんは初めてですわ。

でわ、健闘を祈ります。

この回答へのお礼

>おこんばんわ、ykkw_2001です。
おはようございます。おっはー。

>そらあんさん、「えいやー！」って、やり過ぎでっせ。
自分の無謀さに初めて気が付きました。
皆さんのご指導を元に、今後はちゃんと工夫します。反省。。。

＞バックアップ
＃やってなかったら、「勇者」から「挑戦者」に格上げします。
なんかちょっと「おしかったな～」思っている自分にパンチ！
社内データですから挑戦しちゃいけないですよね。
もちろん、無謀な挑戦者なんて、いけないですよね。

＞でわ、健闘を祈ります。
本当に長々とお付き合いいただきまして、ありがとうございました。

お礼日時：2001/12/14 11:08

No.5 回答者： yanmaa 回答日時： 2001/12/13 13:15

これは大抵テンポラリファイルが大きくなりすぎた為でしょう。

ですからNo2は取り合えず気にしなくて結構です。

SQL文を見ると追加クエリのようですね。
「請求明細（西日本）」テーブルから各種マスタテーブルに各種情報を付加するクエリですね。
この結果を請求書明細データに追加しているようですね。

ここで問題になってくるのは「請求明細（西日本）」のテーブルに登録されている件数です。数件や１万件程度なら問題ないですが件数が多くなるとトランザクションログといわれるファイルが膨大になり処理時間も遅くなります。

またMDBのサイズが100MBという事はかなり大きなDBだと思います。参考URLも参考にして下さい。

最後にクエリのWHERE (((Left([請求日],6))=[【請求月】])) は条件ですが、Left関数を使っておりますので該当テーブルを全件検索しています
これもテンポラリファイルを増大させる要因です。
元のテーブルに請求年月というフィールドを追加し、インデックスをつけ(重複あり)このフィールドで条件にしましょう。
該当テーブルにデータ登録時は請求日と請求年月に同時に書き込み検索時は請求年月を検索する。

請求年月は請求日の左６桁とします。

旧のデータは更新クエリで請求年月=LEFT(請求日,6)で更新しておきましょう。

参考URL：http://www.okweb.ne.jp/kotaeru.php3?q=146304

この回答へのお礼

>SQL文を見ると
はい。そうです。

>「請求明細（西日本）」のテーブルに登録されている件数
47000件です。
追加される「請求明細データ」は最終的に125000件になります。
処理時間もPCが新しくなってからは30秒くらいで終わるので、
ファイルの大きさなどはまったく気にしておりませんでした。
ほかにもコレ級のファイルがちらほらありまして、、、
ちょっと件数をお伝えするのが恥ずかしかったです。

>WHERE (((Left([請求日],6))=[【請求月】])) は条件ですが
軽くする（という表現があっているかはわかりませんが）
工夫が必要なんですね。
こうして教えていただいて、自分の作成したクエリーを見直してみると、
なんだか全部ちからワザで、えいやー！とやっているようなのばかりみたいです。
今後の課題として精進していこうと思います。

No4に記入したように、ykkw_2001さんのご意見も聞いてみたく思います。
締め切りは絶対にしますので、少々お待ちいただければと思います。
（遅くても明日には締め切るようにいたします）

かなり面倒なことにもかかわらず、ご丁寧にご指導いただきまして、
本当にありがとうございました。

お礼日時：2001/12/13 16:53

No.4 回答者： ykkw_2001 回答日時： 2001/12/13 13:03

＞107506KBです。

完成するとその1.5倍くらいになります。

手元にAccess97 しかないので確認取れませんが、以前のAccessでクエリ実行後、MDBに残りカスが蓄積されていったことがあります。具体的には、データを増やしていないのに実行を重ねるとファイルサイズが大きくなっていきました。（最適化後で比較しました）
で、MDBが大きくなると、「クエリ式が適当でない」とか、「テーブルが不正だ」とかとんでもないイチャモンを付け出して、良く分からんまま、MDBを分割すると解決してしまいました。

サイズからして、分割を検討されたらいかがかなと思いました。

＞>INSERT INTO 請求明細データ ・・・・

確信はないですが、クエリ式がこれだけ長くなると、SQLサーバーに渡すときとかヤバくないかな？なんてね。
私なら、アスタリスク（＊）をうまく使うとか、何段階かのテーブル作成クエリに分割して途中経過のテンポラリテーブルを作るとか、あれこれやりたくなる状況です。

＞問題は解決しましたが、すっきりしません。
Ｍ＄の製品はそういうのが多いですね。
　「ゲイツ病」と言うそうです。

＞上記の件だけで原因を特定するのは非常に難しいかと思いますが、
yanmaaさんのご意見を伺いたいとこですね。

ひとまず、解決をお慶び申し上げます。

この回答へのお礼

>サイズからして、分割を検討されたらいかがかなと思いました。
完成したら200000KBになってしまいました。
多分もとのデータのテーブルが大きいだけだと思います。
クエリーやその他のテーブルは多くないのです。
分割するには少々頭をひねらなければ。。。。


>何段階かのテーブル作成クエリに分割して
確かに分割した方が、後々もわかりやすいですよね。
実はもうちょっとすっきりしたクエリーにしたく、
その前段階の変更をしてみたところ、この事態に陥りました。

>yanmaaさんのご意見を伺いたいとこですね。
yanmaaさんのご意見はいかがでしたでしょうか？
なにかykkw_2001さんからもあるかと思い、
締め切りしないでちょっと待ってみます。
よろしければ書込みお願い申し上げます。

>ひとまず、解決をお慶び申し上げます
ありがとうございました。

お礼日時：2001/12/13 16:40

No.3 回答者： yanmaa 回答日時： 2001/12/12 17:08

No2の補足について

MS-DOSプロンプトを起動してSETと入力してEnterします。
そうすると環境変数の一覧が表示されるので
TEMP=なにがし
という行があります。
デフォルトなら
TEMP=C:\WINDOWS\TEMP
となっているかと思います。
これが環境変数の[TEMP]のことです。

ここまでが前置きで次に本題に入ります。

下記の質問に対して補足願います。
注意：作業はバックアップを取ってから行いましょう。

1.AccessのMDBファイルのサイズはどの位でしょうか？
2.MDBの最適化を行っても現象は変わらないでしょうか？
3.修正したと言うクエリーだけが該当メッセージを出すのでしょうか？
4.MDBの修復を行っても現象は変わらないでしょうか？
5.３で他のクエリー及び元のクエリーに戻した時は正常に動いたならば修正後のクエリーを提示してください。
テーブルの構成もお願いします。

まあこの程度かなまだあるような気もしますが

クエリーはデザインビューを開き[表示]-[SQLビュー]を選択して下さい。そこに表示されている内容をカット＆ペーストして下さい。

この回答への補足

おはようございます。丁寧なご指導ありがとうございました。

ただ申し訳ないのですが、なんとか動くようになりました。
どうしてだかは不明です。

いろいろこちらでも試行錯誤を重ねているうちに、
「JOIN式が一致しない」というメッセージまで出てきてしまい、
やっとその意味がわかり訂正したところ、動きました。
テンポラリファイルじゃないの？？？
と、少々憤慨ですが、結果オーライとすることにしました。
お付き合い頂いておりました皆々様には大変申し訳ございません。

一応yanmaaさんの補足要求の結果をお知らせします。

>MS-DOSプロンプト

C:\WINDOWS>set
TMP=c:\windows\TEMP
TEMP=C:\windows\TEMP
PROMPT=$p$g
winbootdir=C:\WINDOWS
COMSPEC=C:\WINDOWS\COMMAND.COM
PATH=C:\WINDOWS;C:\WINDOWS;C:\WINDOWS\COMMAND;D:\SKYNEC
windir=C:\WINDOWS
BLASTER=A220 I5 D1 T4 P330

以上です。読取専用なのかどうかはわかりませんでした。

>1.AccessのMDBファイルのサイズはどの位でしょうか？
107506KBです。完成するとその1.5倍くらいになります。

2.MDBの最適化を行っても現象は変わらないでしょうか？
>変わりませんでした。

3.修正したと言うクエリーだけが該当メッセージを出すのでしょうか？
>データ元のみ違って、クエリーの型が同じものがあと２つあるのですが、
それらについては同じ結果でした。
違う型のクエリーは作動しました。

4.MDBの修復を行っても現象は変わらないでしょうか？
>変わりませんんでした。

5.３で他のクエリー及び元のクエリーに戻した時は正常に動いたならば修正後のクエリーを提示してください。テーブルの構成もお願いします

>INSERT INTO 請求明細データ ( 請求月, 部コード, 部名, 部門コード, 部門名, 営業担当者コード, 担当者名, 取引先コード, 得意先名, 現場コード, 現場名, 請求日, 行No., 日付, 品種コード, 品種名, 商品コード, 品名, 規格, 区分, 数量, 返却数, 日数, 単価, 金額, 摘要, 期間Pe, 期間Ｔ, 伝票No., 加算区分, 締日更新区分 )
SELECT DISTINCTROW Left([請求日],6) AS 請求月, 部マスタ.部コード, 部マスタ.部名, 得意先マスタ西日本.部門コード, 部マスタ.部門名, 得意先マスタ西日本.営業担当者コード, 担当者マスタ.担当者名, 請求明細（西日本）.得意諠Rード, 得意先マスタ西日本.得意先名, 請求明細（西日本）.現場コード, [Q:現場マスタ（西日本）].現場名, 請求明細（西日本）.請求日, 請求明細（西日本）.行No., 請求明細（西日本）.日付, 商品マスタ.品種コード, 品種マスタ.品種名, 請求明細（西日本）.商品コード, 商品マスタ.品名, 商品マスタ.規格, 請求明細（西日本）.取引区分, 請求明細（西日本）.数量, 請求明細（西日本）.返却数, 請求明細（西日本）.日数, 請求明細（西日本）.単価, 請求明細（西日本）.金額, 請求明細（西日本）.摘要, 請求明細（西日本）.期間ＦＲＯＭ, 請求明細（西日本）.期間ＴＯ, 請求明細（西日本）.伝票No., 請求明細（西日本）.加算区分, 請求明細（西日本）.締日更新区分
FROM (((請求明細（西日本） LEFT JOIN 商品マスタ ON 請求明細（西日本）.商品コード = 商品マスタ.商品コード) LEFT JOIN 品種マスタ ON 商品マスタ.品種コーh = 品種マスタ.品種コード) LEFT JOIN ((得意先マスタ西日本 LEFT JOIN 担当者マスタ ON 得意先マスタ西日本.営業担当者コード = 担当者マスタ.担当者コード) LEFT JOIN 部マスタ ON 得意先マスタ西日本.部門コード = 部マスタ.部門コード) ON 請求明細（西日本）.得意先コード = 得意先マスタ西日本.取引先コード) LEFT JOIN [Q:現場マスタ（西日本）] ON (請求明細（西日本）.現場コード = [Q:現場マスタ（西日本）].現場コード) AND (請求明細（西日本）.得意先コード = [Q:現場マスタ（西日本）].得意先コード)
WHERE (((Left([請求日],6))=[【請求月z]))
ORDER BY 得意先マスタ西日本.部門コード, 得意先マスタ西日本.営業担当者コード, 請求明細（西日本）.得意先コード, 請求明細（西日本）.現場コード, 請求明細（西日本）.行No.;

これでよろしいでしょうか？

問題は解決しましたが、すっきりしません。
上記の件だけで原因を特定するのは非常に難しいかと思いますが、
よろしければ何がしかのご指導をいただければ幸いです。
特にご連絡がないようでしたら、明日には〆切らさせていただきます。
ありがとうございました。

補足日時：2001/12/13 10:23

No.2 回答者： ykkw_2001 回答日時： 2001/12/12 15:48

＞もともと正常に作動するアクセスのファイルをコピーしまして

コピーによって、正常に動作していた環境と変ってませんか？


＞環境変数 TEMP で指定されているフォルダがあるドライブに、空き容量がありません。
＞そのドライブのファイルを削除するか、環境変数 TEMP で別のドライブを指定します。
＞環境変数 TEMP で指定されているドライブまたはフォルダが無効または読み取り専用になっています。
＞環境変数 TEMP で有効なドライブを指定するか、現在指定されているドライブまたはフォルダの読み取り専用の制限を解除します。

だそうですが、

この回答への補足

＞＞もともと正常に作動するアクセスのファイルをコピーしまして
＞コピーによって、正常に動作していた環境と変ってませんか？
単純なコピーのため、環境は変わっていないと思われます。

その下の長文に関しては、ほとんど意味がわかりませんでした。
Cドライブには空容量はあるようです。
「環境変数TEMP」がわかりませんでした。
C:\WINDOWS\TEMP　は読み取り専用にはなっていないようです。

できましたらもうすこし詳しく教えていただければ幸いです。
宜しくお願い申し上げます。

補足日時：2001/12/12 15:55

No.1 回答者： coolguys 回答日時： 2001/12/12 15:26

HDDの残容量ってどのくらい残ってますか？

この回答への補足

Cドライブの通常時の空容量は1Gくらいです。
問題のアクセスファイルを開くと残りが800Mくらい。
クエリーがとまってしまった時の残りが600Mくらいでした。
よろしくお願いします。

補足日時：2001/12/12 15:37