How to get your questions answered promptly (1 Viewer)

Banana

split with a cherry atop.
Local time
Yesterday, 19:11
Joined
Sep 1, 2005
Messages
6,318
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, preferably using a old thread most relevant or similar to your problem.

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...
    • Set VBE's behavior with error for debugging handled errors
  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. To make an effective search...
    • Use Access Help to get the right keywords for your search
    • State explicitly if you do not know the correct terms


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:
    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:
    Code:
    ?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:
    Code:
    MyVariableName=SomeValue
    Err.Raise 11
    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.

  • Set VBE's behavior with error for debugging handled errors

    If you go to Tools -> Options and click on "General" tab, you can see three options for specifying how you want VBE to behave with errors:
    • Break on all errors
    • Break in Class Module
    • Break on Unhandled Errors

    The default is, of course, the third option. When you have a problem with a routine that has already error handler but need to get more information, especially as identifying exactly where error trips or troubleshooting a faulty error handling, you will want to select the first option.


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.

To make an effective search...
  • 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.

  • State explicitly if you do not know the correct terms

    In case you are unable to find the correct keywords, be explicit in stating that you are uncertain. This will help other know that what you may describe is not what they may think using the usual terms and make sure to supply you with the correct keywords to help along with the solving of problem.


If you have any suggestions or feedbacks, feel free to post and I can edit the post. I hope this has been helpful.
 
Last edited:

boblarson

Smeghead
Local time
Yesterday, 19:11
Joined
Jan 12, 2001
Messages
32,059
Great Work!

I like it and have posted this as a "Sticky" in the FAQs section. Normally we would remove duplicate posts (because I copied it to the FAQs it is now a duplicate) but the FAQ area isn't for posting questions or comments and so we'll leave this post here for that to occur.

Banana - you can contact me directly, via PM, if you need to modify the post in the FAQ section. Also, you get good rep points for this one!
 

Banana

split with a cherry atop.
Local time
Yesterday, 19:11
Joined
Sep 1, 2005
Messages
6,318
boblarson- Glad you liked it.

I forgot to mention this before, but I would imagine that if other posters add this FAQ to their signature, it will be helpful in getting new members to read it. They may not get it the first time, but after a couple time of seeing the same link in the signature by various members they may get the idea that it is very important... Just an idea.
 

Banana

split with a cherry atop.
Local time
Yesterday, 19:11
Joined
Sep 1, 2005
Messages
6,318
Edited and added a bit more (about debugging handled errors and keywords).

Of course, any feedbacks are always welcome.

Also, to help direct new people to this FAQ, it may help to add the link of this FAQ to your signature.
 

Users who are viewing this thread

Top Bottom