Showing results for 
Search instead for 
Do you mean 

“Does it happen in the Eval database?” and why is that important?

by on ‎05-14-2010 11:31 AM

In my last Blog I talked about the “Divide and Conquer” method of troubleshooting, and I made mention of trying a failing operation in the Evaluation Database.  When the Customer Support Analysts ask if the same failure occurs in the Eval database, the answer is often, “Why should it matter if it occurs in the eval database? It’s happening on my production database and that’s the problem that we’re talking about.”


In most cases, it is actually vitally important to determine if the same operation produces the same or similar results when using the Evaluation Database.  Because hardly anyone uses SalesLogix as it arrives out of the box with nothing customized, this should be one of the first steps in determining where to start (or stop) looking for the root cause of the issue.  When you perform a specific operation and the resulting behavior differs from the expected behavior, you need to find out if that behavior is being caused by something in the SalesLogix application, or if it’s being caused by data or a customization that has been made to your SalesLogix system.  Whenever possible, try the same exact operation on the Eval database.  If the behavior is the same when using the Eval database, you have now narrowed the issue down to two probable conclusions: There’s a flaw (defect) in the SalesLogix application, or the application was designed to function in that manner.  I spoke about ""Defect, Feature Request, or “Functioning as Designed” in a previous blog.


If you can’t perform the same exact operation on the Eval database because it’s part of a customized add-on, the next course of action could be to apply that customization to the Eval database and test the operation.  That can tell you if the issue is due to data or not.  If the unwanted behavior does occur on the Eval with the customization applied, chances are high that there’s a problem with how the custom piece was constructed or applied.  If the Eval still behaves correctly, there’s a probability that the data in the Production database could be causing the issue.  In either case, you will have begun the process of Divide and Conquer to help you find the root cause of the issue.


Try testing the Eval database the next time you encounter an issue, and let your Support Analyst know that you’ve done so.  If you haven’t, don’t be surprised when your Analyst asks you to since that’s almost always one of our first steps.

Register Read Guidelines Request Partner or Employee Access

What's New in 8.1