Sage 100

 View Only
Expand all | Collapse all

On 2015 PU2 SQL a V/I import into A/P Manual Check

  • 1.  On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-26-2016 11:02
      |   view attached
    On 2015 PU2 SQL a V/I import into A/P Manual Check Entry with G/L Distribution bogs down with attached error when it gets to Record 4071 from the source file which has 4156 rows. The screenshot say Rec No 12,213 because it's multiplying by 3 as it's counting Header + Line + Tier Dist. The other source file with 1,500 rows imports fine. I found out what's going is the import has reached a ProvideX system limit of 32,768 open files. That is these memory files are being opened during the import (which is faster than using a temp file or temp table so that is good) but for each check imported, it opens a new set of memory files instead of re-using the existing ones. Eventually hits the limit as more checks are imported. Now that may be the design of V/I or the design of AP Manual Check Entry code but I don't recall ever running into this with V/I definitely other places in MAS). Has anyone ever run into this issue?


  • 2.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-26-2016 12:20
    Unless this is one check with 4156 GL distribution lines, easiest fix will be to split your import into two batches. But that just addresses the symptom. I am also going to guess you don't have any perform logic that is opening MEMORY files and not cleaning up.


  • 3.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-26-2016 13:08
    Hey Randy thanks for the reply. I did end up telling them to split the file. Of course they didn't like it. I did have a Perform in there but wasn't opening any MEMORY channels. It took it out anyway but still made no difference. It looks like with MC Entry where there's an invoice with G/L Distribution, we run into the open file limit faster than in other data entry scenarios. BTW for debugging in case you ever wanted to know how to get the number of files currently open it's LEN(CHN)/2 - 1


  • 4.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-26-2016 16:45
    Have run into this many times before, only solution was smaller files.


  • 5.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-26-2016 17:33
    Thanks for sharing that Greg - feel better to know somebody else ran into this as well.


  • 6.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-27-2016 05:48
    Seems clear there is a bug in the process and I expect will effect other imports than just AP Manual checks. Alnoor - thanks for the tip on # of files open


  • 7.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-27-2016 06:38
    Is only in the Premium version or will happen in all version?


  • 8.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-27-2016 08:06
    Agreed Randy. I think it's likely to occur sooner in objects that have the ""T"" tier distribution type. What's also interesting is let's say you hit the Test button and test 200 records and find from that 500 file channels were opened. After Test completes they're still open, not cleaned up. Click Accept now and you start with 501. I'll have to take a closer look at some point. Jeff it's not specific to the Premium version.


  • 9.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-27-2016 09:09
    @AlnoorCassim - did you bother opening a case with this?


  • 10.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-27-2016 09:22
    Jeff - No. This was done for a new 90 Minds partner not my company's client. However the client DOES want a Sage case created so the partner will do that.


  • 11.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-27-2016 09:27
    Can you post the case ID number back here when created so others can pile on??


  • 12.  RE: On 2015 PU2 SQL a V/I import into A/P Manual Check

    Posted 01-27-2016 11:49
    Going back through my notes I may have run into this and not realized it... the workstation did not have a ton of memory and when it puked, I wrote it off to running out of memory... now I wonder if that memory leak wasn't MEMORY files piling up and tying up all the resources....