Years ago I worked on a big database program handcrafted in Microsoft BASIC for DOS using old-fashioned linked lists and record pointers, just like what I learned about in college in the early '80s. It had two main tables which were related parent-child in this way. Many of the child records were related to each other in various ways using chains of record pointers. For every record pointer that pointed from one record to another, there was a back pointer that pointed from the other record to the one, so there was redundancy.

This database was sold to about 2000 clients. The biggest users would put a few hundred MB of data in it. They would have a dozen or more data entry people using it all day. It would have been a healthy sized VFP project.

Sometimes a customer's data would get corrupted for the usual reasons - network crashes or maybe a bogus data conversion. They might have neglected to make regular backups or they might have been such heavy users that the loss of one day's data would be harmful. That was particularly likely because this data was entered by a customer while talking on the phone to a client without a hard copy being made during the phone conversation. When data was damaged, customers would send it to us for repair. If the corruption wasn't too extensive, and limited to the record pointers, we could fix it by looking for patterns in the errors and using the redundancy in the record pointers.

Does one ever implement this kind of redundancy in VFP related tables? Is it ever a problem that our surrogate keys get messed up without whole records being destroyed or tables becoming unreadable? It doesn't look like the kind of problem that toolkits such as Stonefield were designed to solve, but I don't know much about them.