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

We have a data collection system with really big dbase III files.  Something at one of our clients has started trashing the database at least once each day.  

The trashed files have 28 NULL characters inserted in the beginning of the file.

I don't even know where to look for the culprit . . . .

Does anyone have any thoughts or ideas?

Thanks in advance for any suggestions.

lthamesAsked:
Who is Participating?
 
aikimarkCommented:
Is it possible that either the drivers, the client application, or the operating system has changed?

For instance, if the users had switched from dBaseIII to dBaseIV drivers, you might experience strange database behaviors.

Is the database repaired very often?  Do you have exclusive access to the DBF file when working on it?

I wonder if the number of simultaneous users might be passing some threshhold that introduces instability.

========
See if there is anything in any of the Event Logs on the server that reference the directory or DBF file.

What kind of application is this?  What language was used to create it?

Are any errors trapped by the client?

Has the DBF file been moved to a different hard drive recently?
Have any other DBF files experienced similar problems?
How often do these problems occur?
0
 
pcelbaCommented:
"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?
0
 
lthamesAuthor Commented:
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!

0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
pcelbaCommented:
Inserted characters are not obvious - it should move all 32 MB file contents and extend the file size by 28 bytes which I don't believe. I would guess some block of bytes from the DBF file beginning is shifted upward to the file end, so some DBF record should be corrupted together with the header.

Different sizes reported by OS utilities are OK - MB - kB recalculation obviously depends on different formulas - 1 KB is 1000 B or 1024 bytes etc...

I'll wait for SMB2 and oplocks result (it has to be switched off on both server and workstations) then we may go further.

The monitoring software which will watch certain part of the file isn't so common. Maybe you will need to write some short program which will help to reproduce the error then you may start looking for monitoring sw.
0
 
lthamesAuthor Commented:
Thank you . . . I will let you know what we find out regarding the SMB2 and oplocks.

Lynn
0
 
lthamesAuthor Commented:
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?
0
 
pcelbaCommented:
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.
0
 
lthamesAuthor Commented:
They probably check everything for viruses . . . . .Should I have them skip all .dbf files and .ndx files?
0
 
pcelbaCommented:
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...
0
 
shuvro_basuCommented:
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.
0
 
lthamesAuthor Commented:
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.
0
 
aikimarkCommented:
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.
0
 
aikimarkCommented:
@lthames

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

What was your on-going/prophylactic solution?
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.