DataCare 8.1A (071220)

I have a job named "INTEGR" that is set as follows:

AP, AR, Ledger, Inventory & OE are all set with only 2 checkmarks on:

*Perform file integrity check
*Perform application integrity check

POA & Sales Analysis are set with only 1 checkmark on:

*Perform file integrity check.

Unchecked on all modules are:

*Rebuild file integrity errors
*Rebuild application integrity errors

In Company Profile/Job Defaults:

Uncheck are:

*Rebuild file integrity errors
*Rebuild application integrity errors

Why then tonight when this job found application errors, does it still rebuild?? (copied below)

Every time this job runs whether it finds errors or not, the status says, "Rebuilt". Is there a way to stop DataCare from rebuilding???
________________________________________________________

Data Integrity of:
Located on: I:\data\ with extension: dat
Started at: 2009.10.01 18:30 by System Account
Job: INTEGR

Adagio OrderEntry: Application Integrity

Item CO CA106625 not found for loc WA on line 1 of O 51695
Item CO CA106650 not found for loc WA on line 2 of O 51695
Item TV CHO4053 not found for loc WA on line 4 of O 51695
Orders/Invoice headers ... 3 error(s) found

Summary

Application Integrity ... 3 error(s) found ..................................... FAILED

Finshed at: 2009.10.01 18:34

Data Repair Phase

Correcting Phase 2 Errors
*** Item COCA106625 was added to loc WA
*** Item COCA106650 was added to loc WA
*** Item TVCHO4053 was added to loc WA

Finished rebuilding integrity errors.
Please repeat Data Integrity Check.

Hi, Susan,

Yes, there seems to be a problem with DC rebuilding when it shouldn't on a delayed job. This has been reported to R&D.

Tonight....

-------------------------------------------

Data Integrity of:
Located on: I:\data\ with extension: dat
Started at: 2009.10.02 23:56 by System Account
Job: INTEGR

Adagio OrderEntry: File Integrity

Sales Order Detail ... 1 error(s) found ........................................ FAILED

Summary

File Integrity ... 1 error(s) found ............................................ FAILED

Finshed at: 2009.10.03 00:02

Data Repair Phase

Rebuilding Sales Order Detail ... Done

Finished rebuilding integrity errors.
Please repeat Data Integrity Check.

-------------------------------------------

What am I suppose to do???

1. I have no idea why these errors are occuring.

2. I don't know how to stop DataCare from rebuilding.

3. I'm not aware of any way to find out what exactly is being rebuilt and what data is being lost in the rebuilding process. (I checked OEINTERR.DAT immediately after this integrity check and it's empty).

Hi Susan,

Well, there was an error in the index of the sales order detail and that has been repaired. That may be the extent of it. You'll notice the log suggests running another integrity check to see if anything needs adjustment.

Integrity errors should not happen more than once or twice a year, even in a very high volume site (some sites never have a problem, but the hardware doesn't guarantee that kind of performance). It's possible you may have a marginal netowrk card that only fails under extreme load. Would it be possible to run DataCare from another workstation and see if that changes the results?

Also, if here's a hardware problem, there might not actually be an integrity problem. (If a warning light turns on, is it signalling a real problem or a faiure in the detecton circuit?)

How long does the integrity check take? Could you see whether you have a problem running the checks from with the application, rather than via DataCare?

This is going to take a bit of time to track down, especially if you're having an intermitant hardware problem.

Thanks for your patience.

Hi Andrew,

When I run a second integrity check it will run clear. It always does. I only wish there were some way that I could see what specifically was rebuilt. If I remember correctly, Accpac's mr. fix it used to create an error file that you could print out that gave a detailed report of what exactly was fixed. It gave us an opportunity to manually re-enter what was lost in the fixing process. An error in the index of the sales order detail is too vague. We have so many Pick Lists and Back Orders in circulation at any given time, I wouldn't know what to look for? I could restore the back up and run the integrity through OE and hope it doesn't rebuild and then if it finds the errors again I could call up every uncomplete order on our system and see if I can find anything unusual. I really don't know if this would be worth the time it would take when it's not clear what the problem is with the Sales Order Detail. My primary concern is preventing data loss or at least being able to identify what data was lost so that it can be restored through some sort of workaround.

There may well be no data loss (actualy this is the most likely result). Are errors being regularly detected? Of so, then there's a hardware problem somewhere that should be tracked down and corrected (and I won't minimize how difficult that can be). If the manual DIC fails on one machine then immediately run it from another machine and see if the same errors are reported. (I hope you'll find that the speed of the DIC has improved noticeably in the recent release.) You might also try copying the data local and rerunning the check again. The object here is to try and isolate a failing hardware component.

Hi Susan:

There are 2 parts to a Data Integrity Check: File Integrity and Application Integrity. I'll describe the 2nd one first because it is easier to visualize.

The Application check looks to make certain that the data "matches". Here are a few examples: Does the total of outstanding invoices for customer ABC match the total on ABC's master customer record? If customer XYZ is assigned Terms code "NET30", does that code still exist in the master Terms list? Is every record in the Ship To table matched to a customer in the Customer master? Are there any Sales Orders without a matching customer in the Customer master? And so on.

When these errors are detected they are generally listed in the on-screen log (though more detail and clarity would always be welcome). This is what you encountered on Oct 1.

The File check looks at more fundamental problems. Does the index match the data table? Do the correct data tables exist? Support could explain better what happens during this check.

These errors are not so easy to describe. As a result they aren't always listed in the logs (on-screen or otherwise). This is the situation that you encountered on Oct 2. As Andrew said, you have probably lost absolutely nothing. However it would be helpful if more detail was logged (and a "Print" button placed on the Data Integrity screen to list the log file).

Hi Bruce,

If we lost anything when DC reported File Errors on Sales Order Detail and rebuilt on Friday, I can't find it. However, when DC found File Errors on Customer Alerts and rebuilt it on Sept 14, I made the mistake of assuming that we didn't lose much, if anything. As it turns out all of our customer alerts were wiped out. I guess the worst part is not knowing whether or not anything was lost and if so, what it was?

Andrew,

I hear you about looking for a hardware source to the problem but I can't find anything wrong with our server, workstations, network, etc. In the last month we've had file errors Sept 2, Sept 14, Sept 22 and Oct 3.

We're up and running this morning so I'll watch the integrity checks each night.

Hi Susan,

I think most of the people who monitor this forum would say that this is too frequent. My guess is that you have a network card that fails intermittently under load. Unfortunately, the DIC itself is one of the most disk (network) intensive activities in all of Adagio. Over the next little while make sure that DIC errors are repeatable before pressing the Rebuild button.

Hi Andrew,

I should mention that we run DC Integrity Check from the Server. Therefore there is no network involved during the Integrity Check itself. In the early days after our Adagio install, we ran DC Integrity check across the network from a workstation but it was too regularly crashing and not completing (too intenstive). We run Toolkit from the server as well for the same reason.