By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,300 Members | 1,795 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,300 IT Pros & Developers. It's quick & easy.

How to ask "good" questions -- READ BEFORE SUBMITTING A QUESTION!

NeoPa
Expert Mod 15k+
P: 31,494
Remember that the people here helping you are not getting paid. They have no real incentive to help you beyond the desire to help others generally. So, if you make it difficult for them to help, there is a good chance they will just skip your thread and go on to the next one.

So, how do you ask a good question? There are a few rules:
  • Clarity -- Possibly the most important. Explain your problem clearly, without rambling about unrelated details. Proper language greatly improves your clarity. We all understand that English is not everyone's first language, but you can do better than "pls cn u send me teh codes?"
  • Brevity -- "Brevity is the soul of wit." We don't need to see your entire 800 line source code when the problem is with one small method. Also, we don't need a super-wordy question.
  • Technical Details -- There must be a balance between brevity and details. Be as brief as possible while providing us enough details to help solve your issues. Here are a few details that are almost always import:
    • Compiler errors! Just saying "I get an error" or "My error is nnnn" is never good enough. The VBA Integrated Development Environment (IDE or debugger window) enables you to see the full error message as well as highlighting the line responsible for it. We certainly need that info. Post it!
    • Runtime errors! Same thing, we can't help you if you don't provide the information.
    • The version of Access you're using. This is a simple thing to mention at the beginning of your post, but can save us some time in helping you, as some things have changed significantly over recent releases.
    Beyond these, use your judgment. If you feel like we should know something, include it. Just try not to bog us down with unnecessary extraneous code. We probably aren't going to take the time to read your entire source file if it's huge. It's your job to identify the error in your question.
  • Formatting -- This forum has several text formatting options to make reading things easier. Ordered/unordered lists, indention, hyperlinking, embedding images, and most importantly, the [CODE] tags. Always enclose your source code in [CODE][/CODE] tags, because it preserves whitespace and adds line numbers.

So now that you know what to do, what shouldn't you do?

DON'T:
  • Ask basic introductory questions -- "How do I define a subroutine ??" -- We're here to help, but we can't teach you the language all by ourselves. There are other resources out there for that.
  • Ask new questions in an existing thread -- This is generally known as hijacking and is never welcome. This even includes follow-on questions in your own threads (Those started by you). If an existing thread is about what you need help with then feel free to include a link to that thread in your own new question thread.
  • Ask questions that are easily answered by a search engine -- "What variable types are available in VBA?" -- The information on a large percentage of questions asked is already available on the web. Forums often take days, and almost always take at least hours. Google takes seconds. I would recommend googling your error message before coming to us. You may find your answer quicker than you thought.
  • Ask questions with a huge scope -- "How do I write an accountancy package?" -- We can help you with specific issues, but we can't give you a college course on a topic. Think about whether what you are asking can be solved/explained in a few paragraphs. If it can't, you're probably asking too much.
  • Ask for someone to do your "homework"/"assignment" -- "Can someone send me the codes to link my customers with their orders?" -- We can't do your homework for you. It's dishonest and will give us a reputation as a cheating site. We may be able to help you solve specific issues with your homework questions, but we cannot do it for you. For the record, homework doesn't only mean coursework. We won't write the application for your company on your behalf either.
  • PM technical questions to other members - experts or otherwise -- Private Messaging is not where people expect to find technical questions. These should be found only in the relevant technical forums. Members quite rightly expect their Private Messages to be devoid of requests better handled in the forums. This behaviour is considered to be harrassment and is not tolerated.
  • Break the Posting Guidelines -- These are not difficult rules to follow. Please briefly read them over before you post your question. You may be doing something wrong without realizing it.

Again, remember that the people helping you are unpaid and uncompensated. They just like helping people. If you make it hard for them to help, they might just skip your question and move on to the next one.
Nov 5 '10 #1
Share this Question
Share on Google+
1 Reply


NeoPa
Expert Mod 15k+
P: 31,494
(More important advice copied in from Before Posting (VBA or SQL) Code).

Before posting any code on here please :
  1. For VBA code specifically :
    1. Ensure you have Option Explicit set (See Require Variable Declaration).
    2. Try to compile it. If it doesn't compile for any reason then fix it before posting. If you cannot manage that for any reason, then please explain that clearly - including the error message and which line of your code it appears on.
      1. Compilation is done from the Visual Basic Editor menu - Debug \ Compile Project (Where Project is the actual name of your project).
      2. Determining the line number depends on selecting the Debug option when the error is displayed, and that depends on setting the VBA IDE options correctly (See Debugging in VBA - 3) General Tips for more on that.) in order to allow the code to break. The line the error occurred on wil be the currently selected line and will typically be highlighted in Yellow.
  2. For SQL as well as VBA :
    1. Copy your code (using the Clipboard - Cut / Copy / Paste) from your project directly into your post. Typing in code is not appreciated as it is likely to introduce typos which cause members to waste their time unnecessarily.
    2. Ensure that the code in your post is enveloped within CODE tags. The [CODE/] button in the posting page helps with this. Simply select your code and click on the [CODE/] button to have it enveloped automatically (See [code] Tags Must be Used).
  3. For SQL specifically :
    1. If your problem is a SQL one, but you are developing your SQL using VBA code, then please post the actual SQL you intend to execute. So many people seem to need telling how intelligent it isn't to post just the VBA and hope that the experts can guess sensibly what values your code is working with. Also, it's disrespectful to our experts to expect them to work out what your question should be for you. The member asking the question has the responsibility to provide all relevant information for a question, and if you want help with executing some SQL, then the SQL string itself is pretty obviously relevant information in that situation (See How to Debug SQL String).
    2. This one can be ignored for those with a beginner's understanding of SQL and how it works, as well as for very short and simple SQL strings :

      SQL is like C-based languages in that white space is used as a separator. This includes new lines etc. What this means for working with other people on a forum is that the fundamental SQL doesn't change if you organise it to display in such a way that it is visible and clear by arranging similar items below each other for instance.

      Access will produce SQL for a QueryDef with, quite understandably, very little thought given to readability. Experts on site are likely to be happier though, if instead of displaying the SQL exactly as Access does, the member formats it so that it's easier to read. I include an example here to illustrate :
      Expand|Select|Wrap|Line Numbers
      1. SELECT Table1.Field1, Table1.Field2, Table1.Field3, Table1.Field4, Table1.Field5, Table2.Field1, Table2.Field2, Table2.Field3, Table2.Field4, Table2.Field5
      2. FROM Table1 LEFT JOIN Table2 ON Table1.Field1 = Table2.Field1 AND Table1.Field2 = Table2.Field2 AND Table1.Field3 = Table2.Field3
      3. ORDER BY Table1.Field1, Table1.Field2, Table1.Field3
      This could as easily be written as :
      Expand|Select|Wrap|Line Numbers
      1. SELECT   Table1.Field1
      2.        , Table1.Field2
      3.        , Table1.Field3
      4.        , Table1.Field4
      5.        , Table1.Field5
      6.        , Table2.Field1
      7.        , Table2.Field2
      8.        , Table2.Field3
      9.        , Table2.Field4
      10.        , Table2.Field5
      11. FROM     Table1
      12.          LEFT JOIN
      13.          Table2
      14.   ON     Table1.Field1 = Table2.Field1
      15.  AND     Table1.Field2 = Table2.Field2
      16.  AND     Table1.Field3 = Table2.Field3
      17. ORDER BY Table1.Field1
      18.        , Table1.Field2
      19.        , Table1.Field3
      As this is fundamentally clearer, as well as requiring less scrolling on the part of the reader, it is much easier to work with (and frankly, it will also help you to understand the SQL better). It needn't be exactly that format, but anything ordered and more easily visible on a narrow page is a help.
If all these points are covered then all members will be better able to understand, and therefore attempt to answer, your question.
May 8 '16 #2

This discussion thread is closed

Replies have been disabled for this discussion.