This simple query throws the \"Ambiguous column name TaskID\" error on one db-server only. This is ridiculous. We tested this with the same database structu
Wow. The problem was with the database compatibility mode. It was set to "80" (sql 2000). I've set it to 90 and the query works fine now.
More info on compatibility levels can be found here: http://msdn.microsoft.com/en-US/library/ms178653(SQL.90).aspx
You will get the ambiguous column name error if you run your query on sql server 2000, or under compatibility level 80 or less. On sql server 2005/2008 with compatibility level 90 or better, yur query runs fine.
From the order by clause docs:
"In SQL Server 2005, qualified column names and aliases are resolved to columns listed in the FROM clause. If order_by_expression is not qualified, the value must be unique among all columns listed in the SELECT statement."
What do you mean you can't? It's clear that both Tasks and TaskHelpers has a column named TaskID. You need to indicate which table the column in the Order By is associated with.
what if you try with identifiers? By using these identifiers SQL server know which column to order by. I never done it in any other way and never had any problems. I don't exactly why sql needs these identifiers, it's obvious he doesn't know where to order by when there are ambigious columnnames. Try something like;
SELECT t.TaskID
FROM Tasks t
INNER JOIN TaskHelpers th ON th.TaskID = t.TaskID
order by t.TaskID
EDIT: And what's the reason you can't? SQL throwing an error?
You can specify the index of the column to sort instead:
SELECT Tasks.TaskID
FROM Tasks
INNER JOIN TaskHelpers ON TaskHelpers.TaskID = Tasks.TaskID
order by 1
My Momma said always qualify EVERY column in a query with a table name/alias just like "always include all column names in INSERTs" and justs like "don't SELECT *", etc.
Other than making it easier because it is self documenting the source code, you prevent this error if you ever add/change columns.
check your compatibility levels, there are differences between them and the how ORDER BY works!
In general, in compatibility level 90 and higher, the default level for SQL Server 2008, an ORDER BY without a table name/alias statement produces the error.
ALTER DATABASE Compatibility Level (Transact-SQL) see section: Differences Between Compatibility Level 80 and Level 90
Compatibility-level setting of 80
WHEN binding the column references in the ORDER BY list to the columns defined in the SELECT list, column ambiguities are ignored and column prefixes are sometimes ignored. This can cause the result set to return in an unexpected order.
For example, an ORDER BY clause with a single two-part column (.) that is used as a reference to a column in a SELECT list is accepted, but the table alias is ignored. Consider the following query.
SELECT c1 = -c1 FROM t_table AS x ORDER BY x.c1
When executed, the column prefix is ignored in the ORDER BY. The sort operation does not occur on the specified source column (x.c1) as expected; instead it occurs on the derived c1 column that is defined in the query. The execution plan for this query shows that the values for the derived column are computed first and then the computed values are sorted.
Compatibility-level setting of 90
Errors are raised on column ambiguities. Column prefixes, if any, specified in ORDER BY are not ignored when binding to a column defined in the SELECT list.
Consider the following query.
SELECT c1 = -c1 FROM t_table AS x ORDER BY x.c1
When executed, the column prefix in the ORDER BY clause is not ignored. The sort operation occurs on the specified source column (x.c1) as expected. The execution plan for this query shows that the sort operator orders the rows returned from t_table and then the values for the derived column c1 defined in the SELECT list are computed.