September 6, 2011 at 2:40 pm
Nice question, but I got it wrong by the ambigous column name (not really the point the question was focusing on).
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
September 6, 2011 at 2:42 pm
Hey guys - what am I missing?? I had 3 as failing, so was stumped that 1, 3 and 4 wasn't an option - I knew that 2 would work, as have met the ORDER BY with a TOP in sub select before.
But I CANNOT construct a query like 3 that doesn't fail with an ambiguous column error - what gives?
The following code
SELECT a.co_seq
FROM F_Pm_Tenant a
JOIN F_Contact b ON a.co_seq = b.co_seq
ORDER BY co_seq
gets the result:
Msg 209, Level 16, State 1, Line 4
Ambiguous column name 'co_seq'.
every time. What is the difference (apart from the table & column names!) between this and the example in the question?
Confused :unsure:
September 6, 2011 at 3:51 pm
antony-688446 (9/6/2011)
Hey guys - what am I missing?? I had 3 as failing, so was stumped that 1, 3 and 4 wasn't an option - I knew that 2 would work, as have met the ORDER BY with a TOP in sub select before.But I CANNOT construct a query like 3 that doesn't fail with an ambiguous column error - what gives?
The following code
SELECT a.co_seq
FROM F_Pm_Tenant a
JOIN F_Contact b ON a.co_seq = b.co_seq
ORDER BY co_seq
gets the result:
Msg 209, Level 16, State 1, Line 4
Ambiguous column name 'co_seq'.
every time. What is the difference (apart from the table & column names!) between this and the example in the question?
Confused :unsure:
Which version of SQL Server are you using? I tested this on 2005.
September 6, 2011 at 4:01 pm
SQL Server 2005 SP3 - 9.00.4060 (which I can't find on MS's version list ๐ )
September 6, 2011 at 4:05 pm
cengland0 (9/6/2011)
antony-688446 (9/6/2011)
Hey guys - what am I missing?? I had 3 as failing, so was stumped that 1, 3 and 4 wasn't an option - I knew that 2 would work, as have met the ORDER BY with a TOP in sub select before.But I CANNOT construct a query like 3 that doesn't fail with an ambiguous column error - what gives?
The following code
SELECT a.co_seq
FROM F_Pm_Tenant a
JOIN F_Contact b ON a.co_seq = b.co_seq
ORDER BY co_seq
gets the result:
Msg 209, Level 16, State 1, Line 4
Ambiguous column name 'co_seq'.
every time. What is the difference (apart from the table & column names!) between this and the example in the question?
Confused :unsure:
Which version of SQL Server are you using? I tested this on 2005.
3 should fail as well for the very reason stated - it is ambiguous.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
September 6, 2011 at 4:08 pm
SQLRNNR (9/6/2011)
cengland0 (9/6/2011)
antony-688446 (9/6/2011)
Hey guys - what am I missing?? I had 3 as failing, so was stumped that 1, 3 and 4 wasn't an option - I knew that 2 would work, as have met the ORDER BY with a TOP in sub select before.But I CANNOT construct a query like 3 that doesn't fail with an ambiguous column error - what gives?
The following code
SELECT a.co_seq
FROM F_Pm_Tenant a
JOIN F_Contact b ON a.co_seq = b.co_seq
ORDER BY co_seq
gets the result:
Msg 209, Level 16, State 1, Line 4
Ambiguous column name 'co_seq'.
every time. What is the difference (apart from the table & column names!) between this and the example in the question?
Confused :unsure:
Which version of SQL Server are you using? I tested this on 2005.
3 should fail as well for the very reason stated - it is ambiguous.
Which would mean that the question and BOL are wrong...
September 6, 2011 at 4:20 pm
Ok, own question answered - compatibility level was set to SQL Server 2000 (80) (Don't ask me why, as I don't know...). Changed to 2005, and the query now executes as per BOL.
Nice to finally get an answer!
And great question, as I've finally found something that compatibility levels affect...
September 6, 2011 at 4:31 pm
antony-688446 (9/6/2011)
Ok, own question answered - compatibility level was set to SQL Server 2000 (80) (Don't ask me why, as I don't know...). Changed to 2005, and the query now executes as per BOL.Nice to finally get an answer!
And great question, as I've finally found something that compatibility levels affect...
I was about to answer with a test setup that I created.
IF EXISTS (SELECT 1 FROM sys.objects WHERE name = 'tab1' AND type = 'u')
BEGIN
DROP TABLE Tab1
END
GO
IF EXISTS (SELECT 1 FROM sys.objects WHERE name = 'tab2' AND type = 'u')
BEGIN
DROP TABLE Tab2
END
GO
SELECT TOP 10000
OrderID = IDENTITY(INT,1,1),
OrderAmt = CAST(ABS(CHECKSUM(NEWID()))%10000 /100.0 AS MONEY),
OrderDate = CAST(RAND(CHECKSUM(NEWID()))*3653.0+36524.0 AS DATETIME)
INTO dbo.tab1
FROM Master.dbo.SysColumns t1,
Master.dbo.SysColumns t2
go
CREATE TABLE [dbo].tab2(
[OrderID] [int] NOT NULL,
[OrderDetailID] [int] NOT NULL,
[PartAmt] [money] NULL,
[PartID] [int] NULL)
;
Insert Into tab2 (OrderID,OrderDetailID,PartAmt,PartID)
Select OrderID,
OrderDetailID = 1,
PartAmt = OrderAmt / 2,
PartID = ABS(CHECKSUM(NEWID()))%1000+1
FROM tab1
SELECT a.OrderID
FROM dbo.tab1 a
INNER JOIN dbo.tab2 b
ON a.OrderID = b.OrderID
ORDER BY OrderID
DROP TABLE tab1
DROP TABLE tab2
SQL 2005 automatically uses the column in the select for the order by in the case we specify just this one column.
I had been caught by the ambiguous column several times - but compat mode must have been at play there.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
September 7, 2011 at 1:10 am
cengland0 (9/6/2011)
Tee Time (9/6/2011)
The most commonly selected answer (so far) is "Query 3 and Query 4 will fail" (28%) which means many people think it's okay to put an order by clause inside a subquery.
I selected that option, as I didn't realise that ordering by an unqualified column would use the one specified in the Select.
I found the question difficult as a lesson I learned many years ago is always to qualify everything, both for clarity, and to prevent unexpected results.
September 7, 2011 at 2:14 am
Thanks for the excellent question, I really had to think.
#4 was obvious due to the SELECT *, but It took a while before I realized that you need a TOP clause in the sub select.
BTW, SELECT * is one of the top mistakes that you should avoid, and this is one of the reasons, but there are plenty of more.
/Hรฅkan Winther
MCITP:Database Developer 2008
MCTS: SQL Server 2008, Implementation and Maintenance
MCSE: Data Platform
September 7, 2011 at 11:20 am
Thanks for the question!
-Dan
September 7, 2011 at 4:13 pm
Good question.
I got it wrong. Q1 is obviously wroing, and I immediately concluded it was all about "order by" and just skim the rest for "order by" related errors - so missed the obvious problem with 4. Another confirmation that one should read code carefully, not skim it carelessly.
Tom
September 7, 2011 at 4:23 pm
But of course one could say that the query processing ought to notice that there is no ambiguity in number 4, because any possible ambiguity is eliminated by the ON clause of the join. Would such ambiguity elimination be a good thing or a bad thing? I'm in two minds about it.
Tom
September 7, 2011 at 9:13 pm
Tom.Thomson (9/7/2011)
But of course one could say that the query processing ought to notice that there is no ambiguity in number 4, because any possible ambiguity is eliminated by the ON clause of the join. Would such ambiguity elimination be a good thing or a bad thing? I'm in two minds about it.
Because the two values are equal, I agree that it's not technical ambiguity; however, you can use nonequalities in the joins too like:
ON Column1 > Column2
Shouldn't happen often but the complexities in the query optimizer would be too difficult for Microsoft to handle ๐
And to make it clear, it was due to the ORDER BY clause so the subject of the QOTD was still okay. If you were to remove the ORDER BY clauses, all 4 queries would run properly. Query 1 and 4 fail because of the invalid ORDER BY clauses -- not because of any other reason.
September 7, 2011 at 10:38 pm
Thanks for the nice questions!!
Viewing 15 posts - 31 through 45 (of 50 total)
You must be logged in to reply to this topic. Login to reply