>>>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...
>
>Thanks, Ed. I did try an ALLTRIM() on the input to no avail. I don't know about the Insert mode, I will check that. I did go to the command window and played with the CustID like "JSMITH", "JSMITH ", etc. and finally got it to fail when the lenght of spaces went beyond the field length. So then I tried the trimming. Input Mask is XXXXXXXXXXXXXXX and Format is !. customerid is a C(15) field. This textbox is in a modal form, using the default datasession established by the calling form. Examining the environment in the debugger shows me everything should be proper for this to work as it does from the command window. This is my first use of INDEXSEEK() and I can't believe I am having this trouble. I am stumped.
>

I don't know, I'd set a MaxLength that matched the field's length, and there's no need for an Inputmask and Format, since "!!!!!!!!!!!!!!!" is perfectly permissable and does the job. If it's unbound, I'd initialize it to =SPACE(15). It works fine for me. If the entered value is in the table, INDEXSEEK() returns .T., and if not, .F. - I did make sure to SET EXACT ON for the data session, since SET EXACT is scoped to the datasession.

If this is being used for an identity, then (IMO) it shouldn't be permitted as an editable item for an existing record; it'd be found if it didn't change or if it matched some other record's value for the field. Reality, I think you need to rework the logic for this fundamentally, since it's clearly not going to do what you want in an edit mode IAC; INDEXSEEK() finds the original value jsut like it finds the valuye of another key, and it doesn't tell you if the record pointer had to change to get there.