What could continually trash a dBase III file by inserting 28 NUL's at the begining of the file?

"28 NULL characters inserted ..."  Do you really mean inserted or overwritten? But it does not matter probably. The cause could be:

1) Invalid software
1a) Are you absolutely sure about your software which works on these DBF files primarily?
1b) What antivirus software do you use? (I remember the time when antivirus destroyed ZIP files this way)
1c) What OS do you use? If it is some newer OS then you have to switch oplocks and SMB2 off. Your administrators should know how to do it.
1d) You should be able to watch all write operations to the DBF in some Process monitoring software.

2) Invalid hardware
2a) Did you try the functionality of your software on different hardware? Probably yes, so it should be the first step for the client where this is hapenning.
2b) Mallfunctioning hardware could work this way but it does not seem too probably because NULLs should be on other places in DBF and/or in ither files as well

BTW, "really big dbase III file" can be 256 MB at most by definition. dBase III cannot process bigger files.
Are you really talking about dBase III files?

Sorry for the delay in answering . . . I left town friday evening and just returned home.

I mean inserted.  After the 28th null character the valid header bytes begin.

1a)  Yes, this software is in use at 50+ plants across the nation and has been for over 20 years . . the windows version for about a dozen years.  It's been in use at this particular plan for over 8 years and the issues only started about a month ago.  
1b)  I will have to check with the client.
1c) The server is on sbs2003 I believe.  I will check with their tech guy on the oplocks ans SMB2.
1d) This is multiuser software and we don't know what workstation is causing the problem (or if it is directly related to the server).  Do you know of a process monitoring software that would work in this environment?

2a) yes, as explained in 1.
2b).....

I logged into the client's network to check the file size.  This is odd to me, but may be normal . . .
in explorer the file size is listed as 32,893 kb but when I right click and select properties, it shows

Size:  32.1 MB (33,682,306 bytes)
Size on disk:  32.1 MB (33,685,504 bytes)

I will check on the antifirus and the oplocks and smb2 . . . thank you for your suggestions!

Thank you . . . I will let you know what we find out regarding the SMB2 and oplocks.

Lynn

pcelba,

Can you tell me which workstation OS versions are considered 'newer' and could be at issue?

This plant has alot of 98se workstations in the plant and different versions in the office . . . . so they need to check the 98se workstations also?

98se does not use oplocks and SMB2. Newer operating systems are Windows 7, Windows Server 2008, and maybe Windows Server 2003.

So, it rather looks to antivirus software or hardware. Do you check DBF files for viruses? It could corrupt them.

They probably check everything for viruses . . . . .Should I have them skip all .dbf files and .ndx files?

Yes please, remove DBF, NDX, DBT, and MDX (used by dBase IV). These files cannot contain active viruses. They can be infected, of course, but any infection will destroy them as if they were overwritten...

Does your database have any associated Memo fields? I came across a situation when I tried to save a memo field with data, the actual database was getting corrupted. It was because of of a bad sector in my hard drive. When I copeid the entire software into a new system, it worked perfectly and flawlessly.
This could not be the case in your situation however worth a try. Also ensure that your clients are not running any TSR programs (DOS based) which can corrupt the memory and lead to many such pitfalls.

aikimark:

I just saw your comment . . sorry to not respond earlier . . .

Is it possible that either the drivers, the client application, or the operating system has changed?
***yes, they upgraded server OS but a while before the problems started happening

Is the database repaired very often?  Do you have exclusive access to the DBF file when working on it?
*** no, only when there is a proboem.  No, it is a multiuser program

I wonder if the number of simultaneous users might be passing some threshhold that introduces instability.
*** not sure, but there are alot of users in this database on and off all day.  

========
See if there is anything in any of the Event Logs on the server that reference the directory or DBF file.
*** they ARE getting server errors in the event log at the same approximate time as they notice the corruption, but they do not directly reference the dbf file or directory

What kind of application is this?  What language was used to create it?
data collection that tracks plant operations.  VB6 using dbLib database drivers.

Are any errors trapped by the client?
not until after the corruption.

Has the DBF file been moved to a different hard drive recently?
No

Have any other DBF files experienced similar problems?
this database and then also the index file associated with it has experienced similar issues.

How often do these problems occur?
It hasn't happened in several days, but for about a week it was happening every day or every other day.

It might be worth your time to have a nightly window where you can safely backup the table and index files.  It wouldn't hurt to repair them nightly.  However, it is going to require you to tweak the VB6 application to detect a shutdown request or to implement a (human) procedure to shut down the application at a certain time.

@lthames

Thanks for the points.  Did your research reveal anything specific that would lead to the corruption?

What was your on-going/prophylactic solution?