>I don't know why anyone would EVER want to use Row buffering. I really can't think of a single situation. The reason is exactly as you have mentioned: It takes the process of TABLEUPDATE() out of your hands. There are several operations BROWSE, USE IN, etc, that cause the data to be written automatically. When is this EVER a good thing?

Well, back when I wrote my first VFP app, not having dealt with a multi-user environment previously, I was very leery of optimistic table buffering. I came to the conclusion that it would be too hard for me to get the app out on time if I had to figure out all the error-checking I'd need to handle that kind of processing, so I opted for pessimistic row-buffering (don't lynch me, please < g>). Of course, now I know better, but at the time it seemed an easy way to handle stuff I didn't fully understand. But, it has gotten me wondering about the validity of doing it the way I did it. I mean, the app works and it works fine, but there are not a lot of users so perhaps the inherent weaknesses in it's design will not be a problem.

>This is a really bad idea. A BEGIN TRANSACTION locks all underlying records for the duration of the transaction. So holding a transaction open during a user wait state will cause nightmarish contention problems.

Not a problem if there are not many simultaneous users, and besides, the decision had already been made to use pessimistic buffering anyway.

>Besides, that's not what they are for.

OK, I'm not saying that this was the best way to do this. At the time, for me, it was cuz I didn't know any better and it was easier and it does work, albeit inefficiently. That's why I'm attempting to get a discussion going about the Pros and Cons of various methods of handling table updates. Not surprisingly, I guess this method gets a big "Thumbs Down", huh? < g>

-Bonnie