ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Evo Menu & Evo-ERP >> Purging/archiving Question
http://www.istechforum.com/YaBB.pl?num=1256824560

Message started by gtladmin on 10/29/09 at 06:56:00

Title: Purging/archiving Question
Post by gtladmin on 10/29/09 at 06:56:00

Walter and Nancy complain about the slowness of the GUIs in Evo. I think part of the issue is that they have not really done any purging or archiving of files. The last time anything was done was 2007, and that was work orders. Sales orders has not been done in a while nor anything else.

They have given me a growing list of things they want fixed with Evo, (like I can actually fix any of them myself). Walter's latest complaint "This addresses the slowness of the gui. Go into inventory inquiry, open a part number, go across the tool bar and find trans, click it, stock status now rebuilds and you wait, now close it and open usage. Same things happen, stock status rebuilds again. Depending on how many transactions there are on a part, it takes longer to rebuild. ie IL1400A/U for amt of time to look up one screen at a time."

Our inventory transactions file for this company is about 162MB. Transactions go back to 2001 for the part mentioned above, but for all parts pretty much.

If they purge, they are very afraid of losing info they may need later on. What can they do to make the info accessible in case they do purge and later find they need the info? Their fear of purging records is, I feel, a big reason why it does not take only seconds to bring up info. Rebuild stock status on this part is 15-17 seconds.

I need to be able to tell them they can purge and still be able to get info for an auditor (nancy's biggest fear) without worry. I can't believe this is such an issue for others. What does everyone else do? Please help me help Nancy and Walter on this. It's driving me to seek new employment!!!

Val

Title: Re: Purging/archiving Question
Post by Vman on 10/29/09 at 07:04:08

Evo allows you to have multiple companies. At the end of the year, we created a copy of our current (active) company, then do our purging and archiving. This will increase the amount of disk storage you need, but it gives you access to records you might need later on.

Title: Re: Purging/archiving Question
Post by GasGiant on 10/29/09 at 07:40:34

The new archiving programs go a long way in allaying fears. The data is not purged, just taken out of the main look ups. It is available for reports (choice of looking in current or archive data) and it can be restored, if necessary. As a bonus, the archived data is easily added to reports, like Cystal or Excel, by doing a union of the current and archived tables.

Title: Re: Purging/archiving Question
Post by Lynn_Pantic on 10/29/09 at 08:09:36

Colin is correct, Use ARCHIVE rather than purge. To speed up Stock Status, archive Work Orders (SM-J-B) and Closed Sales Orders (SM-J-J). Keep only as much as you are likely to want to see on the IN-A buttons. All the JC reports (work orders) and the SO-O-J & K reports (Sales Orders) have an option to use Active or Archived data.

Title: Re: Purging/archiving Question
Post by gtladmin on 10/29/09 at 10:43:32

I've mentioned the archive stuff to Nancy twice now (Allen mentioned this to me a couple of weeks ago and I immediately passed it on to Nancy). She's thinking about it. *sigh* This is how it has been with the purging, we re-address this near the end of every year and that's as far as it goes.

We have some very large files that I'm not sure whether they would be touched by a purge or an archive--would any of the following files be reduced
with archiving or purghing? Not sure what some of ISxxxx files are....

ISMICADT.B01 591,524kb
ISMICADT.B04 238,112
ISICADT.B01 199.780
BKGLTRAN.B01 164,584
BKGLTRAN.B04 140,320
INVTXN.B01 161,312
BKARHIVL.B01 118,584
BKARHIVL.B04 102180
BKARDESC.B04 111,376
BKARHINV.B04 107,552
BKARINVL.B01 96,016

Thanks,

Val

Title: Re: Purging/archiving Question
Post by Lynn_Pantic on 10/29/09 at 12:39:12

See additions below

gtladmin wrote:

Not sure what some of ISxxxx files are....

ISMICADT.B01 591,524kb Change to Inventory Master (use SM-J-S)
ISMICADT.B04 238,112 "
ISICADT.B01 199.780 "
BKGLTRAN.B01 164,584 GL Transactions - use AM-I but you will lose the detail; this is not an archive
BKGLTRAN.B04 140,320 "
INVTXN.B01 161,312 Inventory transactions - use SM-J-D but you will lose the detail; this is not an archive
BKARHIVL.B01 118,584 Invoice Lines - SM-J-K and Archive
BKARHIVL.B04 102180 "
BKARDESC.B04 111,376 Sales Order Notes (open SO) - SM-J-J Purge or Archive
BKARHINV.B04 107,552 Invoice Header - SM-J-K Archive
BKARINVL.B01 96,016 Sales Order Lines - SM-J-J Purge or Archive

Title: Re: Purging/archiving Question
Post by gtladmin on 10/29/09 at 13:23:36

Thanks Lynn, I hope they will use this information.

Val

Title: Re: Purging/archiving Question
Post by Kelloggs on 11/03/09 at 08:57:52

Questions about Archiving Sales Orders.

If we use the date range, we assume that it will use the sales order's invoice date right?
Is there a way to view the archived SO? if not, is there are way to reprint a SO and/or Invoice?
The BKARHINV and BKARHIVL data is store where? what are the names of the archive tables?

Thnks,

Kelloggs

Title: Re: Purging/archiving Question
Post by Lynn_Pantic on 11/03/09 at 09:14:16

Archiving closed Sales Orders (SM-J-J) does not touch the invoice tables. Just the closed orders in the open SO files. Archive Invoices (SM-J-K) does the invoice files.

SO-O-J/K and SA-M/N can be used to look at the data in the archive files and the archive programs all have an option to restore archived data to the active files.

Title: Re: Purging/archiving Question
Post by Kelloggs on 11/03/09 at 09:43:52

Thanks Lynn,

I always get confuse about those tables.

I just need to know the name of the tables that the data has been archive it to.

:P

Kelloggs

Title: Re: Purging/archiving Question
Post by Lynn_Pantic on 11/03/09 at 09:49:34

ISARAINV & ISARAIVL and the Sales Orders and ISARAHIN and ISARAHIL are the lines.

Title: Re: Purging/archiving Question
Post by awaretech on 11/30/09 at 14:49:01

With reference to archiving ISMICADT (inventory audit?), is the data lost, or just moved to another file?

Title: Re: Purging/archiving Question
Post by Lynn_Pantic on 11/30/09 at 15:03:58

There is no archive of that file, only a purge but you can define which types of changes to clear as well as a date range.

Title: Re: Purging/archiving Question
Post by awaretech on 12/01/09 at 06:40:08

Our ISMICADT is upwards of 700MB. Is this slowing anything down?

Title: Re: Purging/archiving Question
Post by dameng on 12/08/09 at 22:21:37

just a general observation, but unless your files are closing in to maybe 2GB's, that would be considered large, a lot of records. 100mb to 1GB is not all that large.

Archiving stuff that is 3 or 4 years old is a good practice. normally most want to look at stuff that is at most 2 years old.
Purging is generally not a good answer, but at least it's available. i try to avoid purges.

the ISMICADT and ISICADT are the two files that track changes to your Item Master, so, if you are not using that information, it doesn't hurt to leave it alone or purge. they are not used for your IN-A status screens or other reports.

if you really want to weigh the impact of your decisions to archive / purge and see if it makes that much of a performance difference to warrant such action, then i suggest create a new company copying from your active company, and then perform that process and test in the copy. ( use UT-I )

anyway, just my thoughts.

Title: Re: Purging/archiving Question
Post by GasGiant on 12/09/09 at 06:03:15

In a table where your records are less than 1k ea (e.g. INVTXN) a couple of hundred MB is going to be a lot of records that have to be indexed and sorted through. Since DBA/Evo ave to read through that pile, especially when doing reports, the tiny bit of time it takes to do a read added to the tiny bit of latency in the network gets multiplied to become seconds, then minutes, and then grumpy users. Keeping your active records down to two years worth can add up to a couple of man-hours a week in time savings if you have twenty users. Each company must weigh for themselves this potential time savings against the time that might be lost going back into the archives when something older must be retrieved.