A problem with a corrupted file usually isn't this "graceful". It's more likely to crash your file than to mysteriously renumber it, though a damaged index isn't something we can rule out at this point.
You'll need to look at the design of your database first. What kind of field is this? Is it an auto-entered serial number field (the simplest, safest option for uniquely numbering records)?
Are these records a simple arbitrary sequence with the oldest records having the smallest values and the most recently created record the largest value or is there some additional "meaning" attached to these numbers. (Such as starting over with 1 on january first, or numbers in a given range represent a given category.)
Best guess is, that if large numbers of records are being mysteriosly renumbered and the field in question is a simple number or text field, either a script that is modifying large numbers of records is be running amok or an import records operation is copying the data into a new copy of the file and the renumbering is happening during the import operation.
Thank you for your response. I just checked the field and found that it is an auto entered number field. There is nothing fancy about the number system - the oldest records have the smallest number, etc. We never import records into the database and there are no scripts that fit your description.
I am seriously stumped with the problem. The database has existed for many years before my time here so I'm not 100% sure that there aren't any unusual scripts but I'm not sure where to begin checking for that sort of problem. Any suggestions would be greatly appreciated.
I suspect that either there is indeed such a script or that there is something to the layout where you see this that is creating the illusion that the Serial numbers are changing.
Open Manage | database | Fields, double click this field, click the validation tab and specify: Unique values, validate always. Also click the auto-enter tab and select "prohibit modification during data entry".
This at least, should prevent the field from being changed by a script or a user. If you start seeing error messages pop up that a field cannot be modified after you do this or a user complains that they can't do what they want to do, you'll get a clue as to what is changing the numbers.
BTW, the most typical case of a script "running amok" is a script that uses Go To Related Record, but doesn't correctly check to see if there are any related records to "go to". In those cases, the script can end up running the rest of its steps on the wrong layout/table with potentially disasterous results.
Thank you for your suggestions. It turned out that the "validate always" option was not selected so hopefully this will help to prevent the problem in the future. I also double checked that the "prohibit modification" option was selected.