NT104: How to Debug

By Bob Gates

February 06, 2009


The purpose of the "Newbie Track" of training videos for Open Web Studio is to get you started moving down the best development path by demonstrating how to use the industry-proven approaches and standards practiced by the Open Web Studio Team, and surrounding community.


The goal of this video, "How to debug" is to get you familiar with debugging in Open Web Studio. Since it can get data from so many sources and perform so many tasks, OWS includes a very robust debugging and logging system.  Each configuration maintains its own set of log events.  Events can be debug messages, comments, or errors in your code.  It's important to understand how to read the debug statements and how best to isolate what's wrong, without wasting too much time. Further, this example introduces the tokens for Database Owner and Object Qualifier and provides a brief introduction to conditional branching.

NT104: Watch and Learn

To get started, lets assume you have already installed Open Web Studio on your target platform.
Additionally, we will assume you already know how to create a configuration from scratch and have assigned that configuration to the module on the current page. In our case, we have begin with the end result of the "NT103" session, renaming the configuration "NT104".

  1. From the page, Jump into the administration for NT104 by clicking the Administration link.
  2. Because we already created this configuration, it is ready to begin editing. We also have taken the liberty of setting up paging, which was demonstrated in the previous session. The module is set to 10 records per page with AJAX paging enabled.
  3. The NT104 configuration starts from the NT103 base, which means it consists of a simple table structure complete with a Header row for the column headings, a detail row and an alternating detail row.
  4. To enable automated debugging for this configuration, open the General tab.
  5. Scroll to the area labeled "Debugging": Automated Debugging occurs for four types of users within the system: All Users, Edit Users (those that have edit rights to the control), Admin Users, and Super Users.  The reason for these differences is simply based on your logic structure. You  may encounter a bug in your script that only occurs for some users in a particular role.  In that case, if debugging is enabled only for Super users, then the debug output won't be tracked.  Additionally, debug tracking can be manually provided within each configuration through the use of the Log Action.
  6. Select the option labeled "Display for All Users"
  7. Press Save
  8. Next, Double Click the Query template. We will now demonstrate the use of two simple  System tokens, the owner of the database, ordinarily dbo and the object qualifier, if one is used on the target database. Add the following tokens to precede the table name:

  9. Press Save then Publish.
  10. Return to the front end and press Refresh
  11. You can See the full output of our module with the header footer and detail areas as expected.
  12. To review the debug, go back to the Administration window. From here, click Tools then View on the Events ribbon group.
  13. You will see two entries in the event log. One identified as AJAX and the other as Page Load.

    In general,  Events are in one of three classifications - PAGE, AJAX or custom messages.  PAGE events occur on page load.  AJAX events occur as the result of an AJAX call to this module.  Custom events are generated via the Log action in your action script.

    In our case the Page Load is called when we load the full page by pressing Refresh. Since AJAX is enabled, all subsequent events, including the use of the paging and sorting capabilities are handled through AJAX requests.
  14. To view the debugging, click on the event labeled AJAX

    Event Detail now contains the primary debugging area for OWS messages.  There are 5 primary sections:

    Actions: Follows the steps of your action script

    Original: The primary query for this configuration BEFORE any tokens are replaced

    Actual: The primary query that was actually used AFTER all tokens are replaced

    Tables: Provides Table level statistics for the values returned from the primary query

    Statistics: Tracks values of the module, Form, Session, Cookies and ViewState
  15. Open the Actions detail
    Each action that has children is collapsible to make it easier to read. Note how each action has its own debugger statements.  Collapse it.
  16. Open the Original detail
    Note that the query is exactly as we typed it
  17. Open the Actual detail
    In this view the tokens are replaced with their specific values and displayed.  Notice that the Database Owner and object qualifier have been replaced.
  18. Open the Tables Section
    The number of records provided, corresponding column count as well as the name and data type of each column is provided.
  19. Open the Statistics detail
    This lists some of the core values associated with this instance.  Since configurations can be loaded on any OWS module, this is really useful in tracking down troublesome instances.  This also comes in handy when dealing with form data entry, session values and other runtime parameters.
  20. Now we want to provide a true reason to debug, we will do this by altering the configurations template query again, this time with the certainty that it will be incorrect.
  21. Double Click the Query template and set the Content to select from the lists table, only leave the trailing s from the table name
  22. Press Save then Publish
  23. You can see that we are now not returning any data. To see the debugging, return to the administration window.
  24. From here, click Tools then View on the Events ribbon group.
  25. Click on the most recent AJAX entry and notice the error section which has been added.
  26. Expanding the error yields the full exception as it was relayed from the database server down to DotNet. You can refer to the Original and Actual queries to review the issue and determine a resolution.
  27. Return to the configuration, adding the s back to the table name.
  28. With that complete, let's create a Log Action and to demonstrate the ability to provide manual logging.
  29. For this example we want to log an entry in the database whenever the URL contains a parameter named Debug which has a value of ONE within the querystring.
  30. The Conditional Branching provides the ability to deal with any type of if/then logic. Click IF from the Action Ribbon and then double click to edit the action. In this case we simply want to record a log Action whenever the URL contains the querystring parameter: Debug = 1. To do this, set the Left side to:

    And the Right side to
  31. Now, Save this condition. Make sure it is selected in the action tree and press the Log Action.
  32. Double click the Log Action and enter a Name and Description of the log entry.
  33. Press Save, then Publish to see this capability.
  34. Return to the front end and now refresh. At this point Debug is not in our Querystring.
  35. Place Debug=1 in the querystring.
  36. Now, return to the Admin and click on tools, Event View.
  37. Notice the log entry as you expected.

This completes the demonstration, but there are a few things left to point out. First, the Debug output sections as they appear in this simple example are provided at each level of the action tree whenever a query or subquery is executed. This way you can track  debugging throughout the entire tree logic.  Secondly, we have not yet introduced Regions to you. These actions, meant to provide a bit of structure to your configurations also provide the ability to enable or disable debugging through all children of that action. And Third, a reminder that if you enable Debugging for All users, you should remember that this is continuously running and recording each interaction. You should disable this when you are completed testing as the event log can grow to be quite large otherwise.

You should now have a decent understanding of Debug your configurations, and how tracking of your debug logic can continue easily with or without your tentative involvement. Additionally you have been introduced to the DatabaseOwner and ObjectQualifier tokens. Finally you have begun using conditional branching within your configurations and can continue further down this path.
Each tutorial within the Newbie Track series will provide the same simplistic approach to using Open Web Studio. To find out more, just watch the next video in the series.

Average (2 Ratings):
Want to help out?

New York, NY • Baltimore, MD • Vienna, VA • St. Louis, MO • Seattle, WA • info@openwebstudio.com

Bookmark & Share Bookmark and Share