Data Purge and Data Archiving

There was a company I spoke with at CUE last year that had an Purge and achive solution. Their name was The Revere Group. Of course, that would cost money.

I have a client who uses their solution, which is essentially a cloned product line (e.g. arch) with data from production (prod). Once the data is archived to "arch", it is removed from "prod". I would assume that in order to be usable over time, you would have to maintain "arch" with MSPs, upgrades, etc. so that it matches "prod" for table structures, etc.

I've personally never been a fan of archiving. It's much "cheaper" in the long run to throw in more disks and faster hardware. =

True - to a degree.  However, Revere Software has perhaps the only solution that works for moving data from Lawson to an archive area.  You still have the same data - just not as much to deal with during an upgrade.  The archived data still needs to have the MSP's applied and still needs to be upgraded either before or after the upgrade.

We have successfully used Lawson's purge programs in order to reduce the amount of data that needs to be upgraded.  The biggest headache (in part) came from getting a final determination from the users as to how much to purge and how much to retain (GL, etc).  The second headache came from less than optimal documentation for purging records as the Lawson data structure is handled by system code and has a lot of dependancies from related system codes.  It DOES work - and the records are gone.

Question: Where is the 'break point' on adding more disc space vs upgrade time?  The users obviously don't have a desire to give up Lawson for longer than they need to in order to allow the upgraded data to be converted.

 

We've purged in the AP system using AP300, and we setup triggers on the AP tables to copy the deleted records over to another schema with the same AP tables. This way the users can use Business Objects to still query the purged data if needed. Now a big problem that we ran into with doing this, is that the AP300 doesn't check the CB system to see if there are checks still open before deleting the invoice(s) tied to it. So you will want to see if you have any old checks open before purging Invoice.

If you download the Lawson documentation for purging, you will find a flowchart that addresses the procedure to follow prior to running the AP300 - which includes verification that potential problems that you ran into are resolved prior to the run of the AP300. (System code dependancies)

This was 3 years ago, and pre-9.0 applications. During that time frame, I could not locate such a document, and was told by GSC that the AP300 was "Working as designed". They too never pointed me in the direction of any purge documentation, instead suggested I contact Professional Services. We found other alternatives.

Thanks for the replies!

Your AP300 story reminds us all of the all the hooks and connections Lawson has underneath. Take BN430 for instance... I could run that, but boom, there goes payroll data. Oops, what if you need that for an audit?!

The purge documentation seems to indicate a purge program for nearly each system code. It appears to create a csv file, which I cannot imagine is much use - meaning a individualized process would need to be put into place to be sure that the data can be easily retrieved.

Any advise on how many years to keep certain types of data? I like the idea of keeping everything...but I'm not sure how long that will be an option (fortunately we are a small shop..so we may not have issues with hoarding)...

Thanks for all dialogue on this one, it appears to affect all areas of lawson.

We just went through the process of purging 2 years worth of payroll history. Of course our users said it was ok after much angst and research. However after the data was gone one day, they needed it back to print a check stub. What i found out was a rngdump of the data as of the date of purge helped us tremendously (of course this was before any upgrades occured) we were able to reload the data using dbload for the tables that were affect by the pr300 purge. Also this program created csv files of the tables effected. This helped us determine which tables to reload. Before purging the data i talked with GSC and they told me yes you can reverser the purge using the pr560. After the purge i was told by GSC i would have to write custom code to reload. I chose the dbload. I would hope that you could take the csvs and map them so that the pr560 would accept them to reload the data. I don't know though.

Absolute! will be presenting a data archival solution at Inforum 2012. This data management technology will allow you to selectively archive data from Lawson, keeping it in a compressed format that can be accessed via ODBC/JDBC technologies (i.e. Crystal Reports) and can be brought back into your Lawson production productline as necessary.

Contact Kip.Lindberg@TeamAbsolute.com for more information or call 612.746.1406.

Anyone successfully purged/archived and then still been able to get iinto the archived data without toooo much IT help?
S3 fin gl ap hr payroll benefits running on iSeries

Thanks
:blink:

Martin,

My company provides a method to archive data into folders for easy access and retrieval. We have been in business since 1983 and work with over 350 hospitals as a Report Archiving and Automation Solution. In fact our system, is called RAS (Report Archiving Solution), acts as a virtual printer and allows folders to be setup for viewing and extraction on an ongoing basis. We typically see our clients using our system for 3 major use cases.

 

1) Print Manager Window - Only stores reports for a 3 month window. All management and payroll reports that need to be viewed and looked at a later time as printed to our application. These reports can be retrieved forever once sent to RAS.

2) HR/Payroll reports that are ran frequently get overlaid and the data and information is lost once the new report is ran. Payroll reports like - PR140, PR160, PR135, PR132 - are sent to our application and archived there so the information doesn't get lost. 

3) Our application work in conjunction with Monarch - Reports are captured and extractions allow for custom splitting of reports and custom bursting by department, cost center, etc..

Give me a call at 908-309-4062 or email at mmorgan@dbtech.com if you want to talk further.

www.dbtech.com