July 8, 2008 at 12:06 pm
CAGreensfelder (7/8/2008)
Your problems with cut & paste are not the author's fault. Everything I copy from a code block gets smooshed into one long line, even Jeff Moden's beautiful code. I forget why it happens but I remember the work-around:Keep an instance of MS Word open on the side.
Copy a code block & paste into Word.
Select and copy the code block FROM WORD.
Paste into a QA or SSMS query window.
The line breaks will follow along then and you won't have that problem.
It's anoying but it works.
My previous reply got killed by an expired cookie. It was probably too long anyway. 😉
Thanks for the workaround. I will keep it in mind.
Basically, what I was getting at in my post was that it wasn't just spelling and grammar that needed the editing but the SQL scripts as well. Here are a couple of examples... In the second CREATE TABLE script, the INT IDENTITY(1,1) was left off. This causes an error. I happened to catch it right away but I shouldn't have had to. The next example is in the script for populating the second table based on the first. When I run it as is I get:
Msg 8101, Level 16, State 1, Line 1
An explicit value for the identity column in table '#InnerJoinTest2' can only be specified when a column list is used and IDENTITY_INSERT is ON.
It took me a few minutes to look up what I had to do and figure out that I needed to do this:
set identity_insert #InnerJoinTest2 on
INSERT INTO #InnerJoinTest2
(InnerJoinTest2_PK)
SELECT * FROM #InnerJoinTest1
Again, this may not seem like a big deal to an experienced person but I shouldn't have had to do it. I read the article to see what the author had to say about the inner workings of the inner join, not to debug the scripts. Debugging the scripts not only ate up the limited time I had for reading but it took my focus off the point of the article.
My intent here isn't to whine. I want to encourage the author (and maybe others) to take the time to test the script as well as edit the grammar/spelling. I think both are equally important.
Regards,
Eric
July 8, 2008 at 12:25 pm
This article was written in a good form, but if the goal was clarifying the logic of inner join the content MUST be 100% correct. I can live with one or two typos, but please update the analysis of query 4 & 5, it just isn't correct.
Thanks.
July 8, 2008 at 12:55 pm
Eric, you have a legitimate complaint. I had forgotten about the syntax error -I fixed it and blew on by when I was doing my test run. I thought I'd just botched the cut & paste.
An error in the example code is a fatal flaw. It's a total killer for novices.
BTW All you needed to add was "INT", not the "IDENTITY" part. Adding the "IDENTITY" gave you the extra problems.
July 8, 2008 at 2:09 pm
Looking past the grammatical errors in the article -- which Steve has already explained, I am of the opinion that the underlying content is valuable for those newer to SQL that may not have had exposure to the slightly "out-of-the-box thinking" involved in using theta-joins that are not equi-joins.
My disappointment with the article, however, lies in the fact that the author does not introduce these fundamental concepts and terminology (theta- and equi-join), fails to mention CROSS JOIN at all in the cartesian product section, and somewhat gives the impression that this is a comprehensive list of theta-join predicate types (it isn't).
A "nice to have" for the article would have been an analyisis of the effects of the various predicates on the query plan, just so users would get a feel for when they're about to cause a table scan, for instance.
Getting back to the editing issue though, Steve, if you're reading this, I'm volunteering to help out with editing duties. I know it's a big job with all of the question, script, and article submissions. You know how to get in touch...:cool:
TroyK
July 8, 2008 at 2:53 pm
gandalf97us (7/8/2008)
...Basically, what I was getting at in my post was that it wasn't just spelling and grammar that needed the editing but the SQL scripts as well. Here are a couple of examples... In the second CREATE TABLE script, the INT IDENTITY(1,1) was left off. This causes an error. I happened to catch it right away but I shouldn't have had to.
...
The ONLY thing that was missing from the CREATE and POPULATE scripts was the column definition from Table 2. It should have been
CREATE TABLE #InnerJoinTest2( InnerJoinTest2_PK INT)
If you are going to complain about someone else's code, please get it right.
And (I know other have said it already) PLEASE quit complaining about the lady's command of the English language. We are a community of SQL Server professionals, we are here to help each other and disseminate tips and tricks we learn, not to flame one another for spelling mistakes. Everyone who flames reduces the tone of the site, not the user who takes the time to submit an article, no matter the level of the article.
As for
jpellman (7/8/2008)
Please read your work before publishing content. English is America's language - God bless America!!!
If I write colour (with a 'u') instead of color, are you going to correct me. After all, that's English, but not American English, please don't be so jingoistic in your attitudes (http://dictionary.reference.com/browse/jingoism).
July 8, 2008 at 2:53 pm
Nice article, Keep is up.
Thanks -- Vj
July 8, 2008 at 3:13 pm
I appreciate the article and it clearly involved a lot of effort, but it would have been more useful if it spent more time comparing inner joins with the other types of joins and showing how they were different. This instead seemed to focus on the different results which could be generated with an inner join, which while useful was not as useful as a more thorough comparison.
---
Timothy A Wiseman
SQL Blog: http://timothyawiseman.wordpress.com/
July 8, 2008 at 4:14 pm
the concepts were decent...and the article was well meant, but the schematic presentation leaves much to be desired...there was no train of thought apparent on the way the article flowed....
needs better english.....
July 8, 2008 at 5:15 pm
I have seen most folks have raised their concerns for syntax errors and the output of Q4 and Q5.
Here are the clarifications for those.
There was a syntax error in table creation. It should be corrected as,
CREATE TABLE #InnerJoinTest2( InnerJoinTest2_PK int )
NOTE: There is no need of IDENTITY column for second table.
The Q4 can be re-written as follows to match with the result set given in the article.
SELECT b.*,a.* FROM #InnerJoinTest1 a INNER JOIN #InnerJoinTest2 b ON a.InnerJoinTest1_PK<b.InnerJoinTest2_PK
ORDER BY a.InnerJoinTest1_PK
This will clear the most concerns for many folks.
My apologies for typos and grammatical mistakes in the article.
Susantha
July 8, 2008 at 5:25 pm
A good article, and though all of the concepts revealed in this were well under my belt I certainly felt that this article would have been perfect for me to understand the INNER JOIN when I was starting down the SQL several years ago.
July 8, 2008 at 9:20 pm
Wow, can't say I have seen so much complaining about an article in a long time.
I have to work with all sorts of individuals who have no idea about SQL, let alone joins and how they work that an article like this is a good resource that I can use to get the basic concepts across. This includes Senior Programmers, Senior System Analysts, Principal Technical Lead, Project Managers, etc...
In a lot of cases, these people are coming from a system that doesn't use SQL. In one case, the programmers are using Mumps (Intersystems Cache) and are struggling a lot to overcome the procedural approach they are used to and using a set-based approach.
Now, for those of you who have complained so much about this article not living up to your expectations - I am eagerly awaiting your articles to be published. I look forward to discussing the advanced topics you will be writing about.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
July 8, 2008 at 9:51 pm
Hi
Article was really simple to understand which helps in solving complex queries.
My Humble request could you also post on other JOINS as well.
Waiting for those articles
Thanks,
Suresh
July 9, 2008 at 7:04 am
Simon Facer (7/8/2008)
gandalf97us (7/8/2008)
...Basically, what I was getting at in my post was that it wasn't just spelling and grammar that needed the editing but the SQL scripts as well. Here are a couple of examples... In the second CREATE TABLE script, the INT IDENTITY(1,1) was left off. This causes an error. I happened to catch it right away but I shouldn't have had to.
...
The ONLY thing that was missing from the CREATE and POPULATE scripts was the column definition from Table 2. It should have been
CREATE TABLE #InnerJoinTest2( InnerJoinTest2_PK INT)If you are going to complain about someone else's code, please get it right.
Those who pointed out that the IDENTITY(1,1) was not necessary in the second create were correct. When I tried to get it to work and it didn't I tried making it like the first one because I didn't know any better. My mistake but I thought it was a reasonable guess. My point (which you ignored) that The code should have been tested is still valid.
Also, I reread this thread and while some people were just complaining, a great many took a more constructive tone. Simply saying that spelling/grammar/code bugs detracted from the article doesn't qualify (at least in my book) as whining. It completely depends on the tone of the text. I tried to be constructive and a lot of others did too.
Thanks again to the author both for the original article and for the grace with which she accepted the criticism (both constructive and petty) and posted corrections. She showed a great deal of class and professionalism.
Regards,
Eric
July 9, 2008 at 8:04 am
excellent article
July 9, 2008 at 8:54 am
I agree, a good article for beginners.
Don't know what all the fuss is about. I am fussy about grammar and spelling, but it wasn't difficult to work it out.
Viewing 15 posts - 61 through 75 (of 134 total)
You must be logged in to reply to this topic. Login to reply