May 8, 2013 at 9:46 pm
Comments posted to this topic are about the item The Subquery
Malleswarareddy
I.T.Analyst
MCITP(70-451)
May 8, 2013 at 11:08 pm
Nice question....
Here are some more scenarios:
--Scenario 1
create table address_staging
(client int primary key,addressdetails varchar(250));
insert into address_staging
select 100,'hyderbad,india'
union all
select 101,'banglore,india'
union all
select 102,'banglore,india'
;
create table address_oltp
(client_id int primary key,address_details varchar(250));
insert into address_oltp
select 104,'newyork,usa'
union all
select 105,'chicago,usa'
union all
select 106,'washington,usa'
;
select *
from address_oltp
where client_id in (select client_id from address_staging)
--result
client_idaddress_details
104newyork,usa
105chicago,usa
106washington,usa
---Scenario 2
select *
from address_oltp
where client_id in (select client from address_staging)
--Result
It will return 0 rows
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
May 8, 2013 at 11:16 pm
unfortunately, i trapped in this question. :crying:
But i learn something new. π
Thanks reddy
Thanks
Vinay Kumar
-----------------------------------------------------------------
Keep Learning - Keep Growing !!!
May 9, 2013 at 1:13 am
Nice question...
Hope this helps...
Ford Fairlane
Rock and Roll Detective
May 9, 2013 at 1:15 am
A good question, but I'm not so sure about the explanation.
If a column is referenced in a subquery that does not exist in the table referenced by the subquery's FROM clause, but exists in a table referenced by the outer query's FROM clause, the query executes without error.
Fair enough, but this isn;'t the case here, as the ciolumn referenced in the subquery does exist in the table referenced by the subquery's FROM clause.
May 9, 2013 at 1:30 am
Toreador (5/9/2013)
A good question, but I'm not so sure about the explanation.If a column is referenced in a subquery that does not exist in the table referenced by the subquery's FROM clause, but exists in a table referenced by the outer query's FROM clause, the query executes without error.
Fair enough, but this isn;'t the case here, as the ciolumn referenced in the subquery does exist in the table referenced by the subquery's FROM clause.
No it does not. You should look carefully - table in subquery (address_staging) have a column clientid and select is using client_id. Mind the underscore _.
Funny fact - I've recently wrote something (article) about this - I've called it "Accidental correlated subqueries". (So I've spotted it on sight here π ) This is actually quite possible to happen in real life situations, and could be very dangerous when used with delete statement. We've once ruined a production table because of it (true story).
Best practice to make sure you don't make mistake with incorrect column names should be to always use table names or aliases in front of column names:
select *
from address_oltp t1
where t1.client_id in (select t2.client_id from address_staging t2)
Have the code been written like this it would produce an error and you would spot something is not written correctly.
_______________________________________________
www.sql-kefalo.net (SQL Server saveti, ideje, fazoni i fore)
May 9, 2013 at 1:34 am
Well spotted π
I'd say best practice is not only to use aliases, but also to adopt and stick to some standard naming conventions for your database!
May 9, 2013 at 1:34 am
I faced this issue when coding for my project work. We follow naming conventions and we use '_' for oltp tables. Before doing the functional testing I usually test each line of code in my procedure.
While testing the below line of code I found that it was not throwing errors and was fetching records (although incorrectly) even though the column name (client_id) in the subquery did not exist.
select *
from address_oltp
where client_id in (select client_id from address_staging)
So I verified and fixed this issue with below code.
select *
from address_oltp
where client_id in (select clientid from address_staging)
I found the reason why the first code did not show any errors in the msdn website.
The reference link is given below.
http://msdn.microsoft.com/en-IN/library/ms178050(v=sql.105).aspx
Microsoft should provide information message when developer is doing mistakes. For ex., If dependent procedure is missing when creating procedure it will show βThe module '%.*ls' depends on the missing object '%.*ls'. The module will still be created; however, it cannot run successfully until the object exists.β
Malleswarareddy
I.T.Analyst
MCITP(70-451)
May 9, 2013 at 1:39 am
nenad-zivkovic (5/9/2013)
Toreador (5/9/2013)
A good question, but I'm not so sure about the explanation.If a column is referenced in a subquery that does not exist in the table referenced by the subquery's FROM clause, but exists in a table referenced by the outer query's FROM clause, the query executes without error.
Fair enough, but this isn;'t the case here, as the ciolumn referenced in the subquery does exist in the table referenced by the subquery's FROM clause.
No it does not. You should look carefully - table in subquery (address_staging) have a column clientid and select is using client_id. Mind the underscore _.
Funny fact - I've recently wrote something (article) about this - I've called it "Accidental correlated subqueries". (So I've spotted it on sight here π ) This is actually quite possible to happen in real life situations, and could be very dangerous when used with delete statement. We've once ruined a production table because of it (true story).
Best practice to make sure you don't make mistake with incorrect column names should be to always use table names or aliases in front of column names:
select *
from address_oltp t1
where t1.client_id in (select t2.client_id from address_staging t2)
Have the code been written like this it would produce an error and you would spot something is not written correctly.
It's true. am also using alias when writing code. this issue i have faced almost one and half year back. but i posted this question few months back.
Malleswarareddy
I.T.Analyst
MCITP(70-451)
May 9, 2013 at 1:42 am
Danny Ocean (5/8/2013)
unfortunately, i trapped in this question. :crying:But i learn something new. π
Thanks reddy
me too.. But it will be helped in my future...
thanks nice question....
Manik
You cannot get to the top by sitting on your bottom.
May 9, 2013 at 2:00 am
Client_id vs Clientid - I am glad I noticed this in the last minute.
The question pretends to be about subqueries, but I am pretty sure that the 38% people that picked the "no rows" option were caught off guard by this. Suggestion to the author of the question - next time, if you want to demonstrate something, make it stand out instead of trying to hide it. I get that in a real system, this kind of error can happen with subtle spelling differences between columns names (if no naming standards are used). But in a question that focuses on educating about subquery scope, you should make it stand out so that the readers know what to focus on.
That being said - I appreciate the effort of submitting a QotD, and I hope to see more of you in the future.
May 9, 2013 at 2:05 am
Have to admit, I'm puzzled by this behaviour. It doesn't make logical sense for SQL to make a substitution like this when the table you're selecting from is explicitly named in the subquery, surely? :ermm:
May 9, 2013 at 2:13 am
Good one, thank you for the post.
(so basic, and yet so important in our daily script writings and need to keep an eye on it.)
ww; Raghu
--
The first and the hardest SQL statement I have wrote- "select * from customers" - and I was happy and felt smart.
May 9, 2013 at 2:26 am
paul.knibbs (5/9/2013)
Have to admit, I'm puzzled by this behaviour. It doesn't make logical sense for SQL to make a substitution like this when the table you're selecting from is explicitly named in the subquery, surely? :ermm:
It's not really making any substitution. Yes, there is a table mentioned in subquery in FROM but the columns in SELECT can also come from outer query. It is perfectly OK to use columns from outer table anywhere in subquery - and SQL Server is not gonna make a guessing whatever you planned from outer or inner table. If it exist in one and not another it's going to be used.
Since nothing from subquery's table is actually selected here - it can very well be omitted. Any of these would be exactly the same:
select * from address_oltp where client_id in (select client_id from address_staging)
select * from address_oltp where client_id in (select client_id)
select * from address_oltp where client_id = client_id
select * from address_oltp where 1=1
select * from address_oltp
_______________________________________________
www.sql-kefalo.net (SQL Server saveti, ideje, fazoni i fore)
May 9, 2013 at 2:50 am
This was removed by the editor as SPAM
Viewing 15 posts - 1 through 15 (of 42 total)
You must be logged in to reply to this topic. Login to reply