records disappear [solved]

[Otto]

Jeff,
overwrite I can imagine also delete in conjunction with pack but
> Every now and then (very rare indeed) I will notice that a record has gone missing.
without a reason and not seeing a corruption inside the database I can’t.

But we must take this issue very serious because if there is really a problem with the database engine it can happen to every one of us.
Do you have more information.
I tried to delete exactly one record inside a dbf file with Multiedit.
But then if you try to open with a dbase editor you get a corruption detected error.

Best regards,
Otto


http://www.digitalpreservation.gov/form ... 0325.shtml
http://www.dbase.com/Knowledgebase/INT/db7_file_fmt.htm

[Jeff Barnes]

Hi Otto,

I have no good explanation as to what is causing this. All I know is that there are three of us that use my program in my office.
Only I have access to delete records.

Each new record is assigned a service report number (ie: 12001, 12002, 12003 etc...)
This number is locked from editing.

A while back I had to look up an old report (let's say it was 12120) ... I did the usual search via the program ... not found.
I did a reindex, searched again, not found.
I opened up the dbf file in an editor and manually looked through the entire database. Since the records are stored and created in order i would have expected to find the record right after 12119 but no. The records we as follows:
...
12117
12118
12119
12121
12122
etc....

Nowhere was there an entry for 12120 but I have a printed report for this item so I know it did indeed exist.
There was not even a blank entry where 12120 should have been. No deleted item ... just gone.

In the many years that we have used the program I think this has only happened two or three times.

[Enrico Maria Giordano]

It looks like a bug in your code-generating function.

EMG

[Otto]

Jeff,
I belive that you have a printed copy.
How do you print the records. Do you read from disk. I think you missed to commit and then the data is somewhere in the cache.
Maybe then there was a program error and the data was not written to the disk.
Is your data on a network dirive.
Best regards,
Otto

[Jeff Barnes]

Yes the records are read from the hard drive and yes on a network.
-Record is created when equipment comes in
-Any work done on equipment is entered into the record.
-The equipment is left running for 24 hours to verify the problem has been solved
-The record is re-opened, any additional comments added, and the final report is printed.

If it were a cache issue, the original record should still be in the system but without the added data.

[James Bott]

Jeff,

Well, I agree with Enrico, without a PACK an existing record cannot be removed from a DBF file.

The only explanation for your example that I can think of, is that you printed the report, then a new record was created and it was saved over the existing record for the previous ID. I have had this happen in the past when I was using an index on the ID and the index was corrupted. To prevent this, I started turning off the index then using GO BOTTOM instead of using the index. GO BOTTOM has never failed me.

Regards,
James

[Otto]

Hello James,
Would you be so kind to explain how index or go bottom has an effect if I add a record with append blank.
Best regards,
Otto

[Jeff Barnes]

I guess anything is possible. we don't use the software anymore for new reports ... only used now to pull up old ones.

[James Bott]

Otto,

>Would you be so kind to explain how index or go bottom has an effect if I add a record with append blank.

Now I remember exactly what was happening. I was using an ID index to find the last used ID by issuing a GO BOTTOM (while the index on ID was the current index). Normally this worked fine, but when the index was corrupted I did get multiple copies of the same ID (because it wasn't seeing newly added records). This is not exactly what Jeff is seeing.

However, you cannot remove records from the middle of a DBF without doing a PACK or COPY TO, so one explanation for his example is that a new record was written over the top of the last record in the file. If the ID index was corrupted the new record may have been written over any other existing record in the file.

Or, possibly the missing record was printed on a report but never actually saved to the DBF.

Regards,
James

[Otto]

Hello James,
do you know is the dbf database engine checks if the number of records corresponds to the value stored in the header.
Otherwise what happens if a antivirus software tries to repair a file and deletes some records inside a dbf file.
Best regards
Otto
4-7 32-bit number Number of records in the table. (Least significant byte first.)

[Enrico Maria Giordano]

No. Even at very low level a sequential file (a DBF is a sequential file) can only be truncated (ie. deleted from a point to the end). To delete an inner part of it the only way is to copy it to another file.

EMG

[TimStone]

I'm glad this thread was started.

I don't believe in ghosts, or gremlins, but they still seem to exist in our computers.

I know what should not be able to happen, but I do know what does happen:
1) A "workorder" is created. It has totals, client link numbers, etc. When it is created it is Saved ! Then, when data is added ( connected ), it is also saved. The main workorder is stored in ord.dbf !
2) When parts are added to a workorder ( and labor ), they are linked with the workorder number. These records are all saved in their own files.
3) Example: Workorder 100005 is created. The number is drawn from a separate counter file. It exists in the ord.dbf file. When other items are added they also have the 100005 stored in the first field of their records.
4) A printout is made of 100005. It shows all detail and all connected parts. It is clearly in the system.
5) All entries are physically in numerical sequence. The saves are done when the record is first created, and when it is updated.
6) Several weeks later, a reprint is needed. The record is gone in the ord.dbf file ( but all the associated records still exist in their files ). If I manually add a new record for 100005 to the ord.dbf file, I can then print a full document and all of the related records in other files will show up as they should.

In each case I have investigated, the record is simply missing from the ord.dbf file. I've done numerous searches through the file to see if the data has been written over another record, but that is not the case.

It doesn't happen very often, but it does actually occur.

Perhaps there are ghosts and goblins out there, living our computer data.

Tim

[lucasdebeltran]

Timm,

Which antivirus do you use in that PC?.

Thanks

[Enrico Maria Giordano]

I know what should not be able to happen, but I do know what does happen

No, you only see the final effect that can have many different reasons to happen. Simply, the real reason is not the one you imagine.

EMG

[Antonio Linares]

If indexes are fine, then the technical reason that comes to my mind is that the writting of a record may fail randomly (and this could happen from the DBF engine itself, its a possibility).

If this is the case, maybe you could use a (sort of) backup DBF where you also register your latest activity of the initial DBF.

If a record dissapears on the DBF, its initial existence should be in the backup DBF and that could provide more info for a pattern, or a way to reproduce it.