>Hi!
>
>This problem was discussed before a lot, and I experiensed it too. The solution is to add FLUSH command just after END TRANSACTION. Accordingly to the Hacker's Guide, table header is not updated for table into which new records are inserted when optimistic buffering used and transaction. FLUSH do update headers and prevents such problem (except for case when computer/network crashes at moment between END TRANSACTIOn and FLUSH commands, that is quite rare).
>
>To fix the table after such problem, open VFP development environment, set up in options to do not use any buffering, open that table in exclusive mode, browse it, use 'Ctrl+N' to add new record in browse window, than delete that record. This should fix the corrupted header. You will not see one (or more - do not know exactly) newly added records and will lose them, however.

Another trick to the similar effect was to issue
=reccount()
immediately after writing the record (transactions or not). This call goes for the table header, and somehow makes sure it's right. I don't remember the theory behind that, but some frameworks use this trick.