Yes, I believe it is possible ***IF*** you are using TRANSACTIONs.

In VFP6 (I'm pretty sure) and VFP7 (for sure) VFP would merrily continue processing, acting like it had written the data to the table(s) when in fact nothing actually got written!!!!!!!

VFP8 introduced an error code - 2065 - to TRAP the condition and report it.
The trap at least prevents loss of data (as long as people heed it, I suppose).

VFP8 also introduced SET TABLEVALIDATE to trap similar errors not involving TRANSACTIONs. Not sure that were was much in the way of documented errors of this type, but nonetheless an excellent addition to VFP. We need our data integrity protected by any reasonable means possible.

There was a thread regarding this type of data loss in TRANSACTIONS some time ago, and one technique that was said to highly improve the situation was to add 2 dummy (i.e. never used) fields at the very start of every table involved in TRANSACTIONs, one of C(10) and one of I. That same thread also said that the safest way, at least at that time (pre-VFP8 I believe) was to re-read the record immediately after writing it.

Others also seem to relate Windows' implementation of "opportunistic locking" as being implicated, apparently especially if non-Windows file servers are involved. I've seen several people say that they DISable that feature of Windows, using some MSKB article to carry that out.

Finally, one person's experience that I read of here may be enlightening. He was getting consistent errors (2091 I *think*) daily shortly after implementing VFP8 in some rather simple-looking code. He finally got tired of them and took the drastic step of moving the data to another hard drive. The errors went away, leading the the conclusion that possibly his HD had some intermittent flaky/error tracks.

good luck


>We have a parent/child database system.
>
>Parent is Companies
>Child is People
>The link is the ID which is manually entered for the company then automatically generated for the people.
>
>Is there any known way for people to be missing from the people table, if the data was saved?
>
>I have looked at the table seperately...the names are gone.
>I have looked at the deleted records.
>The table was NOT packed.
>
>We did reindex with INDEX ON all the indexes.
>We did not kill and recreate the tags.
>We did look for the data without any indexes however.
>
>Is this possible?
>Would putting the data into MS SQL make it more secure from the above?
>
>Glenn