>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.

To get this kind of redundancy would you not need a 3rd table that had a field for the primary key in table 1 and what primary key in table 2 is table 1's child? You would need a record for each child in table 2. This or something similar would have to exist to recover from corruption of the foreign key field in table 2 or the primary key field in table 1 became corrupted.

This still fails if both the primary and foreign key fields in table 2 become corrupt.

I don't do this. I depend on backup data. Stonefield definitely will not fix this. The meta data is used to recreate table structures, DB properties, indexes, etc. SDt also can fixe table headers, etc.