>When you really think about it, SET MULTILOCKS is kinda BS as you would think that it'd be much simpler for VFP to not expose multi-locks and just assume ON when buffering was in use. I, for one, have never really concerned myself with how I wanted to set it...just thought "Hmmm...I'm buffering...better set it ON".....

Even beyond what you say here, I've always thought it was silly that there was a setting you had to set to allow multiple records to be locked, ever. Back in 2.6 I sort of rolled my own transaction wrappers a few times. Where a user wanted to make a cascading change, I'd lock the parent and all children first. If I got all the locks, I'd commit the changes, otherwise no. Knowing I may want to do this at any time, and seeing no reason to ever have MULTILOCKS off, SET MULTILOCKS ON has been part of my standard startup prg for a long time.

Hey, Fox development team, why is there such a thing as MULTILOCKS=OFF?

Actually, I can guess. Since the possibility of MULTILOCKS ON didn't come along until what, 2.0? 1.02? There *may* have been some programmers who wrote code which relied on locking a different record to release the current lock, and when MULTILOCKS came along, they'd be leaving records locked which they expected to be unlocked. If I were the Fox developers, though, I'd have just smacked those programmers and said "what were you thinking?" But when you're in the business of selling software development tools, you have to make sure your new features break as little legacy code as possible ... of course this is all guesswork, and even worse, guesswork about how a group of programmers may have been trying to second-guess their users! (We Fox programmers are the Fox development teams users, after all.)

Boy, it must be late. I'm rambling even more than usual. G'night.