Nadya,

>>I want to test value immediatelly after focus is trying to leave the textbox. Additional check would be performed at the stage of saving. So, here is the simple potential scenario:

>>One userA opens table in buffered mode. He switches to Editmode and go to record 4. He changes FunName to "MyFun1". Then he goes to lunch. After lunch he goes to record 8 and changes funName to "MyFun1" or tries to add a new record with 'myFun1'. Since the changes are not saved on disk yet, your method would allow him to do it. I want to catch this invalid input immediatelly.

>>So, only COUNT FOR should work (or seek and do while (or scan while)). Since these operations move record pointer, I would have an error, which I should trap. That's why it's quite complicated task and I want to discuss it with colleagues first. Though, I know in advance the answer: yes, we understand the problem, but it's a low priority problem, etc., etc. So this would never be implemented anyway and I have to deal with it on the particular form level...


>>Basically, there should be two checks: one in textbox valid (or lostfocus). Another in the save method of the form. If I make this tag to be candidate, the save part would be covered by trapping errors on TableUpdate. I'm thinking, that the best way to check uniqueness on the buffered table is to use COUNT FOR upper(FunName)==upper(m.lcFunName) to lnCheck

>>If lnCheck>1 && This is a duplicate

>>AFAIK, COUNT FOR works for buffered table. I think, it would be slow, though.

>>I should also set deleted off before count and back to original settings after count.


Maybe I'm missing something, but:

* METHOD: TextBox.Valid/LostFocus
LOCAL lRetVal

m.lRetVal = NOT INDEXSEEK(THIS.VALUE, .F., "AllFunctions", "FUN_KEY")
IF m.lRetVal
	INSERT INTO AllFunctions ([field list]) VALUES ([value list])
ELSE
	[error handling for duplicate key]
ENDIF

RETURN(m.lRetVal)

Since this implementation of INDEXSEEK doesn't move the record pointer, you will not get the VFP primary key error, and its fast,fast,fast.

As a further step, you might consider writing a primary key validation class as part of a business tier. Keep the business code out of the interface layer and all that.

Regards,
Thom C.