NU failed Sat Morning, it was ugly and we ended up with a damaged TFILE.DBF header. Logged a down call and Applied logged in and fixed this morning, however Applied believes that we are short 34 activities due to the record count being different from the header count by 34.
I have ran a report of all the activities with an entered date of Friday and there are no gaps in time that would indicate a loss. It looks like the Close Day activities are there. Night Utilities just run Rebuild Sections and Customer Balances, Pseudo Post, nothing that creates activities.
Does anyone know of any report I could run that might help me find what these activities might have been?
Any help is appreciated, thanks.
Maybe you could use volume shadow copy to get the old dbf file from before the corruption and compare?
Quote from: Toni Forte on June 13, 2016, 11:48:39 AM
NU failed Sat Morning, it was ugly and we ended up with a damaged TFILE.DBF header
Since we know that the header was corrupted, I'm not sure any reliable inferences can be made from what it contained -- that 34 number could have come from a random unreliable source.
Also, if it was just the header that was damaged, the header could be rebuilt using the existing data in the DBF. So if you were really missing 34 activities, it would mean the corruption would have affected more than just your header -- the data itself would have had to have been hit too. It would be very unlikely that 34 records would have cleanly been truncated from the dbf -- especially if you are seeing intact activities that normally happen at the end of the day.
However, if you want to be extra sure, it should be possible to look at the error log file that wintam creates and see if there were any recent entries mentioning tfile issues before nu ran. If there were, the log file would say which user had the issue so you could ask that person to re-check their activities for anything missing.
Quote from: Ian Brown on June 13, 2016, 12:50:43 PM
Quote from: Toni Forte on June 13, 2016, 11:48:39 AM
NU failed Sat Morning, it was ugly and we ended up with a damaged TFILE.DBF header
Since we know that the header was corrupted, I'm not sure any reliable inferences can be made from what it contained -- that 34 number could have come from a random unreliable source.
Also, if it was just the header that was damaged, the header could be rebuilt using the existing data in the DBF. So if you were really missing 34 activities, it would mean the corruption would have affected more than just your header -- the data itself would have had to have been hit too. It would be very unlikely that 34 records would have cleanly been truncated from the dbf -- especially if you are seeing intact activities that normally happen at the end of the day.
However, if you want to be extra sure, it should be possible to look at the error log file that wintam creates and see if there were any recent entries mentioning tfile issues before nu ran. If there were, the log file would say which user had the issue so you could ask that person to re-check their activities for anything missing.
That makes me feel a bit better, as I am comparing TAM activities to eTfiled items from last Friday and I haven't found a one yet that isn't in TAM.
Quote from: Mark on June 13, 2016, 11:51:50 AM
Maybe you could use volume shadow copy to get the old dbf file from before the corruption and compare?
Thanks Mark.