> 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.

> 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.

> > 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.
> -----------------------------------------------------------------

> 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.

>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.

>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.