What are different forms where data get piled?
If you data is large in the AR System Email Messages form then to delete outgoing message you can use 2 setting a) Mark the delete outgoing notification message = Yes This will delete only outgoing notification emails.
b) You can add properties in the EmailDaemon.properties file as
com.bmc.arsys.emaildaemon.SaveSentItem=false this will delete all outgoing emails.
If you have huge number of entries in the AR System Email Error Logs , please set the log level for ARSystemHandler as OFF or SEVERE
To change log level you have edit logging.properties from email engine Java Runtime Env(JRE)\lib\logging.properties
- com.bmc.arsys.emaildaemon.ARSystemHandler.level=OFF or SEVERE
Once you done this setting please restart email engine.
Also if you have large number of incoming emails then you need to have escalation or workflow to copy message to some other staging form or delete them.
Hope this helps you.
Thankyou all for inputs.
We want to delete both incoming and outgoing emails and also records from AR System Email Attachment form.
Unfortunately our client wants to keep the outgoing notification emails (alteast 90 days older), so we can't use the logging option as it will delete all outgoing notifications and we already have set the logging level as SEVERE.
So more suggestions are welcome other than deletion from Database side.
How about archieving ??
That was my first thought as well but it seems that you can't actually archive in this system form, I mean you can do it, but then it'll cause a lot of problems, more details here:
Thanks Laurent ...Got your point
We also thought of Archiving first but dropped as we had ran into some issues for other OTB forms, so dropped it.
Thanks Laurent for sharing this information.
I think we should go for manual deletion only and define escalations to delete the old records.
But I am keeping this discussion open to get more options.
Another way could be;
1) Disable email engine
2) Create an escalation to delete useless date from AR System Email Messages form
3) Run the escalation
4) Verify whether the data has been deleted or not
5) Disabled the escalation
6) Enable email engine
another and fast way to do this: Take help from your DB team to perform below steps:
1. Create a backup table of AR System Message form (T table)
=> SELECT * INTO copy_of_EmailMessages FROM (T table)
2. Truncate table
2. Delete * from T Table where submit_date < xxxx (records more than 7, 15 days old)
I would prefer to issue a truncate table on the T and H tables. Truncate table would be faster and frees disk space.
yeah, but truncate will delete/clear all records from table. that is the reason I gave two options.
as compare to remedy workflows, both options are much faster.
As Ganesh have mentioned, best way will be to use esclation, it might be slow but safe way to do it..
set up an escalation that fires periodically. Set the run if to do small groups so you don't impact the server. After you get caught up have the escalation run based on some thing like Create Date <= $TIMESTAMP$ - (30 * 24 * 60 * 60) which will delete anything created greater than 30 days ago
1 of 1 people found this helpful
I am just finishing a cleanup of our email forms, which had almost 1.5 million rows in them. The basic procedure I followed was a balance between the speed of deleting records at the DB level and the completeness and cleanup of doing so through AR System. It took a few days of sort of full-time work to complete.
1) Determine the affected tables:
* AR System Email Messages
* AR System Email Association
* AR System Email Attachments
* AR System Email Error Messages
2) Delete the records in the H tables for the first three forms. The Status field isn't even used on them. (In fact, you should probably disable the storage of Status History on the Email forms on your Form Properties in Dev. Studio).
3) Delete the records in the B tables to a safe level, i.e. we want to keep 45 days worth of messages and their associated records, so we deleted down to about 4 months worth at the DB level, and used AR System to delete the rest.
4) Delete the records in the T tables to the same level as in Step 3. The nice benefit of doing it this way is that when you start deleting from AR System, the table is so much smaller that the searches and deletions execute more quickly.
5) From User, delete in chunks until you reach your desired goal (for us: 45 days worth). We used this query:
('Create Date:' + (((60 * 60) * 24) * 45)) < $TIMESTAMP$
6) Set up a Filter and Escalation to flag and delete records daily from those forms (using the same qualification as in step 5), to keep them from building up again. We found that we couldn't put that qualification in the Application-Query-Delete-Entry call in an Escalation - it just wouldn't run. We can do it in a Filter, and set some unused field to a value that the Escalation checks and then deletes.
Thank you Rick for sharing this procedure.