Here’s a good example of why I always tell people to not install a “manual update”, instead you should wait for the “automatic update”. QuickBooks 2013 R7 was just released yesterday, and already we have found a bug that could cause some problems for people. Fortunately, there is a fix available that solves the problem.
Update 7/1/2013: Please note that R7 has multiple errors – and that Intuit has released the R8 update to fix those. See this article: https://www.accountexnetwork.com/blog/2013/07/quickbooks-2013-r8-released/
Manual vs. Automatic Updates
When a new version of QuickBooks is released, it comes out as a “manual” update first. That is, you have to go to the Intuit QuickBooks Support update page and click on the “update” button to download a patch file that you can use to update your installation. About a week later, usually, Intuit will then enable the “automatic” update process, where the patch will be pushed out to any QuickBooks installation that has automatic updates enabled. Sometimes they don’t wait a week, and the automatic update comes out a the same time as the manual update.
Personally, as a ProAdvisor, I always turn off “automatic updates” for my clients. I’ll tell them when it is OK to install an update. People might not always agree with me, but I have several good reasons:
- Automatic updates can be disruptive: Someone sees the notice that an update is available, and they just go ahead and install it. Unfortunately, sometimes this creates problems. The update may take time, and so the workstation is out of service.
- Program updates sometimes require a file conversion, which sometimes (not always) means that OTHER users cannot use the file until THEY install the update on their workstation. What if someone starts this process just before some critical process, like processing payroll? I prefer to do these updates in a controlled situation, when I know that it won’t disrupt the client’s workflow.
- Updates sometimes change the workflow or require some manual fix: A feature may work differently, or there may be a manual data fix that is required. This isn’t normal for an update, but it can happen. I want everyone to know what the changes are in case there is a database correction that we have to deal with. Intuit does NOT do a good job of telling us what the changes are in an update.
- Update releases sometimes introduce new bugs: This is the MAIN reason why I don’t like manual updates – sometimes the update creates a new problem, so I don’t want to rush out and install the update right away. I want OTHER people to be the guinea pigs (or, perhaps I should say “be the field testers”). The week (usually) between a manual update and an automatic update is the period when we see if the update creates new problems.
The 2013 R7 Bug
So, QuickBooks 2013 R7 was released on Tuesday (actually, very late on Monday evening, but probably nobody downloaded it then), and by mid afternoon on Tuesday we have our first report of a serious bug.
This relates to add-on products, any QuickBooks compatible software that uses either the QuickBooks SDK or IPP interfaces. That is, just about ANYTHING written by a third party developer that works with the Windows desktop version of QuickBooks. If that application tries to perform one of the following transactions, QuickBooks will immediately crash:
- Request a copy of the Item List
- Add an Employee
- Update an Employee
- Add a “special item”
In my test (with my own add-on software), as soon as the program asked for the item list QuickBooks would display an “unrecoverable error” window with error 00000 37760.
Once you close this window QuickBooks will usually (but not always) terminate. In many cases your add-on product either freezes or loses connection with the QuickBooks database.
Note that for IPP applications, the app won’t freeze or see the problem, because they don’t work directly with the QuickBooks desktop database. The problem here will be the Sync Manager utility, which should cause problems when it tries to work with the desktop file. I have not tested this aspect of the problem – I have only tested this with SDK based applications.
There is a Fix!
Fortunately, the technical staff at Intuit created a fix for this VERY quickly. I have to say that I’m very impressed with how quickly they responded, helping me with this late into the evening on Tuesday.
There is a small program file that has to be replaced, once this is done the problem goes away. Simple to do if you are reasonably familiar with Microsoft Windows, not too complicated if you aren’t.
I’m not going to post the patched file here – if you run into this problem you should contact your add-on software developer and ask their assistance. If they aren’t aware of the problem, have them contact me directly and I can point them to the patch in the Intuit developer forums.
Please note that at the time that I’m writing this Intuit hasn’t announced how they are going to deal with this issue (other than posting the fix in the developer forum). I see four options, and I don’t know which they’ll implement:
- Ignore the issue and let add-on developers handle it (I doubt that they’ll use this option).
- Fix the manual update (but some people already have it, so that leaves some with the problem).
- Just fix the automatic update (bigger problem, for those who do manual updates).
- Use their new critical fix mechanism to push out the fix (I don’t know if that process works with this kind of update).
Note Added after initial publication: It looks like Intuit will be using the “critical fix” mechanism to push out this correction. However, I don’t have details on how that will work or what revision number we will see for this. In my opinion, this is probably the best way that Intuit could deal with this, and it is exactly the kind of situation that the “critical fix” mechanism was set up to handle.