I often compare logging on to this site to visiting a pub during happy hour. When I am on the site and I see a familiar name light up in green, it takes all I have to keep myself from shouting out a "hey there - long time no see" or some such. Sometimes you get to interact with some of your faceless friends while you're responding to the same post - sometimes you raise a silent toast to a brilliant solution. At other times you just hang out - listening to the heated argument at the next table about whose solution performs better - eavesdropping on some friendly bickering going on at that far forum in the corner and sometimes even being privy to personal tidbits and details unfold. What draws us all to this watering hole is gaining and/or sharing knowledge related to SQL Server.

For each rookie with a question or problem, there're any number of eager beavers (ranging from the merely enthusiastic to those with advanced savoir-faire to acknowledged savants) competing in an unpublicized race - for the coveted prize of being "first responder". For the most part things go along fairly well at this SQL-Xanadu - till you come across those notes of discord - some annoying, some just a tad unpleasant and some downright striking.

After years of silently seething over these deviant notes, it struck me that it was possible that some people may not be aware of what constitutes "acceptable norms". Even though it's almost no different from when you're sitting vis-a-vis someone - you may be separated by a table or miles of ether - but the rules for interaction and social skills are mostly similar. I compiled a list of dos and don'ts for all such deviants in order to provide them with a comprehensive catalog. To illustrate by examples, I have used only contents in actual posts on SSC so I can't be accused of making stuff up. Everything in double quotes from here on is therefore, an excerpt from one of the many forums.

Know your subject:

Please post in the relevant forum - make a point of reading the title before posting - they are all divided very comprehensibly between 2000 and 2005 - within these you have Administration, Programming, General, Replication etc. There is nothing more annoying than trotting off to lend a helping hand in a 2000 related t-sql forum only to find that it's all about Yukon integration services or vice-versa. The Suggestions forum is the one where I find the most mis-postings. This one is for the members to make suggestions to the site-owners about a wishlist, changes they'd like to see, ideas on improving the site etc. More often than not, people seem to think this is to be used for asking for suggestions - I have seen "coalesce is not working"; "IF statement in a function"; "How we can restrict a single ROW in SQL server 2005?" posted here and it's really a measure of how dedicated and thorough the SSC members are, that these get answered at all.

The truth, the whole truth and nothing but..:

The more detailed your query, the quicker someone will post a solution. Vague and cryptic posts end up being frustrating and time-consuming for both the poser as well as the people trying to help. Here're some quotable responses from people who want to help but cannot because they don't have enough information:

1) "Please post DDL, so that people do not have to guess what the keys, constraints, Declarative Referential Integrity, datatypes, etc. in your schema are. Sample data is also a good idea, along with clear specifications."

2) "Post : - Table definitions - sample data - wrong resultset - expected resultset. It's like asking a mechanic to fix your flat tire without bringing the car in. That's just not gonna work."

Then the question from someone who wanted to know why his procedure was taking so long to execute without really giving much more information on run time etc. In trying to extract more information, one member said that time is really very relative and went on to exemplify - "Einsteins thoughts on the relativity of time: If you hold your hand on a hot stove for a second that is a long time. If you spend the night with a beautiful woman that is a very short time."

Help us help you:

This request is joined at the hip with the previous one. Please know that when you post ddl and sample data etc. it saves the troubleshooter valuable time and you get a double action response in record time. The link that is referenced here - "SQL ETIQUETTE SITE" is obviously not visited enough. Newbies, in particular, should make it a point of stopping here first and making it step 1 in the process of posting their query. I've often toyed with the idea of suggesting to the site-owners that they have a pop-up window that reminds people to visit this site first before posting. Maybe they could filter it by forum title and number of post counts so (eg.) anyone posting in the newbie forum that has a post count of less than 100 (or thereabouts) will get this link - like an annoying close cousin of the intrusive Office paperclip!!! Here's a query from someone who not only needs help but really knows how to ask for it :

********************************************************************
"I need this for my monthly report. Any help is greatly appreciated.
/* Schema */DECLARE @MyCalls TABLE
(
CallDate DATETIME,
Calls  INT
)
DECLARE @MyCars TABLE
(
DataDate DATETIME,
Qty  INT
)

/* Data */INSERT @MyCalls
SELECT '06/01/2006', 1 UNION ALL
SELECT '06/02/2006', 12 UNION ALL
SELECT '06/03/2006', 5 UNION ALL
SELECT '06/04/2006', 4 UNION ALL
SELECT '06/05/2006', 2
INSERT @MyCars
SELECT '06/04/2006', 1256 UNION ALL
SELECT '06/11/2006', 1267 UNION ALL
SELECT '06/18/2006', 1282 UNION ALL
SELECT '06/25/2006', 1298............
/* Requirement */Calls are recorded daily and cars are counted weekly
I have to create a report how many calls were received per car
daily.
If the parameter is passed as 'PAST'
SELECT A.CallDate, A.Calls / B.Qty (Qty as of previous reorded date from call date)
FROM
 @MyCalls A
JOIN
 @MyCars B
If the parameter........"
************************************************************

Eggs in one basket:

DO NOT POST IN MULTIPLE FORUMS. I cannot emphasize this one enough. It really does send many of the problem solvers into a downright hissy fit (yes - even the men) if they've just spent some measurable time answering a question to discover that it's been posted in four different forums and was already addressed in one of the others. It's one thing to have enough ambiguity in the question that you feel that it may be appropriate under multiple forums and quite another to think that your post would have more visibility if you have an "in-your-face" approach and thrust it under everyones' collective nose. If you're not sure where to post it, mention that in your post, and if it's too much off the topic it will be pointed out.

Mind your Ps and Qs:

You ask a question and someone takes the trouble to answer it - sometimes immediately and sometimes after going back and forth for a long time to help you resolve it. It really does behoove you to thank the person as well as post the working solution so others can benefit from your post.

I know one member who spends an inordinate amount of time running scripts and doing comprehensive analyses before posting his solution. He's (almost) always unfailingly polite but even he reached the end of his tether when he got neither a feedback nor a thank you - "Ok, then... you ask a question, I bust a hump giving you a pretty good answer... did it work for you or what?"

At the very least, let the person know that you're working on it and will get back as soon as you have everything sorted out.

Do your homework:

If you have the leeway and can spend some time using the various search features on the site you'll find that many questions have been answered in part or fully at some time in the past. If those answers don't satisfy your requirements then you can post your own query. Another good source is Books Online - abbreviated to BOL - the help documentation that ships with SQL Server and provides invaluable reference.

You will be looked upon much more kindly if you make known the fact that you've tried your best to solve something on your own before seeking help. Otherwise you may come across harsh but justifiable comments like these:

1) "Dude, get a book and learn, this isn't a school for newbies. We don't mind helping but we actually paid and worked to get our information."

2) "I think it's time you start TRYING to learn on your own. I'm not paid to show you

every little details of sql programmings and I surely won't do it."

3) "Would you mind to open BOL? Or you prefer somebody else to do it for you and copy-paste the topic here?"

4) "Sorry for being blunt but you need a wake up call."

Temper that tone:

You're the one seeking help. Set your attitude aside and realize that arrogance on your part will only antagonize those who are trying to help. There have been some downright rude and appalling posts that on any other site would not even have merited a response.

1) "..before replying to the question think and if dont know the answer wait for the answer."

2) "I request to those who suggest me to read books online pls dont reply."

3) "Ur answer makes me laugh."

Given the diverse backgrounds of members as well as the fact that the English language is not everyones' strong suit it is possible to make allowances, but only to an extent. Having adopted (what I thought) a particularly clever signature line, it was a rude awakening to realize that some actually misread it as a personal attack.

4) "I m no doubt polite, but I may be rude bcoz of following quotation

ASCII stupid question, get a stupid ANSI !!!"

And now this..the only section devoted to (n)etiquette for those who respond!!!

Just because you're a SQL God...:

is no reason to not be patient and courteous with those who are struggling to understand. Anyone who chooses to help does so because he/she wants to - no one is compelled to help and for the most part most of the members are extremely helpful without being condescending or unkind. There are those, however, who are inarguably far superior in their SQL skills and often their chastisement of the uninitiated is so harsh and severe that these people flee in terror never to come back. Does this not defeat the very purpose of a site like this ?!

Here're some classic excerpts from posts where the newbies have been put through the shredder..

Q)"magic tables will created automatically when trigger fires, i want to know that naming convention means tablename_insert like that, i want correct formation"

A) "We do not work and live in FairyLand where elephants drop out of the sky by magic. Please stop programming before you hurt someone and take the time to read at least one book on RDBMS and data modeling."

"Stop progamming and start reading. Then start re-writting all of your code.

Have you noticed that most of the posting are not for help, but for kludges? Scenario: The poster has coded himself into a corner because he did not bother with even a basic book. He then goes to a newsgroup and posts what Chris Date calls "do my homework for me" requests."

Sure - these gurus are justifiably angry with all those poorly designed databases out there that're limping along defying with every lame stumble the very foundations of RDMS - when they take the trouble to explain themselves, you can actually feel their angst:

"If this were a woodworking newsgroup and someone posted a request for the best kinds of rocks to smash screws into fine furniture, would you tell them "Granite! Big chucks of it?" Or would you tell them to look up screwdrivers, pre-drilled holes and specialty screws? And try to get that rock out of their hands ..."

Here's another SQL heavyweight with a sarcastic observation:

"It's funny, but I never have read from anybody designed those databases, everybody just inherited and does not have a chance to change anything."

and the impassioned comeback from a clearly angered poster who aptly sums up the frustrations of the real world scenarios that most of us have to face:

"..he also apparently lives in a fantasyland where everyone is hired by a company that is just beginning to use SQL Server, and therefore has full and utter control over the design, where no one is a short term consultant that has to work within the existing framework no matter how badly designed, and where there aren't a million applications already in existence that are running against a database, thus making design changes extremely tricky. He also seems to forget that there is a state in the learning process that is between "I don't have a freaking clue about SQL Server" and "I'm a a SQL Server god". In reality, the vast majority of SQL folks are at some point between the two, and helping them towards the latter goal is why this board is here.

While it's always a good idea to attempt to fix problems with design rather than to work around them, some of us

in the real world are perfectly willing to let you know what would help if you do have the option of fixing things, while at the same time helping you solve your immediate problem if you don't. Most of us have been in both pairs of shoes."

As this previous posting points out there are people at such an introductory level, that they really don't have a "freaking clue about SQL Server" - I had once compiled a list of my favourite top 10 newbie questions that, in accordance with Murphy's laws, vanished mysteriously a couple of days before I sat down to write this. I did, however, find two others -

1) "Stupid question, but what is books on line?"

2) "...select 1
       from
       dbo.Page_History pgh2
       where
       pgh1.startdate = max(pgh2.startdate)
       and pgh1.starttime = max(pgh2.starttime)
       and pgh1.pageid = pgh2.pageid...
What are the pgh1 and pgh2?  Am I supposed to substitute anything here?"

Are these questions enough cause for launching a diatribe?! Maybe..but it takes courage to ask a question and even more to admit ignorance. These laudable reasons alone should earn them some kindness but if you're not feeling charitable enough, try and recall these quotes to aid you:

Kindness is a language that the deaf can hear and the blind can see - attributed to Mark Twain and another that's less preachy - Courtesy is a small act but it packs a mighty wallop (source unknown).For those who want to get downright colloquial, here's one from one of the SSC members - "Manners, dude. Learn them. Might be helpful one day."

Tact and diplomacy are really not that hard to master and here's a post by Phil Factor that's an exemplary illustration of how you can be one of the SQL greats and yet not look down on the hoi polloi:

"Forgive me for presuming to re-write your routine, but I don't see why you need the table at all. If all you are doing is getting the datetime value of the previous monday then something like this would do the trick:"

Conclusive evidence:

Ulimately, it's all about communication skills as much as it is about manners and etiquette. It's only fitting, therefore, to conclude with this great bit on communications posted by a member, that is presented here in its entirety:

"No matter what language you use; precision of communication is important. Let me give you an example of imprecise communication:

"Mommy where did I come from?" Her six year old asks. She thinks that it is way too early for that particular lecture and is about to tell him to wait when he continues. "Bobby came from Ireland, June came from France, where did I come from?"

Just as it is important to know what the questioner is asking, it is very important to listen and get all the data before you act. If you can not communicate precisely it is impossible to answer the question. No matter what the language."