>I am pre-validating candidate keys in my Save method. In the Save method, I call the row validation function for this table (in the DBC) before the TABLEUPDATE. In the row validation, I do: INDEXSEEK(,.F.,ALIAS(),) to check for existence of the key we have just entered.
>
>If go out to the command window, manually SET MULTILOCKS ON, set BUFFERING to (5), set EXACT ON, then change this table in a BROWSE window - all is OK. When I do the same thing in my application INDEXSEEK apparently tries to move the record pointer (and recursively fires record validation). I've pinned it down to the one line of code (in the Save method) where I call the row validation code for the first time. The validation code runs up to the point of the INDEXSEEK, then as soon as that line executes , the row validation procedure is called again.
>
>I can't find anything different (other than the fact that, in the application, the table is open in a private datasession).
>
>Has anyone seen this behavior? Absent that, does anyone have any suggestions about how I might more closely check my environment to see what could be different?
>
>Any help would be greatly appreciated. I am stumped

Multilocks and buffering is scoped to the session you are in. Check to see if your set command are set properly.