Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Insufficient disk space redux

Status
Not open for further replies.

jlockley

Technical User
Nov 28, 2001
1,522
US
Once again I am frustrated in attempting to restructure or export a large table with the message "insufficient disk space". There are about 8 gb available, which really ought to be enough for the table and every cousin it had.

Last time I tried resetting bde directory and finally ended up by creating a new database and importing using the borrow structure option (which I am looking for now without much success.) When I did I got some oddly different file sizes on the new form without apparently losing records or information.

I wonder if anyone has any recent experience (or unreported old experience) with this phenomenon? This is P8. I understand from the last time this happened that it also happens with 7 and 10. I am thinking this may have something to do with the windows environment? Thanks. JLL
 
jlockley,

Could be a couple of things:

1. Verify that :pRIV: (your private directory) and %TEMP% (the Windows TEMP directory) have 3-5 times the size of the table (and its indexes) available. If not, that's probably why you're running out of space. Either free some up or move these locations to a drive with more space.

2. The table (or one of its indexes) could be corrupted. I've seen cases where these would cause erroneous "out of space" errors. To test this, do a CheckAll query against the table and see if you can restructure that. Also, make sure you got all your data. If you can restructure it, then the problem is likely one of your indexes and I'd probably just re-create those on the ANSWER table.

Hope this helps...

-- Lance
 
Thanks, footpad.

The private folder has plenty of space, but I wonder if it is the %temp% directory, which is on the fulller C drive. I found a work around last nigh - simply moved the table with object file to another partition and it worked, but I'd like to be able to do it on the fly.

The table doesn't seem to be corrupted from the table repair utility. I don't know about a checkall query, but I will look it up.

I believe I couldn't query the table for the same reason the last time around. How would I recreate the index in an answer table? JLL
 
JLL,

%TEMP% is usually on C:. You can check this by running the SET command from a command prompt.

If it is the TEMP drive, you can change it from an AUTOEXEC.BAT file, though I know some people don't recommend doing so.

A CheckAll query is my way of saying "a query that selects all fields and all records" from the table. You can do this in a couple of different ways:

1. Using QBE:

1.1 Create a new QBE query containing your table.
1.2 When you get to the horizonal criteria window, press Shift+F6 twice. This places a CheckPlus in every field in your table.
1.3 Press F8 to run the query.

2. Using SQL:

SELECT * FROM TABLENAME

If you have problems running the query, then it probably is a disk space issue. Try moving your private directory (which I will wager is currently on C:) from the Database tab of the Preferences dialog.

Hope this helps...

-- Lance
 
Lance: AHA - a check ALL query. Moving %temp% and %tmp% via the control panel to a partition with 10G free did not solve the problem. The query, which moved it to the same area, did. One of the related files must be involved, and not the index, as I copied that with the db and blob files when I moved them. Very odd. Thanks a lot footpad.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top