ABTWork table


what are the ABTWork and all ABT… tables used? Can they be purged, they use a lot of space on my database.

Thank you,

Daniel Cardoso

They can be purged as they are used for storing parameters related to posting. In E9 there was a conversion program you could run to clean up these tables but not sure what the equivalent is in E10. Perhaps @aidacra does?

I thought there was a conversion for this in the application, but, looking through other Support cases it appears that we request a data fix to address in 10.1. The name of the fix to request is: FX_Del_ABTWork.sql

1 Like

10.1.400.29 had the fix.

This was something we were interested in. Our ABT tables were almost 50% of the total DB size.


Is it safe to delete all records in this table without testing?


I haven’t tried so I don’t know


So I requested this fix for 10.2.300 and it appears to delete one row at a time. We have 1.6 million rows to delete and it appears to be deleting records at about 1600 / hour . At this rate, I’ll have to run the data fix for over 40 days. Does anyone know if there is a better way to do this?

At this time their fix I think only does 1 record at a time, you will have to ask Support to modify their fix. No other way at this time.

1 Like

I had the same problem with ABTWork records. After complaining about the time to run the data fix program, Epicor Support provided me a SQL script, instead of the data fix. It ran directly in SQL and took all of 40 seconds to find, determine they were useless, and delete 1,000,000 ABTWork rows and 377,000 ABTHead rows. I ran it first in Test db, then in Live db.

I’m on I don’t know why the financial engine doesn’t delete these records when they are through with them. I think I purged them from E9 before migrating to E10 (at 10.1.600.14), and I assumed they wouldn’t come back. But, they did.

I referenced KB0051207 in my Case CS0001862824. After first getting the datafix named FX_Del_ABTWork.df, they later sent SQL script named FX_Del_ABTWork.sql.


I also ended up getting the SQL script after complaining about the first fix they issued. I’m not sure why they even bother with the first fix, but the important thing is it’s possible to ask for a fix of the fix.

Thanks much for this info. We had 5m rows.
For others, Epicor advised that these ABT tables be cleaned up prior to upgrading to Kinetic. Apparently there was a bug in 10.1.600 that has since been fixed. They were kind to provide the fix for Kinetic to us.