Error #121 147 occurred!

[doyle]

Yesterday we had a crash during the day. We had the following error "Error #121 147 occurred! File Accounts Payable G/L Transfer File for ..."

We restored the prior days back-up and recovered all modules. I found an error description file in AR that indicated that the distributions were flawed. There was no transfer file created in this module all month (something I'm going to change in the future).

We now have 5 open credit customers in AR with bogus account balances. We can't seem to come up with a way to get them balanced in a way that I'm comfortable with the resulting transfer file to G/L.

Since these are 1 time customers with only a couple of entries, I'm considering deleting all activity on these customers through INVOICING and/or AR, which will still result in a bogus balance. I then will delete the customer in the UTILBA program. I'll recreate the customer and re-enter the invoices and payments. This sounds comfortable given that there have been no transfers to G/L nor has there been a transfer created.

What are the dangers here???? Will inventory be in error? Should I be concerned about the rest of the monthly activity that was performed for the month and has not been transferred? How can I protect this data?

Thanks.

[chikamic]

Try running recover data on your AR files.

[doyle]

I'm sorry. I left a few things out. The long and short of it is that although the error occurred in AP my bigger problem occurred in AR. Since there was only a handful of entries performed on the entire system it seemed logical to do a full restore of the back-up from the end of the previous day. My thinking was, "since we had such a hard crash, just start fresh from last nights data and move on."

I did run the recovery process on all elements of AR and Invoicing (actually I did it on all modules after the restore). I looked inside some of the AR files and saw what appeared to be corrupted invoice data for the customers in question (5 customers). I could see the offsetting accounts on other invoices, but these 5 customers had out of balance transactions (not double-entry). The result is the customer pending balances do not add up to the the detail from printed documents. The imbalance matches exactly the values that are missing in the AR files.

My thought that I could simply delete all invoices and payments that PCA could find and then delete the customer with it's erroneous balance through UTLIBA, is only of interest to me because there is no real customer history. These customers are most likely a one project customer. After deleting the customer, I could then re-establish the customer and make new entries from the start of the sale and move on.

So far all the rest of the modules seem to be working okay. I suspect that inventory will be off. (You may have remembered my experience and attitude towards the inventory module from a previous post). My concern is that after all of this that I will still be out of balance between the AR module and GL. Since the transfer files were not generated for the whole month, I don't know what I'm going to get until we initiate them and transfer to GL. It's a little difficult to back-up and fix things after that.

In closing, do you have a feeling as to why the restore and recover would have resulted in a problem like this? Should I refrain in the future from performing a full restore and recovery in the future? Where is the transaction data located prior to creating a tranfer file?

Thanks.

[chikamic]

Tell me about your backup method and what if anything occurred when you restored.

I think I can help you get back to a point where you are comfortable but I need a little more info.

[doyle]

Our back-up procedure is to do a full back-up of all modules at the end of everyday to a zip disk. We have a zip for every day of the week and have 5 fridays.

When we restored the back-up from Monday evening, we basically should have simply lost the data entered on Tuesday, something we were okay with. There didn't seem to be any odd occurances during the process.

We did a recovery before making any entries. During the recovery process it changed the balances on 2 of the customers. Although incorrect, the changes made are logical numbers found in the previous transaction detail.

Anyway, after the full restore and recovery the office manager tried to re-enter her work after the last back-up. That's when the balance problem became fully apparent.

My understanding is that the recovery simply re-indexes and links PCA's data files. Seems like a safe thing to do at any time.

I just talked with the office manager and going back to the Friday back-up would not be too difficult of a data re-entry problem.

Thanks.

[chikamic]

Due to the fact that the damage showed up upon running Recover Data, it is apparent that the dmage was already present it was just dormant. PCA data damage is sometimes not apparent until you run a process like Close Current period or Recover Data. You are correct, it is a reindex, but there are times when it can make the problem worse.

If you think you have what you believe to be a clean backup, what you can do is to deactivate the module, reactivate it to create a set of empty files and then restore your backup. I have run into cases when attempting to restore over corrupted data form zip corrupts the inmcoming data as well. Starting with a clean set of files would eliminate this risk.

Let me know if you need additional guidance.

[doyle]

Thank you X ...

That did the trick. I even restored the same back-up that had previously failed. I did the recovery. All balances are legitimate. We just have to re-enter the activity from Tuesday thru today.

Why would corruption still occur if you restore a back-up normally? It seems it would simply overwrite the files. Then the recovery would build the fresh indexes. What did the de-activate re-activate do to correct the problem? Are there pointers in the module files that keep track of EOF or something?

I just like to know these things.

Thanks again.

[chikamic]

There are a few files that remain unchanged even after restoring because they are read only.

When you deactivated and reactivated you created a clean set of module files to restore into. You got rid of all files associated with the previous data set