I am encountering a serious problem with transactions, inserts, and updates. I have views that are optimistically table buffered. Changes to the views are committed with TABLEUPDATE, wrapped inside Transactions.

Most of the time, everything works perfectly. However, on occasion a disastrous thing happens. A new record is added to the view, and TABLEUPDATE() is issued. TABLEUPDATE() returns .T. However, the new record does NOT get written to the table. Worse, still, the key value of the added record gets written to the index. Then child records are allowed to be added (using RI builder's code for RI) to child tables of the base table from the view even though the key value in the parent DOES NOT EXIST IN THE TABLE.

After some looking around (and help from the UT) I determined that the problem was that the DBF's header was not getting updated properly. It would show one less than the actual numbers of records in the table. This would cause all new records to be written over the last record in the table, instead of at the end of the table. But since VFP seemed to think everything was OK, the index was updated.

I have determined a way to trap for the error, and a way to fix the tables after the fact. But if I have a situation where I have RI that is set up programmatically external to the DBC I can still end up with orphaned records.

I am horrified that a problem like this, which seems to have been around for a while, has not been addressed by MS anywhere. Then again, maybe I shouldn't be surprised. I know I'm not the first one to discover this. But I can't even find an article about it on the Knowledge Base. Does anyone know of a way to fix the problem in real-time? Do I have to stop using Transactions? Is anyone aware if MS even really knows about the problem?

Problems like this, in my mind, really compromise the MS pitches for VFP as middle-ware DB repository. Talk about unstable.

I'm done venting. Any help I could get here would be greatly appreciated.