Sage 100

HELP!!! Customer at 4.40.5 has a corrupt IM_TransactionDetailHistory file. Can't rebuild it, can't get data through Crystal or Excel, can't even export it with VI. Troubles started on Wednesday in PO. Today they can't update the SO Sales Journal. They opened a case with Sage who had them rebuild files, etc. then asked for a copy of their data. Finally, they call me this morning. I tried copying their data to a test company and that file didn't even copy. There are over 617K records so kind of hard to scroll through them. I have been working on this for most of the day and it IS getting late on a Friday. Any thoughts on how to find the bad record or other options????

Yikes. Hope you didn't promise them a solution before the Super Bowl on Sunday.. I bet one of the PVX guru's (@AlnoorCassim , @KennethPhillips , @RandyMarion or someone I have forgotten to mention) can probably give you the secret code to determine which record is wretched so you could access it via DFDM...... Kinda reminds me of the Princess Leia reaching out to obi wan Kenobi in the first (4th) Star Wars episode... http://www.youtube.com/watch?v=xIFJLMyUwrg

Since there is an unlock region failure, I would at least try the rebuild directly on the server, if you have not already tried that? If you try and import it into Excel or Access, what type of error do you get?

Run the rebuild with Option to Optimize File (check box in upper right corner of rebuild file list). But seem record for item 304-686 is going to be the focus point. If the optimization doesn't allow rebuild then DFDM to that file and call up the file's record list . You should be able to locate the bad records pretty quickly in that view and scrolling down list. Blank key or blank fields should be easy to spot.

Tried @JoanSerr's approach but that didn't help. This is the error in Excel and I believe it was the same in Crystal.

Back up the file then try *ufar utility to rebuild. That's usually my rebuild utility of last resort.

What was the error in PO? And you have run the embeddedio Script. A trick I learned is to run the report getting the error and with the error up on the screen go to DFDM and view the work table that is created for this report run. The record expected after the last record is typically the one causing the problem. Like Bill, When all else fails I also use *ufar, as last resort

Well, I can't even copy the file. The PO error was Wednesday. Today, it was during the sales journal update.

Could you have a bad spot on the server drive?

You might be able to Import the record in Access. And then start searching for an odd record. I have been able to import directly in Access when ODBC was bombing on occasion.

Trying UFAR now. Will see what happens. Access is a thought though.

Does UFAR ever error out? The bar hasn't moved in the last 10 minutes. @JoanSerr

What do you do when ProvideX stops responding??

Are these errors all coming up on their server or are you doing this locally on yours and getting the errors? If it's on theirs it sounds an awful lot like a bad section on the disk.

It's on their system and I agree.

Time to throw in the towel and pour a double glass of wine. Let the IT folks worry about it now.

I did. I left one of the principals a voicemail with my concerns and that there's not much more I can do. I told him I'd contact them again first thing Monday AM to see what we might be able to do. Thanks all, for your suggestions!!

be careful if it did rebuild that it the number of records from the old file and new file are close. You cannot import into this file if you need to later. I did get a developer to append a huge file when we lost a bunch of records during a rebuild.

There were six files in total that somehow got corrupted, mostly historical. We had to restore from a backup, fully aware that they would be incomplete files. He preferred that to doing a full restore and re-entering a week's worth of data. Their backup also failed last Monday with a similar error - something DOS related, I think - so they had to restore those six files from a week ago last Sunday. He rebooted the server and ran a Check Disk but nothing came up. He is hoping his backup worked last night but if not, he knows something needs to be done with their server.

The bad part here is if you ever need to run rebuild inventory then all the history tables and inventory by period will be hosed!

I told him that. He said they have a pretty tight rein on their inventory so he isn't too worried about having to do that. I gave him fair warning though! The other files - in case anyone is interested - were IM_PeriodPostingHistory, RA_CustomerInvoiceHistorySearch, AR_SalespersonCommission, IM_ItemCustomerHistoryByPeriod, and SO_SalesHistory. Since these are all written to during an invoice update, I'm guessing something went awry during an update. He had opened a case with Sage and they said to zip his data directory and send it to them, which also didn't work. And then he left on vacation for a day and left another in charge. By Friday, they were getting a little frantic.

I'm sorry I didn't catch your message. I was knee deep in an upgrade with IT running amuck. Looks like you worked your magic on the situation. Glad for that. Again my apologies.

A final update - I hope! Their backup did NOT work that evening either so the next day, he had Dell log in to take a look. They said their RAID array had a ""puncture"" due to a failed (failing?) drive. He manually copied files to an external drive and I believe, they got a new drive in the next few days. Haven't heard from him since.

Aren't Raids supposed to alleviate that type of data error???

Hey, don't ask me. That's all I know. http://www.theprojectbot.com/?p=161

Some RAID configurations are for redundancy and some are striping, which distributes data over multiple drives to increase performance, but actually increase the risk of data loss because files can be in pieces across multiple drives, the failure of any one of which hoses the file.