Horrific QuickBooks Desktop File Errors

by

Lately I have seen some horrific QuickBooks Desktop files in terms of major errors which are preventing files from converting to QuickBooks 2018, verifying, backing-up, and even rebuilding.  I think a lot of people using Desktop have chosen to wait until the last 60-days to upgrade their copies of QuickBooks from 2015 to 2018.  Some are upgrading from 2016, and others from 2017.  Many of these I don’t understand since they were QuickBooks Enterprise clients who were on the FSP support plan, or annual subscriptions, and were long since eligible to stay current in terms of their product versions.

The one good thing about all these horrific files is that they have provided several new examples of major file corruptions which I will be sharing in my QuickBooks Desktop Super Geek 201 course at Scaling New Heights 2018.

Regardless of the learning experience these files provide, there have been some real messes sent to me for data-file work.  In one case our file analytics/datametrics, a kind of super-verify, identified 152,515 corruptions. This was certainly one of the worst corrupted files we ever had submitted to us for analysis. There were more than 72 different kinds of corruptions present in the file but about 30,000 of the corruptions involved errors in the ‘link table’ that associates

QuickBooks uses ‘links’ to related transactions in one table to transactions in a different table.  At times the links between transactions can become corrupted and most reports associated with the broken-link related transactions will be inaccurate.  This sometimes occurs between Vendor Bills and Bill-payment Checks, it can also occur between Invoices and Customer Payments. 

When links become ‘broken’ they may be repaired by either a manual process, or in some cases using the QuickBooks Rebuild Utility. Unfortunately, the Rebuild Utility may not always resolve this type of problem, especially if the link table containing the transactional references is the actual source of corruption.  You would be hard pressed to find time to manually go back and re-link 30,000 transactions, and you might not even be able to do that is the link table is so corrupt that it can be hardly read at all by the database server. 

Even worse, that type of corruption can be made worse by using the Rebuild Utility, which may in fact encounter such significant corruption that it will actually ‘crash’ simply trying to fix one error.  Take the following example (in which the names have been changed to protect the innocent) for instance.

In this excerpt from the QBWin.log file (which we have highlighted by use of ‘red’ text) there is an error associated with the Rebuild Utilities attempt to correct a corrupted link between a ‘bill’ (Vendor Bill) and a ‘bill pmt – check’ (Vendor Bill Payment Check). The result was an ‘Unexpected fatal error’ in which the Rebuild Utility crashed. Specifically, the fatal error resulted from a ‘write transaction being initiated while the transaction was being read (or attempting to be read).’

You are not going to get very far trying to repair 30,000 link errors if the Rebuild Utility encounters a fatal error and crashes with every one of them, even if you manually repair the first such error in the list.

Below is another example of some of the corruption issues we have been dealing with as of late.  In the QBWin.log except below we find an example of QuickBooks ‘Target chaining’ errors.  Just as QuickBooks ‘links’ different transaction types together, the database also creates objects that relate the various components (records) of a single transaction type together using something known as ‘Master’ and ‘Target’ records.

In QuickBooks, essentially all of the transaction types are actually made up of at least two records.  For example, in a check the transaction record designating the ‘source’ relationship is the ‘Master’ record. The source of a check is the bank account upon which it is drawn. That information is captured in the ‘header’ or top portion of the check along with information like the Payee’s name, the Amount, a Date, and a Memo field. The stub portion of the check is actually 1 record for each line of the stub. So, a transaction line that is associated with an expense account is one ‘target’ record containing the ‘target account’, and a different transaction line that is associated with a ‘Item’ is another ‘target’ record and a different ‘target account’.

The source record and the line items are related to each other by various identifying objects in the database.  All of these records have the same ‘target_id’ but each has a different ‘transaction_id’. The index (primary key) that relates these is made by combining the ‘target_id’ with the ‘transaction_id’.  Anything that corrupts these relationships and the objects identifying them, creates the type of error we see in the above illustration.

Intuit tells you that you may see these ‘Target Chaining’ errors after running the Rebuild Utility. In other instances, the presence of errors of this type may again cause the Rebuild Utility to crash with an ‘Unrecoverable Error’.  Intuit goes on to tell you that you need to ‘restore a backup’ created prior to the Rebuild that produced the Target Chaining error(s). They then tell you that ‘if a good backup is not available, you will have to create a new company file and re-enter your transactions.’  In other words, ‘don’t bother sending your file to Intuit Data Services.’

Both of these are seemingly daunting errors because the normal mechanisms which QuickBooks Users and ProAdvisors make use of, namely the Rebuild Utility, to resolve many errors simply don’t work in these two cases we have seen.  What’s worse, the Rebuild Utility may actually make matters worse by leading to additional damage in the link table and producing even more target chaining errors. 

But all is not lost. If you have a relatively limited number of transactions corrupted of either type we have discussed, you maybe able to resolve the corruptions by ‘manually’ repairing the transactions.  For example, you might need to remove a Customer Payment from the Bank Deposit, then record an identical replacement transaction, link it to the original Customer Invoice, and then delete the broken payment, finally you would add the replacement payment back to the bank deposit.

In the case of target-chaining errors, try ‘duplicating’ the original transaction, then deleting the original. This will likely insure the Master-Target relationships between the various records making up the new transaction are properly related to each other. 

Of course, if you have hundreds or perhaps thousands of such records, then you probably should seek professional help.  If Intuit Data Services won’t take your case then there are several reputable file-repair services who do repairs of this type and can potentially turn a bad situation into satisfactory solution.

By the way these are some of the QuickBooks Desktop Errors we will be discussing in my QuickBooks Desktop Super Geek 201 course at Scaling New Heights 2018. So, if you simply can't get enough of these kinds of 'file messes' by looking at your own clients' files, then by all means join me in my course in Atlanta.