100% agree.

Anyway, not the implicit transaction is the main problem, at least from my point of view, but the fact CA doesn't behave like RV - if the transactions are set to 1, it issues a commit tran by it's own at the first update in a multi-table update. RV don't do that and if one tries to use the RV's code with the CA (very little difference - instead requery() it's CursorFill() or CursorRefresh()), well, the code bombs out. on a 3 forms app, that wouldn't be a problem - but when someone looses the compatibility on an app distributed in 270 points all over the country, then the problem has a completely different perspective.

Anyway, I wonder what was in the programmer's mind: "so: the ca sends an update. Wouldn't be nice if I'd count the transactions, and if I find some open, to close them?" well, it isn't. Or, at least, give us a way to make CA stop that. No such way there, and my hands are tied.

And yes, I downloaded all the examples I found in UT, I had a close look at example in the samples. Not a single word about transaction management. It's easy to say "study the examples before making a judgment". Yeah, right. Examples? heh? where?

>... and wouldn't it be nice if you could find the answers to this and many other similar questions within the VFP docuemntation?!?!