By Steve Van Dyke, Meridian’s Prolog Product Lead

Have you ever experienced performing daily tasks and suddenly something doesn’t work as expected or stopped working altogether? The following troubleshooting tip describes how to take effective steps necessary to identify the problem, narrow the scope, and resolve problems. The information provided is not intended as a solution, but instead used as a guidance map to identify the cause and present resolution.

This tech tip will be covered in two segments. This segment will cover defining the problem, gathering necessary information, and narrowing the scope while next month’s tip will conclude the series with troubleshooting and compiling a hypothesis to presenting steps of resolution.

Problem Definition

1. In one sentence describe the problem
2. Document any Error Messages. Screen shots are helpful.
3. Encompass the problem (All, Several, One)

• Bad Example; Get error when running report
• Good Example; All users receive error “Report File not Found” when clicking Run in Report Manager on all reports within one database.

Gather Information (What are the Symptoms)

1. When did the problem begin?
2. What changed since then? By You? By other users?

   • Are minimum product requirements met according to the Readme?
   • Document the environment and any changes:

   o Operating System
   o Service Patch updates
   o Anti Virus software
   o Network Firewall? Local XP Firewall
   o Network Access Rights
   o Current installed applications/recent updates or install

3. Is the behavior by design? Reference the Help files to determine current functionality.
4. Detail “Steps to Reproduce” It helps to number steps to reproduce with fine detail to avoid assumptions thus delaying the resolution process.

Narrow the Scope (Isolate)
Efforts should first be applied to narrowing the scope of the problem before any attempt to resolve the issue at hand.

1. User Specific? Does this problem occur for one user, several users, or all users
2. Database Specific? Does this problem occur in one database or multiple databases? Can this problem be reproduced in the Sample database?
3. Machine Specific? Does this problem occur on one, several, or all machines?

   • Does the problem occur for another user on this machine?
   • Does the problem occur if Administrator logs on to this machine?
   • Does the problem exist for you on another machine?
   • Are other applications having this problem?
   • Are Pop-Up Blockers enabled?
   • Is the machine caching pages?
   • Recently rebooted?
   • Recent patches/updates?

4. Project Specific? (One, Several, All)
5. Data Entry Form Specific? (One, Several, All)
6. Record Specific? (Last Record, Certain Records, All Records)
7. Network Related? Try removing the network environment variable.

   • Does the same problem occur sitting directly behind the Server or machine presenting the problem?
   • Does installing SQL directly on the problem machine and testing a backup copy of the database resolve?
   • Are the appropriate services running?
   • Are the appropriate protocols being used?
   • Are the appropriate ports open?
   • Can you Ping or Tracert?
   • Can you copy a file from this machine to the network location Prolog is trying to access
   • Were there any recent network or firewall changes?

8. User Rights Relates?

• Prolog Security Rights

o If a new security group is created and user placed in that group does the problem still exist?
o Does the problem exist for Admin?

• NTFS Rights – If logged on as Administrator does the problem exist?

o If user group is granted full access or moved to a user group with full rights does the problem exist?

Be sure to review the conclusion on the Basics of Troubleshooting, Part II next month when we cover troubleshooting and compiling a hypothesis to presenting steps of resolution.

The Basics of Troubleshooting is covered in two segments. Last month’s newsletter covered defining the problem, gathering necessary information, and narrowing the scope. This segment will cover some tips and tricks on troubleshooting and compiling a hypothesis to presenting steps of resolution. The information provided is not intended as a solution, but instead can be used as guidance to identify the cause and determine a resolution.

Troubleshoot & Compile Hypothesis (Do homework based on the narrowed scope)

1. Don’t ignore basics or the obvious (Minimum requirements, Updates, Reboots)
   
2. Identify tools available:

   • Knowledge Base
   • Online Help system
   • Web Search
   • Technical Bulletins
   • Utilities - Some examples include: Event Viewer, Performance Monitor; File Monitors; Registry Monitors; SQL Utilities such as Profiler; and more

3. Exclude Variables – Start basic and keep it simple. Variables can be added or removed as necessary. Some examples include:

   • Network – Remove the network environment and reproduce problem locally. If the problem can not be reproduced locally then the problem may lie    within the network. Connection, user rights, etc.
   • For that license problem can the user copy a simple .doc file from their machine across the network to the Prolog program folder where the license    resides? This helps exclude the network access rights variable.
   • Nomenclature – Restore all defaults (Backup Test Copy Only). If the problem still exits then you know it has nothing to do with nomenclature.
   • User Defined Customizations (Backup Test Copy Only). If you believe the problem lies with User Defined Fields for example and you remove all    UDF’s and the problem still exists then remove the UDF variable from the equation.
   • Database – (Backup Test Copy Only)

   o Delete all records in question. Recreate with steps to reproduce. If problem no longer exists then its data entry. If problem does exist    then other database variables.
   o Restore database locally.

4. Include Variables – It is sometimes necessary to include variables to determine cause. For example, does the problem happen if?

   • Create a separate excel sheet for that import problem. Copy and paste one record, some records, all records. Export one record and import if back.    Is it the export/import process or the excel sheet?
   • Create a new record with basic simple text. No list, lookups, long text, or special characters for example. Does the problem still exist?
   • Create a new user. Reproduce with new user.
   • Run that basic system report first. Then include each variable such as filters.

5. Use a swap technique. Different printer, different user, different excel sheet for importing, swapping configuration files of working user, etc.
   
6. Ladder Effect – For testing purposes only to determine if variables can be removed from the equation or if they are the actual point of focus, start at the top of the ladder and work your way down. Some examples include:

   • Set full network access rights just for testing purposes to validate if the problem is network security.
   • Put user in a new security group for Prolog. If the problem still exists then exclude security as a variable. If the problem no longer exists then you    know your problem is somewhere in security. From here you can begin the process again with the focus on the security variable.
   • Open that firewall for just a short testing period for determination of cause.
   • Remove authentication restrictions from that Mail Server.
   • Disable Virus Software.

7. Perform a comparison analysis

   • If machine specific, compare a working machine to the non working machine regarding installed applications, updates, install files, registry, etc.    There are several utilities useful for this technique such as regmon and ntfilemon.
   • If database specific compare to the sample or other working database such as database properties, size, views, stored procedures, design view    field properties, etc.
   • If user specific compare to a user not experiencing the issue. Compare user rights, profiles, etc.

8. Brainstorm – Write down several things you feel will resolve the problem based on the information you gathered, your narrowed scope, and your performed analysis. Use this sheet as your Game Plan of Action.

Present Steps of Resolution
Using your Game Plan of Action, compile ‘Steps to Resolve’ similar to the format used in this article outlining tasks to perform. Hopefully, you have defined the problem, narrowed the scope, and presented your hypothesis from troubleshooting. The best practice for resolving problems is to perform each task individually and test the results. Make sure to identify the cause for future reference and documentation.

Take a step back – If all troubleshooting performed seems to lack resolution or direction, ask questions.

• Have I forgotten any variables?
• Can I narrow the scope further?
• Am I going in the right direction
• Is there a workaround available for use until the problem is fixed?
• Is there a limitation I am unaware of?
• Is this a known issue?
• Re-evaluate the situation and always ask ‘What happens if?”

Contact HardHat Technologies' Meridian Support Services
If the problem is unresolved HardHat Technologies' Support Services is always here to help. Present the information above by calling one of our expert support analysts.

Phone: 877-418-6300
Email:  This e-mail address is being protected from spam bots, you need JavaScript enabled to view it