It's a bit difficult to prevent something when you don't know how it happened in the first place.
Ways that a record can "go missing".
- It's really there, but due to a damaged index it's not coming up in a search or sort as expected.
- It's still there but has been modified beyond all recognition by a user or a script.
- It was deleted by a user or a script. (Don't forget that users who don't have access privileges that allow deleting records can run a script set to "run with full access privileges" and the script can delete the record.)
- It was deleted when a related record was deleted. This is controlled by an option you select in Manage | Database | Relationships by double clicking a relationship line and then selecting the "Delete..." option for a table.
Thanks. I went into a layout based on this table and the record is gone. Only thing I can think of is that 2 users were in different parts of the system trying to access this record in some form (drop down list, portal, etc). when the record vanished. Users don't have privileges to delete anything and I don't have any scripts that would delete a record. I also don't have any relationships that would delete the record. I'm puzzled.
If two users try to modify the same record, the first user will be allowed to "open" the record for editing, but the second user will be "locked out" and will get an error message telling them that they can't modify the record until the first record releases (commits) the record.
What might happen is that either user or a script might modify fields in the record--producing a very different record than what you are looking for. Since I know nothing about the design of your database, I can't tell if this is a likely or unlikely scenario.
I went into a layout based on this table and the record is gone.
How did that tell you that the record is gone? Appearances are sometimes deceiving. It might not be in the current found set. It might be present but located in a different part of the found set than you expected--especially if an index is corrupted--affecting a find or sort's expected result.
And if you use a record identifier (Primary key) that is neither an auto-entered serial number nor Get ( UUID ), then that may be a key clue in how this record went missing on you.
I am not looking for the record in find mode. I'm in the actual layout based on that table, and there are 28 records. I went through each one and the record is missing. I also track changes in each record so I can detect if someone tampered with it and disguised it.
I use auto entered serial numbers for each record.
You might want to run a recover on this file just to rule out possible file damage.
Take a copy of this file and try this experiment:
Create a new record, but before you do something to commit the record, then select "revert record" from the Records menu. Then create another new record. What number do you now see in the auto-entered serial number field? Did this produce a "gap" in your series of serial numbered records?
Yes this causes a gap. I recovered the file but the record is still missing.
Then is it possible that there is no missing record but that a user generated a gap in the sequence--resulting in what looks like a missing record but isn't?
I did not expect recover to bring back a missing record. But rather it was a check to make sure that the recover did not report finding and fixing a problem. If the file is damaged, that damage could have resulted in a lost record.
No. The record is of a specific employee. The employee is missing and all related records show his name missing. I just did an export and imported the record back in. But now I broke all references to external container storage on my FMS12.
I just did an export and imported the record back in.
Why did you need to "export"?
You can import data directly from tables in the back up file into your current file. That cuts the number of steps and the time involved in half.
But now I broke all references to external container storage on my FMS12.
That's very strange to me. Simply importing the missing record back into the table where it was missing should not have any effect on how your containers function.
I have no other suggestions to make as to how the record went missing. My best guess remains that either you or another user managed to either delete the record or overwrite it with different data. Short of inventing a time machine, you may never be able to figure this out unless it happens again and you spot a pattern that helps you sleuth out the reason.
I exported bc I didn't know any better and needed to get the system functioning properly since it was during business hours I was trying to restore the record. The record was needed to be accessed by staff. I acted fast and unfortunately it was an inefficient method.
As for breaking my file references...they didn't break. Rather, when I took the file offline to run a recovery on it, it deleted all the container data bc I uploaded the recovered file and deleted the original. Fortunately, I was able to move my backup data to the correct directory and all is well again.
Learning from my mistakes I guess.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421).