>>What if matter of change is replacing not adding new records? This way header should not be locked. In another scenario, IMO if buffering case includes adding new recors, then headers will be locked anyway. VFP suppose to lock headers (for short time) when it creates new record through buffer or with no buffer. As long as transaction is dynamic, locking will be handled by SET REPROCESS.
>
>Ed,
>
>Updating an existing record does not lock the dbf header at all, therefore the only thing locked is the exact record being updated and the multi-user conflict is limited to that record.
>
>The issue with using a transaction with unbuffered tables has to do with how long the locks are held not whether they are held or not. First transactions are not needed when one table is being updated, buffering and the proper use of tableupdate will insure that situation is completed properly.
>
>With a transaction the locks are held on all tables involved for the complete duration of the transaction. If the tables are buffered all of the calculations and field data changes have been accomplished (using direct replace statments if desired)outside of the transaction and the only thing that is in the transaction is the TaleUpdate calls making for a very short duration (since all activity is inside VFP and not interpreted lines of code doing replaces or gather statements). With unbuffered tables one either has to calculate a whole bunch of memvars to hold the data values before the transaction or else there are calculations going on inside the transaction which extends the duration of the transaction and thusly the locked record time.
>
>Keep in mind that none of this is talking about while the form is running, it is only the duration of the actual transaction. Buffered tables are not locked when you append a blank record outside of a transaction. The TableUpdate will hold a short lock adn a trnasaction will hold a lock until the transaction is committed or rooled back.

I completely agree with your points here. Just one addition (logical one I hope)- if all changes are held by some object, i.e. all calculations are done already before transaction called, then time for real update (i.e. moving data from object, and/or from cursor assigned to this object) is essentially the same as in case of standard buffer.
Another possible scenario: there is just one CURSORSETPROP() call between buffered and non-buffered table. If this call made on Save point, then all changes pumped into the buffer, then transaction called with TableUpdate() inside, then the whole thing looks completely identical.