Welcome to UtterAccess.com, the Internet's fastest growing Microsoft® Access community! We would like to make your visit to "UA" an informative and positive experience.

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.

• 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 search engine.
• 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 specific details.
• 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 important fields.
• 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 be seen.
• 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 of them.
• 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!