How to get your questions answered promptly

[Banana]

Note: This is condensed version for the benefit of the board. For much more detailed info, read here.

Steps to take BEFORE you post anything

1. Debug the problem. Don't forget to verify the spelling and referencing! (See below for tips)
2. Get all information about the error. See the next list to see what you need to know before posting.
3. Consult Access Help files. This is very important, especially in discovering correct keywords and terminology that will make your search easier.
4. Search Google.
5. Search Usenets. (You can use Google Groups for that; search Groups separately from the Google engine, though)
6. Search the Board.
7. If you are still stuck, go ahead and post.

What to post

1. Version of Access
2. Error Number and message, if included.
3. A concise description of the problem.
4. The desired solution.
5. Steps you've already taken to fix the problems. May be helpful to mention how you searched the web, and what keywords you used.
6. Post the relevant code, highlighting the offending line where error is risen. If the error is not from VBA, but from Access (e.g. you get a pop up error message), be sure to specify exactly what steps you took to rise the error. If this is a bad query, it may be helpful to show the recordset and tell what recordset you want to see.

Debugging Tips

List of Contents:

1. How to debug VBA code
   • To step through the code
   • To inspect the variables within the code
   • While stepping through the code, you can...
2. How to debug queries and/or functions on the forms within Query Builder
   • For queries or controls on form, use "Build..." whenever possible!
   • Always check the queries by clicking on View.
   • For bad queries...
3. Use Access Help to get the right keywords for your search

How to debug VBA code

• To step through the code
  
  In Visual Basic Editor (VBE), go to the relevant snippet's heading (e.g. the line starting with Private Sub or Private Function or similar), and click on the gray margin to left of the window to activate a breakpoint. If this is in a module, you can execute this by pressing the "play" button. If this is for a form, you need to switch the form from "Design View" to "Form View" and attempt to fire the event (e.g. editing a value on the form or make a bogus record).
  
  When the event fires, you will be immediately taken to VBE and the line at the breakpoint you just created will be highlighted. You now can then step through the code line by line by pressing F8. Alternatively, you can execute the code normally by pressing F5. If you never ever see the VBE, it means that event didn't fire at all.
  
  
• To inspect the variables within the code
  
  You can mouse over the variables to see what values are as you move through the code. This is very helpful in checking whether variables are behaving as expected.
  
  Alternatively, you can add a line in your code:
  

  Debug.Print MyVariableName

  . This is useful for some situations where you cannot step through the code and get same results (e.g. VBE will choke on any acRunCommand if you try to step through those lines). In this case, the values stored in the variables get printed out to the Immediate Windows. This is the tiny windows to the bottom of the code windows.
  
  
• While stepping through the code, you can...
  
  Use the immediate windows to get more information that is not available from mouseover. You can do so by issuing the command in the immediate windows:
  

  ?MyVariableName

  Which will then print your variable's value. You also can execute another code not otherwise included in your routines. For example, you can type:
  

  MyVariableName=SomeValue

  And your variable will be changed accordingly. This is useful in identifying problems that are intermittent due to bad values but does not show up if it has good values.
  
  This is also useful for seeing variables or data that isn't within the scope of the routine, as well.

How to debug queries and/or functions on the forms within Query Builder

• For queries or controls on form, use "Build..." whenever possible!
  
  A common problem that arise is referencing the forms/subform controls and using function correctly. Instead of trial and error, you can use Build... to give you the correct references. For example, suppose you want to set a query's criteria to a textbox in a subform. You would right click on the Criteria field in Query Builder and select "Build..." which you will then get the Expression Helper. You would then navigate to "Loaded Forms" -> "MainFormName" -> "SubformName" -> "ControlName" then double click the control's name and it will give you the full reference without any hassle or errors.
  
  This is also useful in helping building functions within the query. Experiment with it a bit to see how it work would be much more productive than me trying to describe it.
  
  
• Always check the queries by clicking on View.
  
  This is very useful in ensuring that you are getting the expected resultset. Even though you may have made 100s of similar queries before, you can never know if the query will behave the same with different data or database. This also can tell you what to post any problems that may not be as self-evident if the query is for a control on the form.
  
  
• For bad queries...
  
  If you're getting errors that seems entirely random or unrelated to what you are encountering in QBE, it usually helps to start by deleting one column at a time, executing the query and see if it raises the same error, and if so, repeat the process until error no longer raises, then you know that the problem was with the previous column you just removed from the query.
  
  Alternatively, you can start out with a simple query, then add one column or criteria or function at a time to ensure that everything is correct.

Use Access Help to get the right keywords for your search

A recurring problem with searching is that if you do not have the right keyword, searching anywhere, be it on Google, Usenet, or the board is basically going to be a hunt for a needle in a haystack.

The first step in finding what you should be looking for is to consult the Access Help and the Properties Windows. By starting with what you already know (for example, you want to do something with AfterUpdate event), you can read the help on AfterUpdate, which it may link to other terms that are associated with the event and provide you with the correct keywords to use for searching.




I hope this has been helpful.