buffering & transactions

Microsoft Visual FoxPro - Programmer Exchange

It is not necessary to buffer a table for transactions to work. 
Nevertheless, I usually buffer a table (or use a view), then if a 
transaction is necessary, put the transaction only around the TABLEUPDATE in 
order to keep the transaction short.

But I'm really guessing here. Am I approaching it in the best manner? What 
general rules are there for handling buffering and transactions?

Also, I occasionally want a transaction to cover changes to several tables, 
with some calculation done during the process, and even a couple nested 
transactions. The whole thing could take a few seconds (in a multi-user 
environment). Is there anything specific I need to look out for? Other than 
the limit on transaction levels, I mean.
Hi Paul,
The article below might give you some hints. 
Thanks, but there's not much there that's new to me, or particularly 
helpful. I'm looking for practical guidelines on how long and involved 
transactions can be, their effects on other users, what can go wrong and 
why, that sort of thing.

Also, it says "Transaction processing should never be used without 
buffering," without saying why. I hate it when they do that. Transactions 
appear to work fine without buffering, so...?
The admonishment about buffering for transactions is because with dirty
reads on unbuffered data, changes are committed as soon as they're made.
Unless you want to hold a transaction open for an entire editing session,
and I KNOW you know better.

In other words, they just didn't say it very well. <g>

I wrap transactions around tablupdate(). The main benefit, of course, is
that ROLLBACK restores you to buffered/changed data so you can investigate
which change caused the tableupdate() to fail. There are cases where another
user's changes will make tableupdate() fail but it really doesn't matter to
your current transaction, so you can write code to make tableupdate()
succeed on a second attempt.


I open a transaction only when saving. But in this unusual case, "Save" is 
an extended process involving calculations and several updates to various 
tables. (Just what transactions were made for, I think.) Some of those 
updates are simple inserts (sql), so offhand I don't see a need to buffer 
those. I have them in TRY blocks and can rollback if necessary.
Paul Pedersen schrieb:

In vfp6 we ran into trouble using transactions on a save process that 
was coded to include (yes, I know ... not my design<g>) BizObject checks 
on the data to be saved and some optional protocols and/or audit trails.

Dunno if there still is a problem, but if you get chr(0) in your saved 
tables, this can be one reason. But there are some other (even 
documented at MS) ways to get invalid data.

my 0.02 EUR

If it works for you, rock on. <s>

Well, I HOPE it works (I'm sure I'll find out eventually, but I'd rather 
know sooner than later), which brings me back to the original question! To 
wit, is there something wrong with my logic, and what problems might I run 

But you and Ook have made a couple suggestions and observations, for which I 
am grateful.