How are destruction dates stored?

Go to solution
Matthew D Wilso
Honored Contributor.

How are destruction dates stored?

Hi guys


I've been trying to write a sql query so our records people can do some reporting on "dates due for destruction".   I've been looking at the table TSARCHIVEE, but the dates (AEEVENTDATETIME) only sometimes seem to correspond to the dates displayed in the TRIM GUI.   Sometimes they're a round number of years off, and sometimes just seemingly random.  


Can anyone tell me how those dates are modified before they're displayed by TRIM?    The client seems to ask for the dates, but do I need to apply further rules from TSSCHEDEVE?   The issue for us is just the sheer volume of data - it would be a lot more convenient to be able to work with the data offline, is all.






Greg Fraser_1
Micro Focus Expert

Re: How are destruction dates stored?

Hi Matt,


Not sure if anyone else has any advice to offer, but you wont get what you are looking for with a SQL script as far as I know.


**Any opinions expressed in this forum are my own personal opinion and should not be interpreted as an official statement on behalf of Micro Focus**
Acclaimed Contributor.

Re: How are destruction dates stored?

The TSARCHIVEE table is where the pending events are stored. the Date Due for Destruction field is a *calculated* field. It may change from minute to minute based on changes to the record (or say the contents of a folder).

If your event server is bogged down and behind on schedule event triggers then you may see a difference between what's in the TSARCHIVEE table and what's in the Date Due for Destruction field.

As for why some are rounded, look at the trigger definition regarding rounding.
Matthew D Wilso
Honored Contributor.

Re: How are destruction dates stored?

Yeah, I gave up on the SQL approach and wrote a short program to run a search and write the results to a spreadsheet.


It took just over 4 hours to run, which is roughly what the users were reporting of the TRIM client as well.   Once the data they need is saved as a spreadsheet, the users can work with it easily.  It's not rapidly changing data.


We have some containers with a lot more contained records than the TRIM spec recommends, so retention schedules can take a loooooong time to be calculated (and there's not a lot we can do about it from a system tuning point of view - it just involves a lot of individual database requests).   We don't even process scheduled event trigger events "live" any more - I do a "batch run" when the records management people want to work with the latest dates (select all the schedules -> recalculate).   If I leave the event service running those events all of the time, they can get way behind and start dragging down the other event queues.