>>I disagree completely. Did you run the same code in SQL Server? It works as expected there. I trust SQL Server for correct parsing way more than FoxPro.
>
>No one has yet to comment on the FACT that the results are different and as expected when executed against SQL Server 2000.
>
>I do most of my work against SQL Server and I wrote that UPDATE statement as I would normally write in SQL Server (T-SQL). Fortunately, for me I double checked the results in FoxPro and noticed the HUGE undeniable difference. Again, I ask which do you trust more - SQL Server or FoxPro? I say SQL Server is the better benchmark and gold standard.
>
>However, looking at the fine print in FoxPro help I see that it is BY DESIGN where Help says the following under the UPDATE - SQL section:
>
>****************
>Local_Alias specifies a temporary name for the table specified in Table. If you specify a local alias, you must use the local alias instead of the table name in the UPDATE statement. The alias can represent a table or a cursor.
>****************
>
>Thus, this is why the correct syntax when using a "local alias" is as follows:
>
>update y set y.d1 = x.d2 from junk as y inner join junk2 as x on y.id = x.id &&works correctly
>
>Nevertheless, I find it disconcerting that FoxPro will execute and return incorrect results using the following that is syntactically incorrect according to FoxPro help via the following:
>
>update junk set d1 = x.d2 from junk as y inner join junk2 as x on y.id = x.id &&WRONG results.
>
>In my opinion the above should result in a syntax error.

Fox Pro is not perfect.
But SQL Server is not perfect too.

SELECT X=1
	INTO #DUMMY
	UNION ALL
SELECT 2

SELECT *
	INTO #DUMMY2
	FROM #DUMMY

-- with "FROM", SQL SERVER tries to guess
UPDATE #DUMMY SET X=0 FROM #DUMMY A JOIN #DUMMY2 B ON A.X=B.X+1

-- this don't require some guess
UPDATE #DUMMY SET X=0 FROM #DUMMY2 A WHERE #DUMMY.X=A.X

-- here name it is ambiguous and then returns an error
-- then you cannot use a table 3 or more times without update an alias
UPDATE #DUMMY SET X=0 FROM #DUMMY A JOIN #DUMMY B ON A.X=B.X+1 WHERE #DUMMY.X=A.X+2

the Achilles' heel lies in the fact foxpro tries to reconcile two very different environments,
such as xBase and SQL.

SQL Server in this case follows a road that leads to ambiguity;
but the ambiguity is not on the street, but rather on the choice to travel it