Sage 100

IM_ItemTransactionHistory File full Sage 100 Advanced 4.4.8 My customer has just filled IM_ItemTransactionHistory.M4T.015. Instead of kicking over to .016 we are getting an error that the file is full and shut down. Is anyone aware of a file size limitation?

Has .016 been created? If not, create a test company, and using the test company data, navigate to LM, reinitialize data files, then click ""manual"" to manually create an empty .016. I do not believe there is a file size limit as 4.4 uses the enhanced file format. There may be an issue in the file creation routine. Also, make sure the hard drive is not full.

There is a 2Gig file size limit on the Business Framework files. When a files reaches somewhere between 1.6 - 1.8 Gigs the file should extend into another file which is linked to the main. But the main file is still the primary file of concern, like importing and creating crystal reports. Hope that helps

I predict these type issues are going to be more common in the future!!

@JoanSerr - Once a data file hits the 2GB limit, a ""companion"" data file is created. The first newly created data file will have an .001 extension (IM_ItemTransactionHistory.M4T.001). When "".001"" reaches 2GB then "".002"" will be created, and so on. Theoretically the limitation for a file would be 2 terabytes (1000 linked companion files atof 2GB each, ie IM_ItemTransactionHistory.M4T.999). This ""theoretical"" limitation is not a ProvideX file limitation but a ""code"" limitation. There is most likely no constraints on extending the file naming convention to 4, 5, or more decimal places, ie .0001 or .00001. Great question for Mike King.

So Harold you have 32GB's on item transaction history. WOW. that is alot. Does that seem reasonable? if not you may have some data corruption.

Yes, they average 77,000 sales invoices per week . Since Inventory control is actually handled in a legacy system, I cant speculate how that translates to purchasing and inventory transactions but everything is imported.

@HaroldWestover - Please post the eventual solution when you get it resolved. Also, do the end users use the data to view or create meaningful reports? If so, how is the performance? Given the number of transactions, this would be a candidate for Sage 100 ERP Premium. If the data is not used, why not purge some once in a while?

Doug maybe on to something with the corruption thought. It could be that in the prior file there is a corrupt record preventing the creation of the next file sequence. DFDM to the main file and go to the last record and using the VCR buttons scroll back to make sure you can and that the last record is not corrupt or damaged. Also regarding space, (but not related to this issue), the available space on the C drive is crucial since MAS utilizes the Temp file on the C anytime utilities or updates are carried out. Good rule of thumb is to have enough space to support at least 3x the file size you are trying to perform the task on. That is just a FYI.

Here is what Sage support says to do - Sage Case # 8003053683. Haven't tried it yet. Customer is reluctant to purge what they consider good data. Double check available disk space on the server. (500 GB available) Restore the original IM transaction history files and eliminate or move the new file they created out of the IM company folder. Then review the process below as a possible solution: 1. Purge history from IM5 with the purge option in I/M Period End Processing. * Select the Only Remove Transaction Detail option. * Select a date far enough in the past to avoid affecting recent transactions. The default date is within the current period. 2. They have missing transaction history due to creating a new file. To address this, restore the entire system to another directory. Login and enter one of the transactions to ensure the file is full does not occur. Then enter the remaining missing transactions. Ensure no one is in the production during this time or not entering IM transactions. 3. Once step 3 is complete, copy the IM transaction history files into the production and they should be able to continue.

LOL - this is the type of advice you get from people who've never worked in the field, at a customer or installed a system.

RE Wayne's comments: Is it really too much to ask? Every day I seem to have to lower my expectations when it comes to quality, care and service. I might have asked the analyst then why the 3 digit file extension value if only allowed to go to 15. (Oy, I digress)

This is a good question for the ProvideX people on whether an Error 2 (""file full"") occurs by design when reading a 17th segment (.m4t to .015 are the 1st 16) in a multi-segmented file. I'm pretty sure only they would know. I've never heard of a limitation here but wouldn't be surprised as 16 is kind of magic limit number in pvx anyway. E.g. in v2013 AR_InvoiceHistoryHeader has 1 primary key + 14 alternate keys / indexes. Sage can only add 1 more for the future. @HaroldWestover - Not sure if it was mentioned already above but have you tried Rebuild Key Files yet? Since 4.40 RKF should be able to rebuild segmented files. But make a backup of main file + all segments first and run it night as it will be time consuming.

@HaroldWestover My money is on @AlnoorCassim theory of the number 16. I would suggest requesting that the case be escalated to a knowledgeable tech person. I think Sage still has one or two. Perhaps Steffen Urban since we chatted with him last week.

The maximum number of segments varies by data file. ProvideX determines the number of segments based on the Block Size of the file. For Sage 100 ERP, most of the files have a 4K block size which allows for 16 segments. Also, the MB parameter is set to 1800 so that files segment somewhere around 1.8 gig. This allows some leeway before the segment hits the 2 gig limit. The recommendation would be for the customer to purge some records from the file if possible. (maybe copy the current data to a ""archive"" company?). Here is a chart that shows the Block Size and Segments for ProvideX VLR files: Block SizeSegmentsBlock SizeSegmentsBlock SizeSegments 31K12430K12029K116 28K11227K10826K104 25K10024K9623K92 22K8821K8420K80 19K7618K7217K68 16K6415K6014K56 13K5212K4811K44 10K409K368K32 7K286K245K20 4K163K122K8 1K4 @HaroldWestover - You are maxed out.

If @HaroldWestover could move his client to SQL, would this be an issue?

Sage 100 ERP Premium does not have the ProvideX file size limitations. Moving his client to Premium is an option, however, keep in mind the non framework modules are not available in premium.