>>What happens is, the third table Assnlog doesn't get a record added to it. Well that's how it
>>looks. If I check the record count of 'assnlog' just before the END TRANSACTION in the code
>>below, the count has gone up by 1 and you can browse the table and see the record. Immediately
>>after the END TRANSACTION the record count goes back down by 1 and the record has disappeared.
>
>That means the header has been corrupted. You can cause the header to be re-written by adding a column, saving the change, then deleting it and saving the change.

Garrett,

That seems to be jumping to a conclusion. He checks the record count and it is OK. Surely the system doesn't give him a valid record count from RAM that differs from the one in the actual header content.

More importantly, WHY/HOW does the header become "corrupted"??? That seems to be the real problem at hand.

As importantly, how come a record can be successfully added to a table when it is NOT in a TRANSACTION yet within a TRANSACTION it gets 'lost'??? Surely that difference can be isoltaed by those who have the code.

Also recently reported here was an instance where a record in a TRANSACTION was NOT updated (i.e. a re-write, not a write) despite clean returns and certainty that the code to do so had run.
My guess is that this case too is related to the one at hand and to Q293638 generally.

>
>The problem has been solved in VFP8: if the header is corrupted, you will get an error, instead of silently losing records.

I'd say that silently dropping records has been "solved" but that it is done by a trap and that this is an INTERIM 'solution' at best.