>>>I have a network foxpro 6 application that has three input fields
>>>and two page frames. When the last input field is entered, the lost
>>>focus event does:
>>>
>>>set filter to
>>>set filter to vehicle_nu=thisform.mycombobox1.value and ;
>>> substr(dtoc(entry_date),7,4) = thisform.mytextbox1.value and ;
>>> substr(dtoc(entry_date),1,2) = thisform.mytextbox2.value
>>>
>>>The first pageframe has a grid on it that is populated with the filtered
>>>records.
>>>
>>>The user can then depress the add button, and pageframe two displays
>>>for the user to enter a new record. When the user depresses the
>>>save button the last part of the click event is:
>>>
>>>set filter to
>>>set filter to vehicle_nu=thisform.mycombobox1.value and ;
>>> substr(dtoc(entry_date),7,4) = thisform.mytextbox1.value and ;
>>> substr(dtoc(entry_date),1,2) = thisform.mytextbox2.value
>>> go top
>>> thisform.mypageframe1.page1.grid1.setfocus
>>> thisform.refresh
>>>
>>>If someone else on the network is entering a record at the same time,
>>>that record also appears in the pageframe one grid, although it does
>>>not meet the filtered criteria (vehicle_nu).
>>>
>>>Any Ideas................
>>>
>>>dan
>>
>>I'm sorry to say this, but this whole thing is highly suspicious to be used for grid. Generally, grids don't like filters. Usually, it's painfully slow. Other problems can possibly be fixed, e.g. by resetting grid.recordsource, though again it's much better to view or cursor in this case.
>
>I would tend to agree about using filters on a table. Filters are slow whenever and where-ever used in FoxPro. Use a SQL select as the grid source, then requery after adding a record.

Not true! A filter is not slow if it matches an existing index tag key, making it Rushmore optimizable. However, a filter that doesn't match a key is terribly slow.