How to post a good question - The Do's and Don'ts for everyone at UtterAccess.com
Welcome to UtterAccess.com, the Internet's
fastest growing Microsoft® Access community! We would like
to make your visit to "UA" an informative and
To help you and others find the solution to
problems more effectively, please take a moment to read the
"Do's and Don'ts" for the UA site. These recommendations
are based on experience and are intended to be helpful guidelines.
Please Do Not:
- Consult the standard resources before posting. Run a search through
the forum and archives, or try your Access Help file (F1).
- Ask one question at a time and give
it a meaningful subject line that will fit in the space available.
This allows members to answer topics within their knowledge
and all of us to find answers in the archives or through the
- Post in the correct forum. You can
find descriptions of the forums on the
main index page, or if you see a "Please Read" post
at the top of a forum, take a moment to read it for the forum
- Take some time to get used to the forum
layout - don't worry if you make a mistake. You can view your
post and choose the edit option. Delete the post and repost
it in the correct forum.
- Provide sufficient detail: your version
of Access if you are not posting in that version's forum, your
objective, what you have tried and what is actually happening.
Include any error messages and error numbers you receive.
- Try to describe a complex situation
clearly by using your form, control, table and field names.
Writing vaguely is of little help and your object naming may
be part of the problem. If getting to this level, it is useful
to mention the data types (i.e.: text, integer, date/time) of
- If you are asking about data or design
issues, describe your existing tables or the data that you want
to store. Provide a sample of non critical data when possible.
- If your question is specifically about
queries or coding, and you have made a start, then post the
SQL string or code segment. It is difficult to debug what cannot
- When asking about a query or report,
describing your objective may be difficult. If you provide a
few rows of non critical data plus the results you wish to obtain,
this will help others understand your problem.
- If you are having trouble running a
query from Visual Basic code, provide the result of a debug
statement as well as the code. Raw code that composes SQL can
be very difficult to read. Comparing the results versus your
code may help you or someone else solve the problem.
- Be polite. If you are having trouble
understanding another member's question, ask them to clarify
it for you. English is not everyone's native language so they
may have just as much trouble understanding what you are requesting
- Make an attempt to answer others' questions.
It is a great way for you to learn and if you make an error
you will be treated kindly. Remember that a Guru is just somebody
who started making mistakes before you did.
- Try to reply to a question at a level
that will be understood. If someone says they are a beginner,
do not overwhelm them with code only an experienced developer
would understand. Better yet, explain to them what it is you
are doing and why.
- Compact and Zip
any attached files. You can attach a file with your post when
you have checked the, "I want to preview my post and/or
attach a file" check box.
- Thank people who are particularly helpful
- but privately.
- When attaching a database, be specific about what report/form/table/query etc is creating the problem, and what steps are necessary to recreate the problem.
- Remove all startup properties, forms, macros, etcetera, from attached databases.
- Expect members to write your application
for you. If you are given only hints or general directions don't
take it personally. You should show that you are making an effort
yourself. This especially applies to homework assignments -
outlawed at many sites.
- Send Private Messages, direct emails
or unsolicited database files to other members, moderators or
administrators related to questions concerning Access unless
they have requested you to do so.
- Post questions in Archive forums (Access
Code Archives, Access FAQA's and ASP-VBScript Code Archive).
These forums are for code examples only, or for answers to
frequently asked questions.
- Complain that Access does not work
the way that you wish. Each version of Access has its own limitations.
Microsoft has tried to add more functionality in each new version
they have released, but this requires the user to spend some
time learning the additional fundamentals. Try to find a workaround
solution, and share that solution for others who may have run
into the same limitation.
- Make rash statements regarding the
limitations of Access unless you are prepared to prove your
observation. A better reply might be: I am not sure this can
be done in Access. List why you think it can't be done.
- Reply to a serious post jokingly -
this may confuse the person who asked the question or others
viewing it. UtterAccess is viewed in over 100 countries and
although displayed in English as a default, may be a very foreign
language to many members.
Special thanks to Roger Carlson and all the other's who prepared these wonderful
tips, and to you for taking the time to read and apply them!