>>>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.
>
>Jim

OH, (insert expletive of your choice). In my form, I had a filter on the customers table. Temporarily removing the same cured the problem. RTFM. I will be wearing my pointy dunce cap the rest of the week, I promise. TGIS! Thanks, all.

Jim