|
| | KB005: Avoiding Table and Index Corruption
Topic: Visual FoxPro
Last updated: May 10, 2001
Database corruption can appear in many forms. Error messages such as
"Not a table or DBF" indicate problems with your data. There are some
types of corruption that are difficult to detect. For example, binary data in a
numeric field can cause the field to look correct, but not be included in
calculations. A good DBF repair tool is recommended. You can purchase such tools
from Hallogram Publishing or the Stonefield
Database Toolkit.
However, there are things you can do to avoid errors.
- If users turn off their PC without properly exiting your application, data
could still be in the PC's data buffer. In this case, the data is not
written to the network. Add the
FLUSH command to the Save
routines of your application. This will force the local data buffers to be
written to the network. I charge my clients 3x my standard rate to fix
corrupted data. This makes them think about exiting the proper way.
- Don't edit the data directly. Instead, use data buffering.
- There are known issues with some versions of Novell Client 32 and FoxPro.
You should download the latest version of Client 32 from the Novell
web site.
- Use transactions.
A July, 1999 thread on the newsgroup microsoft.public.fox.programmer.exchange
listed the following causes of corruption:
- Turning off the server or workstation with a table open
- Hardware conflict
- Viruses
- Full duplex NIC cards
- Manipulating FoxPro tables with old FoxPro/dBase software
- Manipulating tables with other software, for example, Excel or Word
- Garbage In/Garbage Out
- Bad business rules
- Rounding errors
- Calculation errors
- Poor logic
- People deleting index or memo files
- Bad memory on the workstation or server
- Bad router
- File caching problems on the workstation or server
Thanks to Mike Fernald, Liz Kimber, and Vladimir Mikhelson for providing help
with compiling this list.
|