Re: GXR & GLH

Mark,

Let's take the two files one at a time.

First, the GXR file.  This is the Subsystem Cross Reference file and you may
or may not need its content.  This file helps you link back to the subystem
for any individual subsystem G/L entry.  This can be very helpful to help
you reconcile accounts or inquire into the G/L.  On the face of it, this
file would seam critical but the information in it may actually be
redundant.  With 6.04 macros, you can actually have all the information you
need to link to the subsystem written direcly to the GLH or GLA files. 
Therefore, if you are using the proper macros in your models, you probably
can purge the GXR file carefully and selectively.

Note: I think you are better off getting more disk space than deleting this
data.

Now on to the GLH file.  This file is central to your general ledger.  It is
the General Ledger line detail.  You definately need all the data in this
file for the current year and probably for the previous year.  However,
there are tho things you can do to save room.  First, you could post in
summary.  I don't like this approach because, you will lose the ability to
reconcile your accounts easily if you don't have the detail.  However, some
clients reconcile daily and have no need to go back to the detail.

Secondly, you could purge old history from this file.  Many companies do not
need to report results from over two years ago.  If this is the case, you
could selectively and carefully delete old info from the GLH, GHH, GLA, GSX,
GXR and GSB files for the old data.

Again, I would be very careful before I did any purging.  Of course you
should back everything up to tape or a separate server before doing anything
like this.  Consider data warehousing.

--Paul Holstein
iWork Software, L.L.C


On Fri, 12 May 2000 09:13:40 +0100, BPCS-L@midrange.com wrote:

>  6.0.04  HP-UX / Informix
>  
>  Folks,
>  
>  About 1/3rd of my total dB space (i.e. 6Gb of 18Gb) is taken up by two
>  tables, GXR & GLH and I have been informed by SSA that there are no purge
>  programs with BPCS for these tables.
>  
>  We have been running for around 13 months on 6.0.04 and whilst I can
still
>  accommodate these tables I need to put into place a long term strategy to
>  ensure that these tables do not just continue to grow.
>  
>  Has anyone out there had similar problems with these tables ?  If so did
you
>  get a solution out of SSA or write your own SQL to purge data from them ?
>  
>  Any help or assistance would be much appreciated.
>  
>  Regards
>  Mark Curtis
>  IT Director
>  Hafele U.K. Limited
>  Office : +44 (0)1788 542020
>  Direct : +44 (0)1788 548557
>  Fax    : +44 (0)1788 548599
>  Mobile : +44 (0)973 121135
>  email  : mailto:mark.curtis@hafele.co.uk
>  Web    : http://www.hafele.co.uk
>  
>  
>  
>  +---
>  | This is the BPCS Users Mailing List!
>  | To submit a new message, send your mail to BPCS-L@midrange.com.
>  | To subscribe to this list send email to BPCS-L-SUB@midrange.com.
>  | To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
>  | Questions should be directed to the list owner: dasmussen@aol.com
>  +---





_______________________________________________________
Get 100% FREE Internet Access powered by Excite
Visit http://freelane.excite.com/freeisp

+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---