that can be a corrupt database. But before running recover, there could be a few more tests that can be done.
For example have a Layout in table view for that table. Then sort by Last name for example (no filter). Scroll to the person name that is giving an issue and see if there are two records on only one.
Out of curiosity, how come there are only 515 records in that database, and it is weighting 3.86 GT ?
This sounds like an indexing issue.
I would try:
Remove file from server.
Run Recover, but ONLY the rebuild indexes option.
Test file for duplicate.
Return to server if fixed.
(The rebuild index option in recover is non-destructive and the file is safe to continue using.)
My first attempt at fixing this would be to rebuild the file's indexes.
To rebuild one index:
Go into Manage database, turn indexing on the field off, exit Manage Database by clicking OK, then return and turn it back on.
To rebuild all the indexes in one go:
Take the file down off the server. Use recover it to recover it, BUT, only with these advanced recover options selected:
Copy File Blocks As Is. Rebuild Indexes Now.
Take a clone of your file and import all records into the clone.
I'm not sure why the file is so big since all the Containers are stored externally.
Which field should I turn indexing off on - or should I turn it off on all fields that have it on in Manage Database?
Is there an option to choose advanced options when choosing recover?
Wouldn't importing into a clone import the extra record?