• Your update query should be fine and, no, it does not matter if you include the table in the FROM or table operator clauses (e.g. JOIN & APPLY).

    With the way that SQL Server evaluates your query, the UPDATE statement is actually evaluated after the FROM and JOIN clauses. As long as your target table and target column are listed in you FROM or JOIN clauses they can be referenced in your SELECT or UPDATE statements.

    Itzek Ben-Gan talks about the query processing order in his excellent books. This pdf is a good reference:

    http://tsql.solidq.com/books/insidetsql2008/Logical%20Query%20Processing%20Poster.pdf

    I personally prefer to use a CTE for this type of task.

    Taking this sample data:

    IF OBJECT_ID('tempdb..#table1') IS NOT NULL DROP TABLE #table1;

    IF OBJECT_ID('tempdb..#table2') IS NOT NULL DROP TABLE #table2;

    CREATE TABLE #table1 (t_id int, t_txt varchar(20));

    CREATE TABLE #table2 (t_id int);

    INSERT #table1 VALUES (1,'old val'),(2,'old val'),(3,'old val');

    INSERT #table2 VALUES (2),(3);

    Instead of doing this:

    UPDATE #table1

    SET t_txt = 'New Val'

    FROM #table1 t1

    JOIN #table2 t2 ON t1.t_id = t2.t_id;

    you could use a CTE like this:

    WITH table1_filtered AS

    (

    SELECT t1.t_id, t1.t_txt

    FROM #table1 t1

    JOIN #table2 t2 ON t1.t_id = t2.t_id

    )

    UPDATE table1_filtered

    SET t_txt = 'New Val'

    I like this method because it's easier to understand and debug. Both UPDATES will produce the same query plan but, with the CTE method you can quickly highlight and run your select statement to see ahead of time what rows will be affects.

    Cheers.

    "I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code."

    -- Itzik Ben-Gan 2001