Glenn, does it make a difference if you include the table name (table1.number instead of just number?) If so, you might be able to work around the problem. We had a similar one with existing fields named 'desc' in some updated tables, and using the table name helped substantially.

hth
Barbara

>Vlad,
>
>Thanks for your thoughts, I understand what you are saying about functions such as Recno() but in my case the View SQL I was using does not use Recno. It has a where clause to join the two tables as follows,
>
>table1.number = table2.staff_id
>
>In some of the records returned staff_id and number were different.
>To take the problem to it's simplest level I issued the following via the command window,
>
>SELECT number FROM table1 WHERE number = 20
>
>A record with number = 22 was returned whilst record 20 was ignored.
>On further checking I found the recno of record 20 was 22 and when the field name was changed to something other than 'number' everything was OK.
>
>Does this make sense ?
>
>>I think the problem is the RECNO() function, not the name of the field. Don't use RECNO() with a SELECT SQL on more than one table. The same goes for other VFP functions (like DELETE() for ex.). Basically, you don't know what happens inside the SELECT SQL. So, the result of these functions is undetermined.
>>
>>To be more clear: using such functions with no parameter for alias means they are applied for the current work area, but you don't know which is the current area at every moment inside SELECT SQL. If you specify the alias as the parameter for the function, it will be applied to the alias you already have, not to the table (which is open again) inside SELECT SQL.
>>
>>If you really need to use a function like that, first SELECT from one table. In this way you have the info you want as a field in the result. After that you can join this result with your other tables using another SELECT. This will give you the correct result.
>>
>>HTH,
>>Vlad