>Thanks for the response Nick.
>
>>Jim, I would suggest you:
>>
>>1. Instead of local variables create and assign form properties.
>>
>>2. If appropriate, create lookup tables for your section, township and range (or if they already exist somewhere just use those fields. IMHO (if possible) it is better to select existing (say, defined in the lookup tables) values from the listbox or combobox rather then input them in textboxes. (But really it depends on your app, also if the range is a date range you may enter it manually, or use any Calendar OCX control)
>
>That does seem like a much better approach. I'll work on that and see what I can do with it.
>
>>3. Instead of SEEK you may use SQL select to cursor, something like
>
>I'm using a SEEK because I just need to get them to the first record in that area. From that point they have to do a visual scan of the data. It's sort of the last resort search option ;)
>
>>You may also use parameterized view where parameters will be your selected (or entered) values from listboxes, comboboxes or textboxes.
>
>Could you explain a little more on parameterized views?
>
>TIA,
>
>Jim

SQL statement of the parameterized view will look like:

SELECT * from myTable ;
WHERE myTable.section = ?variable1 ;
AND myTable.township = ?variable2 ;
INTO cursor _ctmp

It means that when you REQUERY() your view, it will substitute the parameter with current values from those variables. You can make them local, global or use the form properties. You just need to make sure that those variables exist in the method you are calling them from and have necessary current values in them. Say:

variable1 = thisform.listbox1.value
variable2 = thisform.listbox2.value
SELECT myView
=REQUERY()
thisform.myGrid.Refresh()

You may put the code similar to above mentioned into say, myForm.RequeryViews() custom method.
If your parameters used as local variables, usually you set
myView.NoDataOnLoad = .t. in your DataEnvironment and requery your views when necessary.

HTH,

Nick