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

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.

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

Thanks Lynn, I hope they will use this information.
 
 
Val

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.
 

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

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.

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.