Forward this tip to a friend

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)
  • 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.
  • 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 Meridian Support Services
If the problem is unresolved Meridian Support Services is always here to help. Present the information above by calling one of our expert support analysts.

Phone: 800-565-9490, Fax: 916-294-2299
Email:  support@meridiansystems.com

To Top ▲