The optimiser is probably smart enough to derive the same plan anyway. For instance I get the same query plan and INdex utilisation for the following (very basic) queryDECLARE @foo TABLE ( [ID] INT , [val] VARCHAR(45) PRIMARY KEY ([ID]) )DECLARE @bar TABLE ( [ID] INT , [fooID] INT , [val] VARCHAR(25) PRIMARY KEY ([ID]) )INSERT @foo SELECT 1, 'a' UNION SELECT 2, 'b'INSERT @bar SELECT 1, 1, 'aa' UNION SELECT 2, 1, 'ab'SELECT f.[val] , b.[val]FROM @foo f JOIN @bar b ON b.[fooID] = f.[ID]SELECT f.[val] , b.[val]FROM @foo f , @bar bWHERE b.[fooID] = f.[ID]
I think if the queries are far more complex then you can get filtered CROSS JOINS when you didn't want them but...Anyway -- the JOINS are the standard and support for old school LEFT joins etc will be depreciated at some point.Charlie===============================================================Msg 3903, Level 16, State 1, Line 1736The ROLLBACK TRANSACTION request has no corresponding BEGIN TRANSACTION