I have done much the same as you. I have an incremental search textbox that autofills with the first matching record as the user types. I have often included a grid that also moves to the matching record as the user types in their search string. This technique works great with native VFP data.

This technique can be ineffective where the database is in Oracle or SQL Server. What I do in those cases, is provide a search form where the user will type in strings for different key fields [e.g., last name, company, city, postal code, etc]. When the user clicks the GO button, I build the SQL from their entries and use SPT to return a manageable results set that the user can then select the record they want to edit.

>I have yet to see a Sample VFP application that ships with VFP, that shows forms with proper search functionality. (I have not seen VFP 6.0 samples yet). Usually they are hopelessly inadequate forms, with just a grid as the search option. This may be ok for a table of 100 or so records, but it is useless for a table of say 4000 records.
>
>Ever since I learnt the basics of VFP about three years ago, I have always created most of my forms in the following way: (I am a non- professional VFP, and have learnt my own technique in total isolation from other VFP programmers, cause there are none where I’m from).
>
>I have a form with a pageframe and several pages. The first page always consists of a grid covering most of the page, and a search textbox above it. The search box always starts off with the focus set to it (and is then green). The user can then type in the first few key words of any one of several fields. For example, on a products form, the user could type in the product code, or the product description. The table will then be ordered by code, and if not found, ordered by description (seek &mysearch). The grid will then pull up the data and scroll the first result found to the top of the grid (code that Centin Basoz once showed me).
>
>The focus is then set back to the search text box, which is again green, blank, and ready to except the next search string. The found/current record is also displayed in two or three textboxes just above the pageframe. Eg: Code: 092700 Description: Flight Unlimited 3 Game CD
>The user can also click on any record in the grid, and move around on the grid, and the current record will always be reflected in the text boxes above.
>
>Once the user has found/selected the correct record, he/(she) can click on any of the other pages of the pageframe, and all of them will contain data etc. relevant to the current record.
>
>When the user needs to find another record, all he needs to do is go to page one and type in a new search string. (I do also have the search textbox on some of the other pages, along with next/previous buttons)
>
>I have used this method for tables with customer account info, product info, quotations, etc. Tables with usually several thousand records.
>
>I have seen with a few professional programs, that there are lots of little search icons all over the place. This seems to be the norm. To me it seems a long way around to have to click on these and keep opening up other search windows.
>
>Am I the odd one out? Does my way of creating the form have any merit /draw backs?
>Has anyone else created forms in a similar way?
>Is there a better way?
>
>Your opinions would be appreciated.
>
>Regards David