LinkedIn | FaceBook | Twitter
At some time, all of us need technical help with something. Whenever you do, make sure you try and frame the question not necessarily in terms of what you want to know, but what you're trying to do. Spending time on thinking through your questions will help you get better answers, and people will appreciate that you're putting some effort into the process, and they are more willing to get help.
For instance - let's say yo're stuck on a particular SQL Server Replication issue. You're not sure whether moving the Distributor function away from the Publisher server is the right thing to do, given your budget. You could ask:
"Where should the Distrbutor go in a Replication scheme?"
That's too vague, and doesn't help others help you. Instead, this might be a better way to put the question:
"I'm setting up the design for my Replication scheme, and I have a limited budget. What are the best ways to save money in my design?"
This question goes more towards what you really want to know, and in fact, you may find out that the Distributor question isn't what you need to care about at all. Sure, sometimes you just want the phone number to a store, and you really don't need to tell everyone you're hungry, but if the question goes beyond simple facts, it's a good idea to include as much information as possible so folks can help you best.
And if I may Buck extend what you're espousing further; it ALWAYS helps to include in a request for help, exactly what it is you've already done/tried to solve the problem yourself first.
It blows me away when I peruse the forums and see message after message of the metaphorical "do my work for me." Even with a "please", it's still a "do my work for me." I'm lucky enough to consider myself a part of this amazing SQL community filled with kind souls willing to give you the shirt off their back. But that only goes so far when the OP puts no effort whatsoever into learning for themselves the proper way of doing things. The easy way out is posting the question in the MSDN board where they know Plamen will jump right in with an elegant solution; simply cause he's one of the nicest guys out there.
So, if I may offer a small pearl of wisdom to those out there looking for answers from our SQL colleagues and friends; include what you've tried/read/seen, and you'll stand a much better chance of getting thorough well-thought out responses.