Hi 'jfwalke'
I don't have a straight answer on your speed issue of R42800, although if you are updating 40,000 records, I am not surprised it is taking 4 hours.
However I do have grave concerns as soon as anyone mentions the word "cancel" or "terminate" in relation to R42800.
If the UBE is cancelled before it is finished, the R42800 Workfile (F42UI800) will still have records. If you subsequently run R42800 again, you are very likely (depending on when exactly the UBE was cancelled) to get duplicates in A/R and G/L. These duplicates are very messy to clean!
The other day I made a similar reference to R42800, so please allow me to copy this section here again:
There is a Knowledge Garden Document (ODS-00-0140) that gives a reasonable explanation of what exactly happens during sales update. The key to it all is F42UI800. You should try and determine if the batch failed during:
a) writing of the F42UI800 records
b) reading of the F42UI800 records
c) Reading and deleting of the F42UI800 records
Case a) You are in luck and just need to delete the F42UI800 records
Case b) Only financial records are written, which you can remove by SQL from F0911 and F03B11. Also delete F42UI800 and re-run R42800.
Case c) Ouch; All financial records were written and some Inventory and sales records were created/updated. In this case I would only delete those records from F0911 and F03B11 that still exist in F42UI800, than delete the remaining records from F42UI800 and re-run R42800.
The most important thing is to ensure F42UI800 is always empty before the next R42800 is submitted, or else you risk having duplicates in A/R and G/L
This is just a rough guideline to fixing your integrity issues, but hopefully if will give you a bit of a hint on how to proceed.
Hope this helps in your quest,
Rgds,
Sef van den Nieuwelaar
Australia
B732 on NT, XE on NT, B732/A73 on AS400, B733 on NT
* Coming to a European City near you soon *