The Importance of Reporting Errors

Back in January 2009, I wrote an article: The Importance of Reporting the first Error, which talked about why it is important to report errors, but especially the first error.

After dealing with a number of recent support cases where it came to light during the course of the support case that there had been errors in the past that were not reported, I wanted to cover the subject again.

So, I will stand on my soapbox again (you know I need the height) and explain why this is SO IMPORTANT:

• Whenever Microsoft Dynamics GP or its underlying language, Dexterity, reports an Unhandled Exception error or crashes with an application error, it means that the code that was in the process of being run stopped executing.
   
• As we don't know exactly how far the code has progressed before it stopped, we do not know what changes to the data have been made already.
   
• As we don't know what code was not executed because the Unhandled Exception or crash stopped the processing, we do not know what changes to the data have not been made.
   
• As the data is now in an UNKNOWN STATE, and could have inconsistencies, orphaned records, partially posted transactions or any other number of issues, it is very likely that the system will start generating subsequent errors or have data issues.
   
• All subsequent errors, while important, are usually a result or consequence of the very first error that occurred.
   
• The support team and system administrators need as much information about the first error AND all subsequent errors to be able to help.
   
• It is imperative that users take screenshots of errors and make notes of what they were doing, including noting the transaction or master records they were working on.
   
• It is imperative that users click on more information or details buttons to obtain as much information as possible.
   
• It is imperative that users report the errors to their system administrator or support team, so appropriate action can be taken as soon as possible.
   
• It is imperative that the reporting of the errors happens immediately as the best solution might be to restore the last backup and the more time that elapses, the more data that will need to be re-entered.
   
• Finally, System Administrators need to make sure their backups are made regularly AND that they have verified them by restoring them to a test system and making sure they work.

 

While exceptions are not an everyday occurrence, when I hear about users just clicking OK without noting any details and continuing as though nothing has happened it makes me cringe...

Please note that if these steps are followed, we have a much better chance of identifying the root cause of the issue and so log a problem report to get the issue fixed. Also this gives us the chance to fix or restore the data earlier rather than later.

I can get off my soap box now. 

David

Comments

• Anonymous
  November 18, 2012
  Thank you for touching on a subject that is not discussed much. This is applicable for any software application.

• Anonymous
  November 19, 2012
  It is also imperative that users participate in the Customer Experience Improvement Program (CEIP) to forward those exceptions to Microsoft. Many times errors are not even application related, but possibly an underlying issue with the operating system. Many times when submitting error reports to Microsoft, you will find it surprising that there's already a fix for the problem. I also recommend system administrators to use the traditional maintenance routines (Check Links and Reconcile) to identify potential issues and fix potential damages prior to resorting to SQL scripting. While Check Links has a habit of removing records without warning, it does a very good job at letting you know what it removed: PRINT THE REPORTS!! MG.- Mariano Gomez, MVP

• Anonymous
  November 20, 2012
  @Mariano: Support normally suggest only running Check Links when fixing specific issues. Regardless, make sure you have a backup in case it removes records that are valid. I have seen it remove records from 3rd party products as they did not appear as valid records to the Check Links code.

• Anonymous
  November 20, 2012
  Posting from Mark Polino from DynamicAccounting.net msdynamicsgp.blogspot.com/.../the-importance-of-reporting-errors.html