File sizes -

Afternoon people,

Reviewing our backups. Finding (in my opinion) files that are too large.And needing some understanding of the below:

Anybody know why there are several copies of this file in our BKY company, and why they are almost 2gb?

Our other companies do not have multiple copies, but they are the same size.

Is this an indexing issue? 1gb is still an awful big file for a database table.

Thanks

  • 0
    SUGGESTED

    There are likely 2 issues: (1) what are the files and (2) the amount of data that has caused the original data file to grow so large it created these other segmented files.

    (1) Some explanation on those segmented files from Sage Knowledgebase article 224924750069488 "There are segmented data files for some data files":

    "There’s a limitation on Sage 100 data file size of about 2 GB in size.  One or more segmented files are generated automatically upon reaching this size limit. The segmented files are extensions of the original file, with the same fields and file structure. 

    If a segmented file takes up to 2 GB of space, an internal process creates an additional segmented file. This process repeats for each file segment reaching the size limit.

    • Example:
      1. IM_ItemTransactionHistory.M4T
      2. IM_ItemTransactionHistory.M4T.001
      3. IM_ItemTransactionHistory.M4T.002, etc."

    (2) The amount of raw data for most files gets so large due to data not being purged - like the Invoice History file, etc.  In your case, this is the AP Check History Header table which possibly contains millions of records due to skipped or voided check numbers.  (The system will keep track of all the check numbers in between if check numbers are skipped). If you are familiar with using Data File Display and Maintenance, you can view the AP_checkhistoryheader.M4T file and would likely see millions of blank/voided checks - unless you actually are using millions of AP checks.

    You could reach out to your Sage Partner for assistance with purging or removing these voided checks and possibly shrinking down these files.

    If this suggested answer helped, please mark it as verified White check mark 
    (Click the "…" button next to Reply)

  • 0 in reply to DGR

    This is greatly appreciated. We will start investigating.

  • +1
    verified answer

    Take a look at check history.  There are probably a ton of fake Void payment records, created automatically by someone posting a journal during a check number sequence change. I have seen literally millions of rows added to check history, without significant warning (just a line of text on the journal) during the posting process.

    (Sage has a utility to purge void checks).