Very Computer

by **Gary Hal** » Thu, 21 May 1998 04:00:00

I have a Visual Basic App which accesses a FoxPro 2.6 database. The
database is read from and written to and currently contains about a
thousand records with each of these records having about 500 characters
within them.

Users are writing data to the database regularly and we have recently come
up with an error message that says "Error: Not a table/DBF". I have had to
restore the backup of the data file and run with that, but within a week
the same error occurs. I then rewrote the .dbf file, copied the existing
data into it and within a week the same error occurred.

Has anyone else experienced this problem? How do I get around this? It
doesn't seem to be a problem with the file as I have rewritten it. Is there
only a certain amount of data that a .dbf file can hold?

Any replies would be gratefully accepted as this is now becoming a problem.

Thanks.

by **Joe Faulhabe** » Thu, 21 May 1998 04:00:00

> x-no-archive: yes

> > error message that says "Error: Not a table/DBF".

> I have experienced the "Not a Database File" error many times. This
> problem is really not that serious if you know how to handle it. It is
> seldom seen in a single user environment and is much more common in a
> peer-to-peer non-dedicated server situation than on a Novell network
> with a dedicated
> server.

> On a Novell network with a dedicated server this problem will
> *frequently* occur if the server goes down, in power outage, for
> example. For this reason an uninterruptable power supply (UPS) is
> recommended for the server if power interruptions are a problem in your
> area.

> Usually, though not always:

> 1) The DBF file actual, physical record count does not match the record
> count in the DBF file header.
> 2) The DBF header record count contains one more record than is
> actually
> (physically) present.
> 3) If you decrement the record count in the DBF header by one the DBF
> file pops right back.

Bob is exactly correct on the cause of the problem, some station is issuing
a partial write to the file (probably because the machine goes down).

The real fix for this is to move to client/server, the Advantage Database
Server is a good choice for DBF files, if the cost/effort of fixing is
worth adding Advantage into the system.

Joe
----------

Software Engineeer "He had no time for pain,
Extended Systems, Inc. "no energy for anger."
www.extendsys.com Ayn Rand

by **Paul Le** » Fri, 22 May 1998 04:00:00

> I have a Visual Basic App which accesses a FoxPro 2.6 database. The
> database is read from and written to and currently contains about a
> thousand records with each of these records having about 500 characters
> within them.

> Users are writing data to the database regularly and we have recently come
> up with an error message that says "Error: Not a table/DBF". I have had to
> restore the backup of the data file and run with that, but within a week
> the same error occurs. I then rewrote the .dbf file, copied the existing
> data into it and within a week the same error occurred.

> Has anyone else experienced this problem? How do I get around this? It
> doesn't seem to be a problem with the file as I have rewritten it. Is there
> only a certain amount of data that a .dbf file can hold?

> Any replies would be gratefully accepted as this is now becoming a problem.

If you do not find the permanent solution to the problem soon, a
database file fix
utility may be faster and easier than backups/etc. and will restore more
records for you.

Check out our 'Recover' utility on our web site http://www.abri.com/
A single user license is only $70.

-----------------------------------------------------------------
Paul Lee ........... Abri Technologies ......... http://abri.com/
'Recover' - top rated FoxPro file repair utility.
-----------------------------------------------------------------

by **Hal Davit** » Sat, 23 May 1998 04:00:00

I have an app that is prone to being shut down without proper exit, my
programming errors, and many other problems.

So before I open, I just do a length check with fseek and fread. And a
fix with fwrite. Then I open.

Kludge city, but it works.

> > I have a Visual Basic App which accesses a FoxPro 2.6 database. The
> > database is read from and written to and currently contains about a
> > thousand records with each of these records having about 500 characters
> > within them.

> > Users are writing data to the database regularly and we have recently come
> > up with an error message that says "Error: Not a table/DBF". I have had to
> > restore the backup of the data file and run with that, but within a week
> > the same error occurs. I then rewrote the .dbf file, copied the existing
> > data into it and within a week the same error occurred.

> > Has anyone else experienced this problem? How do I get around this? It
> > doesn't seem to be a problem with the file as I have rewritten it. Is there
> > only a certain amount of data that a .dbf file can hold?

> > Any replies would be gratefully accepted as this is now becoming a problem.

> If you do not find the permanent solution to the problem soon, a
> database file fix
> utility may be faster and easier than backups/etc. and will restore more
> records for you.

> Check out our 'Recover' utility on our web site http://www.abri.com/
> A single user license is only $70.

> -----------------------------------------------------------------
> Paul Lee ........... Abri Technologies ......... http://abri.com/
> 'Recover' - top rated FoxPro file repair utility.
> -----------------------------------------------------------------

by **MBALL** » Sat, 23 May 1998 04:00:00

If you can open the file in VFP, you can add a record and then delete it and
that should solve the problem too.
Mike Ballai

Try DBRITE -- the better FoxPro Tablemaker shareware program

by **Greg Landr** » Tue, 16 Jun 1998 04:00:00

Hi Gary,

You've been given plenty of good advice on fixing the error when it occurs,
but I haven't seen what the root of the problem is yet. In my experience, it
usually boils down to a single user who likes to turn of their computer
without properly shutting down. I would check this first.

My permanent solution has been to use FoxFix in the nightly maintenance
routine (since I couldn't break the bad habits of the users). It just opens
the files with FF and if there's an error, it fixes it automatically and then
dumps a repair log out to a file with the details.

With this setup, I haven't had a call related to a file error in over 2 years.

HTH,
Greg

<snip>

Quote:> Users are writing data to the database regularly and we have recently come
> up with an error message that says "Error: Not a table/DBF". I have had to
> restore the backup of the data file and run with that, but within a week
> the same error occurs. I then rewrote the .dbf file, copied the existing
> data into it and within a week the same error occurred.

<snip>

by **ZorkBe** » Wed, 24 Jun 1998 04:00:00

Quote:>You've been given plenty of good advice on fixing the error when it occurs,
>but I haven't seen what the root of the problem is yet. In my experience, it
>usually boils down to a single user who likes to turn of their computer
>without properly shutting down. I would check this first.

>My permanent solution has been to use FoxFix in the nightly maintenance
>routine (since I couldn't break the bad habits of the users). It just opens
>the files with FF and if there's an error, it fixes it automatically and then
>dumps a repair log out to a file with the details.

>With this setup, I haven't had a call related to a file error in over 2
>years.

Its a real shame that knuckle headed users cant learn a few simple lessons,
like how to shut down Windows 95.. I recommend a 2 x 4 as a teaching tool.. but
beyond that, there are a couple other ways to help prevent this problem.
First, if feasible put a FLUSH command at appropriate places in the program.
This will force the network to dump the data to the hard media. Secondly, you
can turn down the cache level on the network client if they use Client32 from
novell. This may slow performance slightly, but it should cut down the chance
of having a corrupted database.

Mike Occhipinti

by **Greg Landr** » Wed, 24 Jun 1998 04:00:00

Amen to the proper teaching tools. ;-)

I've got the FLUSHes in place, but how do you go about turning down
the Client32 cache level? Is this done from the client's machine?

Greg

> Its a real shame that knuckle headed users cant learn a few simple lessons,
> like how to shut down Windows 95.. I recommend a 2 x 4 as a teaching tool.. but
> beyond that, there are a couple other ways to help prevent this problem.
> First, if feasible put a FLUSH command at appropriate places in the program.
> This will force the network to dump the data to the hard media. Secondly, you
> can turn down the cache level on the network client if they use Client32 from
> novell. This may slow performance slightly, but it should cut down the chance
> of having a corrupted database.

by **Alexandre Pechtchans** » Thu, 25 Jun 1998 04:00:00

[ Courtesy cc'ed through e-mail to the quoted author ]

Quote:>Amen to the proper teaching tools. ;-)

>I've got the FLUSHes in place, but how do you go about turning down
>the Client32 cache level? Is this done from the client's machine?

Yes. Start/Settings/Control Panel/Network/Novell Netware Client 32/
Properties/Advanced Settings/File Cache Level.

[ When replying, remove *'s from address ]
Alexandre Pechtchanski, Systems Manager, RUH, NY

by **Greg Landr** » Thu, 25 Jun 1998 04:00:00

Thanks Alexandre.
Greg

> Yes. Start/Settings/Control Panel/Network/Novell Netware Client 32/
> Properties/Advanced Settings/File Cache Level.