All too often, QuickBooks faults with a critical error and the User Interface will shut down; it may display an error number, or only display a message, in some cases it may display nothing at all. How you go about responding to this situation determines if you are really a QuickBooks professional with a thorough database understanding, or if you are simply a robot of habit. And the distinction can make all the difference in salvaging your QuickBooks Database.
So what do you do when QuickBooks closes unexpectedly? If you are like most QuickBooks Users, even many QuickBooks professionals (ProAdvisors and ISPs), your answer to this question is something like: “Well, I usually just double-click on the QuickBooks Icon and try to re-start it!” And therein is the problem.
Indeed our ‘natural tendency’ is to try to restart QuickBooks as quickly as possible to see if it is going to run, to see if it is going to open the database, and possibly to see if we can run the “Verify Utility”. But I am here to tell you that those steps may in fact destroy your QuickBooks data and leave you reliant upon some long ago made back-up. How you respond in the first few minutes after a QuickBooks error can make all the difference, and doing the right things, in the right order, can turn a disaster into a successful recovery.
Allow me to digress; I live in Tornado Alley, in fact in what could be called the Tornado Capital, (Moore, Oklahoma) of the world. Moore is noted for multiple F5 tornadoes within a ten-year time span, including one in which the “fastest wind speeds ever measured on the face of the planet”, destroyed about 25% of our small city. Buildings were literally wiped off the landscape, cars were tossed as far away as 2 miles from where they were ‘picked-up’ by the giant multi-vortex funnel, and the only people who survived were those fortunate enough to either get out of the way, or ride the twisters out in underground shelters. Just this past spring another F5 twister destroyed about 40% of our community.
In the immediate aftermath of these storms, live electrical wires and natural gas were immanent hazards to the surviving population. One electrical spark, one careless smoker, could have turned our community into an incendiary of splintered homes, ruptured vehicle gas tanks and broken gas meter ‘flame throwers’. Fortunately one of the critical responses was proper scene assessment by local emergency personnel who not only performed ‘triage’ of the situation, but also began the process of eliminating the immediate threats.
About now you are asking, “Where is Murph going with all this talk of tornadoes and disasters?” Well the reality is that for QuickBooks users, an unexpected shut down can be a database disaster, a techno-tornado of sorts, and the initial assessment you make and steps you take to eliminate the threats to your QuickBooks Company-file should be your first ‘critical mission’, in lieu of simply trying to re-start QuickBooks.
Unfortunately most QuickBooks users, and even QuickBooks professionals, believe that the primary tools for assessing the health of their data exist within the application in the form of the Verify and/or Rebuild utilities. While these are indeed two of the tools we may make use of, at the appropriate time, the major source of useful information from which we can make a diagnosis is found in the various log files that are companions to our QuickBooks data and application.
But even a review of the various log files, prior to restarting QuickBooks, is still not the appropriate beginning point for post-disaster recovery. You see, before starting any ‘assessment of a scene’ the initial step is always ‘securing the scene’. Before the CSI (crime scene investigators) are called in, out comes the ‘yellow-and-black crime scene tape’ to insure that the scene is secure and ready for assessment free of potential contamination. Similar principles should be followed in the case of QuickBooks failures.
To make this point I again digress, this time to one of my favorite movies, the Clint Eastwood Directed film version of John Berendt’s novel, Midnight in the Garden of Good and Evil about the true-life circumstances surrounding the murder trial of Savannah Georgia’s Jim Williams. During Williams’ trial one of the key witnesses against him was the Savannah Police Detective responsible for investigating the case. While cross-examining the Detective, Williams’ attorney commented, “I'll tell you what's ridiculous. You saying that the scene of the crime was secured. That’s what’s ridiculous. Seven, no eight people, and a pussycat, walking around the room… You call that secure?”
I can’t count how many times I have failed to secure the ‘crime scene’ when QuickBooks shuts down unexpectedly. Rather than taking the appropriate steps, I simply forget to put up the ‘yellow-and-black Do Not Enter’ crime scene tape (so to speak) and simply dive headstrong into diagnosis. Of course the result is that I may very well contaminate my data crime scene, just as ridiculously as allowing “a pussycat” to crawl about at a murder site.
If other users are still in the Company file they should immediately attempt to log-out normally. Then turn-off all 3rd party applications that may attempt to connect to the database, this should include QuickBooks Sync-Manager, QuickBooks Web Connector and Intuit Data Protect, as well as any SDK linked software. In other words get that crime scene tape up as quickly as possible.
Now preserve a Windows-copy of the entire directory of the QuickBooks file that was open at the time of the failure, and also make a copy of all of the QuickBooks related log files. These constitute your best ‘forensic evidence’ of the problem to investigate.
Hopefully now you can start to see where I am going with this. QuickBooks Professionals must learn to treat an unexpected QuickBooks shutdown in exactly the same way that a police detective treats a crime scene; we must not let anyone, including ourselves, contaminate the situation. Any actions taken by anyone, that modify the database, including attempting to open it, can result in additional data loss and can complicate our ability to determine the cause, and possibly repair any data corruption.
In future Techno Topic and Data Detective articles we will look at examining the evidence on hand.