>>Hi Jim,
>>>I am trying to validate to textbox with the following code:
>>

>>>set step on    && to see what is happening
>>>badid = .T.     && to get a reference point
>>>badid = INDEXSEEK(THIS.VALUE,.F.,"customers","customerid")  && goes to .F. here!
>>>IF badid
>>>           MESSAGEBOX("etc")
>>>           RETURN .F.
>>>ELSE
>>>           RETURN .T.
>>>ENDIF
>>>
>>>ALIAS() shows the proper table
>>>SYS(22) shows the proper controlling index
>>>THIS.VALUE  = what I entered
>>

>>>Yet it still fails to detect an existing value in the index. If I drop out to the command widow, do the same
>>>with a known key value vs. THIS.VALUE, it works fine. What else can I look at?
>>
>>First, the way I read it badid will be .F. for a Good Id and .T. for a Bad Id. But, otherwise... Does the datatype of This.Value match the datatype of the customerid index? If it is character vs numeric it will always fail, for example. If both are character, is the case the same? That's where I'd start.
>>HTH,
>
>Hi Bill,
>
>No, the logic is OK, in my case I want to catch a duplicate before it happens. If the INDEXSEEK finds the key, I want to stop at that point and have the user try another 'customerid'. These ID's are character fields, forced to upper case on entry into the text box. Generally in the form of first initial+lastname as a rule. However, with all the possible JSMITH's you do have to be a bit creative at times. If I take the case of badid = INDEXSEEK("JSMITH",.F.,"customers","customerid") into the command window, it works. In the Valid Event of my textbox, it doesn't. The only time the user is in this textbox is in an ADD or EDIT of the record in question. Any other ideas?
>

This is a SWAG, but I suspect that the LENGTH of this.value doesn't match up with the field length, requiring a PADR() or TRIM() operation; very likely if the field is not bound, and the keyboard is in insert mode - the blanks in the field get pushed out to the right, and if you don't have an explicit InputMask limiting the length...