>Sigfried,
>
>I've always used your approach "B." I don't see why it should pull values from the base table, though, something fishy there. My code looks something like this:
>
>

>m.TestValue = MyAlias.MyUniqueField
>m.MyRecno   = RECNO()
>SELE MyUniqueField FROM MyAlias ;
>  WHERE RECNO() <> m.MyRecno;
>    AND MyUniqueField = M.TestValue;
>  INTO ARRAY a_temp
>IF _tally > 0
>  =Messagebox("Bad news....")
>ENDIF
>

>
>Hope this helps.
>
>>1. I've got this grid for editing lists of things.
>>2. One of the fields is a unique description.
>>3. Requirements dictate that we edit in the grid fields.
>>4. The grid is populated by a view.
>>5. The view is table buffered and we are not suposed to commit any changes to the table while in the editing screen.
>>6. If a user enters a value into the edit field in the grid for the unique description that is already in the list, a dialog should appear allowing them to delete the new entry or change it to something not in the list.
>>
>>Problem: I'm having trouble coming up with a good way to check the entered value against the values in the view. Things I have tried...
>>A. Using locate or seek on the view while in the valid of the entry field seems to muck about with the view reccord pointer witch causes the bound field to commit its value half way through wich messes up the reliability of the search. (damn grids)
>>B. Using a select from the view to do the searching in (as an array). But the select returns values form the table the view is based on and not the view. ie the changes made so far in the view do not show up in the select so the comparisons are unreliable.
>>C. Manualy maintaining an array that matches the list in the view. It works but i have to do allot of work to keep the array matching up, and it just isn't easy to maintain, and seems realy kludgy.
>>
>>I'd love to hear what people have done for this kind of situation, or how I might make one of these solutions work better. Thanks much.

There are many good ways here. For example, INDEXSEEK() will search in a table without moving record pointer. Also, you may use table-buffered view, so moving from record to record will not trigger tableupdate. Also, there are many other good ways, one of them I personally prefer: base grid on read/write cursor.