>>>>>Parameterized, ordered views are the best way to go in situations like this.
>>>>>Something else that might work is to base the grid on a SELECT statement. If you
>>>>>need to edit in the grid, copy the results of the SELECT into a temp cursor. Just
>>>>>be careful that you don't lose the connection between the grid and the RecordSource
>>>>>when you do that.
>>>>Yup. I should have added in parameterized view, but I think that it is unecessary to use one.
>>>>Can you help with the problem.
>>>
>>>The SELECT statement and the p-view are the only things I can think of
>>>offhand that will give you your sorted table....
>>
>>One problem I had when I started replacing tables with parameterized views in grids is that my "find" button, which does a LOCATE FOR myexpression, can't locate any child records, unless it finds one that goes with the current parent. Unless there is a better way, my find button will have to be changed so that it will locate in the underlying child table, get its parent key, then LOCATE FOR parent.key = child.parentkey, then REQUERY the parameterized view.
>
>And here I was thinking that param views was the way to go. These are the first negative remarks regarding them I've heard.
>
>Though I have to admit I am not that familiar with pv's, I would think that you be able to add another ?parameter that would hold the value of myexpression and then simply issue a Requery.
>
>HTH

I don't know how that would work. In this situation, I want to LOCATE FOR childfield operator value where childfield is in the pv of the grid. After finding that value, I would need to move the parent record pointer. The parameter of the view typically used in these grids is ?parentkey.