We have seen some large serial databases, but not to this magnitude. Manually clear the serial numbers from the receipt or completely remove the PO/Receipt.

If you have Sage 300 installed on the SQL server, I wonder if that would increase your chances?

I don't feel it will. I'd have to imagine the program is trying to load all these records in memory and hitting some sort of 32 bit application limit. I'm surprised it processed the PO Receipt.

Maybe Musick or TaiRox can "emulate" what would happen to this document through SQL? Or you can reverse engineer the logic behind a serialized shipment day end and move the records around yourself... But I know how risky and time consuming that would be.

If you have Sage 300 installed on the SQL server, I wonder if that would increase your chances?

I don't feel it will. I'd have to imagine the program is trying to load all these records in memory and hitting some sort of 32 bit application limit. I'm surprised it processed the PO Receipt.

Maybe Musick or TaiRox can "emulate" what would happen to this document through SQL? Or you can reverse engineer the logic behind a serialized shipment day end and move the records around yourself... But I know how risky and time consuming that would be.

I figured out the crash earlier this morning. They have a scheduled job that runs IC day-end every night at 11 PM, and it's been taking so long that it's been bumping into the next run of the job, causing a "record modified by another" crash. I just disabled the schedule, so now we'll see how many days it's going to take to finish.

And I can't wait for it to finish, because on top of all the serial number problems, the OE shipment is showing an extended cost of 1,668,633,834,000.00. That's 1.7 Trillion with a T! I think there's been some major fat-fingering going on.

LOL! I don't envy your situation. Unless the number's legit, then just say you can fix it for a 1% commission.