I'm doing the same thing, porting an incremental search routine from FPD26 to VFP, and the logic seems to be more or less the same, so just a few remarks: > CASE skey >= 48 AND skey <= 58 OR; > skey >= 65 AND skey <= 90 OR; > skey >= 97 AND skey <= 122 OR; > skey = 32 OR skey = 44 OR skey = 46 && 0-9, A-Z, a-z, or > Spacebar This is where you went wrong. Just an "Case sKey>32" would be quite enough (considering you've handled any F1-F12 and other keys before), because this way you lose... me :), since for me the alphabet has five extra letters, and if I included my 100-mile neighbourhood, add some ten extra more. You forgot ¹ðèæ¾ and the rest of above-128 stuff. Besides, such things made me uninstall some evaluation packages without a second thought - couldn't write my name properly in them (can't do it here, anyway, but might give it a shot: do you see a c acute here: æ?). Not considering localization in these days might mean some damage to the sales. > SKValue = SKValue+CHR(skey) In the seek part, consider skv1=skvalue+chr(skey) skv2=skvalue+upper(chr(skey)) skv3=skvalue+lower(chr(skey)) if seek(skv1) skvalue=skv1 else if seek(skv2) skvalue=skv2 else if seek(skv3) skvalue=skv3 endif endif endif This way you find both upper and lowercase. This also doesn't work if there's one uppercase you find before another lowercase and vice versa. Say you seek "charlie", and you have "Charles" and "charlie" in the table. If your user typed capital C, finds Charles and can't find charlie. My solution to it is using national collating sequences for name/description field indexes, they are case blind, though in some cases they may misbehave if they expect a ligature. For example, in hungarian sequence, when the last char was a "g" ot "t", sometimes it didn't position well, because the table contained entries with ligatures "gy" or "ty" (consonants of their own in the language), and only after an additional keypress it resolved to position properly.