Discussion:
There is not enough disk space for <my.dbf>
(too old to reply)
Dan Musicant
2011-05-30 23:43:40 UTC
Permalink
I have some FoxPro free tables on a machine on my LAN (Windows WORKGROUP
file sharing), and occasionally (now pretty frequent all of a sudden) I
get this message when I attempt to save data to a memo field of one of
these tables. VFP (9.0) just becomes unusable. I cannot close the table
from the Command Window. Help from the dialog indicates 3 possibilities:

1. Disk is full (NOT! It's a 250GB HD that's ~80 empty space)

2. Something about Novell and owners. I don't run Novell.

3. The file is over the 2GB limit for FoxPro tables. None of my tables
are large. The one that's hung now is under 25 MB.

The table remains open and there's nothing I can do. I have to kill the
VFP process from Task Manager to get out of this pickle. What could be
at play here?

Dan


Email: dmusicant at pacbell dot net
JayB
2011-05-31 00:29:39 UTC
Permalink
try running a chkdsk /f on that hard drive to repair file allocation table
a corrupt fat table could give you that symptom
Post by Dan Musicant
I have some FoxPro free tables on a machine on my LAN (Windows WORKGROUP
file sharing), and occasionally (now pretty frequent all of a sudden) I
get this message when I attempt to save data to a memo field of one of
these tables. VFP (9.0) just becomes unusable. I cannot close the table
1. Disk is full (NOT! It's a 250GB HD that's ~80 empty space)
2. Something about Novell and owners. I don't run Novell.
3. The file is over the 2GB limit for FoxPro tables. None of my tables
are large. The one that's hung now is under 25 MB.
The table remains open and there's nothing I can do. I have to kill the
VFP process from Task Manager to get out of this pickle. What could be
at play here?
Dan
Email: dmusicant at pacbell dot net
Dan Freeman
2011-05-31 01:22:09 UTC
Permalink
Post by Dan Musicant
I have some FoxPro free tables on a machine on my LAN (Windows WORKGROUP
file sharing), and occasionally (now pretty frequent all of a sudden) I
get this message when I attempt to save data to a memo field of one of
these tables. VFP (9.0) just becomes unusable. I cannot close the table
1. Disk is full (NOT! It's a 250GB HD that's ~80 empty space)
2. Something about Novell and owners. I don't run Novell.
3. The file is over the 2GB limit for FoxPro tables. None of my tables
are large. The one that's hung now is under 25 MB.
The table remains open and there's nothing I can do. I have to kill the
VFP process from Task Manager to get out of this pickle. What could be
at play here?
Dan
Email: dmusicant at pacbell dot net
That note about file ownership on Novell applies elsewhere as well. It
was just discovered first on Novell. A *LOT* of common problems in the
early days of networking were attributed first to Novell because that's
what most people used. It was only later that we realized they were
more generic file sharing errors applicable to most environments.

You mention memo fields. Remember that for any save, you may need disk
space equaling three times the size of the FPT file -- and that's just
what Foxpro wants. No telling what Windows' cacheing wants.

Dan
Gene Wirchenko
2011-05-31 18:45:42 UTC
Permalink
Post by Dan Musicant
I have some FoxPro free tables on a machine on my LAN (Windows WORKGROUP
file sharing), and occasionally (now pretty frequent all of a sudden) I
get this message when I attempt to save data to a memo field of one of
these tables. VFP (9.0) just becomes unusable. I cannot close the table
1. Disk is full (NOT! It's a 250GB HD that's ~80 empty space)
^
Something is missing here. I suspect that it is either "%" or
"GB". Either way, disk space does not seem to be an issue.
Post by Dan Musicant
2. Something about Novell and owners. I don't run Novell.
3. The file is over the 2GB limit for FoxPro tables. None of my tables
are large. The one that's hung now is under 25 MB.
<25 MB according to what? Remember that VFP splits out the memo
columns into the .fpt. The memos may need to be packed.

Someone more knowledgable than I might know if a different set
blocksize setting could make a difference.
Post by Dan Musicant
The table remains open and there's nothing I can do. I have to kill the
VFP process from Task Manager to get out of this pickle. What could be
at play here?
I do not know. Consider my suggestions as guesses.

Sincerely,

Gene Wirchenko
Dan Musicant
2011-05-31 22:06:19 UTC
Permalink
On Tue, 31 May 2011 11:45:42 -0700, Gene Wirchenko <***@ocis.net>
wrote:

:On Mon, 30 May 2011 16:43:40 -0700, Dan Musicant <***@privacy.net>
:wrote:
:
:>I have some FoxPro free tables on a machine on my LAN (Windows WORKGROUP
:>file sharing), and occasionally (now pretty frequent all of a sudden) I
:>get this message when I attempt to save data to a memo field of one of
:>these tables. VFP (9.0) just becomes unusable. I cannot close the table
:>from the Command Window. Help from the dialog indicates 3 possibilities:
:>
:>1. Disk is full (NOT! It's a 250GB HD that's ~80 empty space)

: ^
: Something is missing here. I suspect that it is either "%" or
:"GB". Either way, disk space does not seem to be an issue.

Yes, it was %, the drive is only ~20% full.
:
:>2. Something about Novell and owners. I don't run Novell.
:>
:>3. The file is over the 2GB limit for FoxPro tables. None of my tables
:>are large. The one that's hung now is under 25 MB.
:
: <25 MB according to what? Remember that VFP splits out the memo
:columns into the .fpt. The memos may need to be packed.

The dbf is 212KB, the cdx 155KB and the fpt is about 21.6MB. I don't
normally have the problem and it hasn't reoccured since I posted
yesterday. I suppose I should do a chkdsk /f on the HD. Thing is I
routinely write data to the memo fields of these tables and there are
hundreds of them. I never know when this will happen. At times I'm able
to copy the unsaved data to my clipboard and from there to a text file
for later addition to the memo field after I've cleared up the problem.
It has happened, however in circumstances where I haven't been able to
access the unsaved data and it's lost.

Dan
:
: Someone more knowledgable than I might know if a different set
:blocksize setting could make a difference.
:
:>The table remains open and there's nothing I can do. I have to kill the
:>VFP process from Task Manager to get out of this pickle. What could be
:>at play here?
:
: I do not know. Consider my suggestions as guesses.
:
:Sincerely,
:
:Gene Wirchenko



Email: dmusicant at pacbell dot net

Loading...