I would be happy if I could return even a fraction of the help I've received from the group! I really wish I could attend Epicor's convention sometime, I'd LOVE to meet some of the people in this group. Too bad the company I work has so many policies from the dark ages, they refuse to see any value in something like that. However, I'm very grateful I have this user group and it doesn't cost the company a penny!!!
Sue
Sue
--- In vantage@yahoogroups.com, "jplehr" <jlehr@...> wrote:
>
> Sue,
>
> First, great to hear you have this working.
>
> Second, I think your follow-up is great for the group. We need more of this type of communication. So many times I see an answer that sounds promising, but you never hear how it worked out or if it had to be tweaked. Or, you never see a solid answer and you always wonder if the issue was resolved by another avenue. I am guilty of this myself.
>
> Thanks for sharing.
>
> Jeff
>
> --- In vantage@yahoogroups.com, "snielsen28" <snielsen.hipco@> wrote:
> >
> > I found a way to get my BAQ to work in Epicor 9. I found an entry in the server log that said "More than 4000 items in a single statement. Use the -tok parameter." I found an answerbook on EpicWeb for the same error message when running a BPM. It was AnswerBook# 12542MPS and said:
> >
> > PROBLEM RESOLUTION:
> > 1. Navigate to epicor904 or epicor905\server\config depending on your version and open the mfgsys.pf file in notepad
> > 2. Locate the -tok parameter and double the current value (ex if it is set to 3000 increase it to 6000) - there isn't a maximum value that can be set, the limitation is with the amount of RAM on the server
> > 3. You will need to restart your appservers before the new setting takes affect
> > 4. Try to create your new BPM after logging back into the database
> >
> > I played around with that parameter. If I set it too high, I got the message "REPLACE/CONCAT may not result in data > 32000 bytes." I searched around and found out the -tok parameter is the number of tokens per statement and each word or special character (such as parenthesis, plus sign, and minus sign) counts as one token. I trimmed all excess from my BAQ (got rid of parenthesis for documentation purposes only, etc.) and was able to get it to run by setting the -tok parameter at 7000 (the default was 4000). I'm not sure why the same BAQ didn't exceed the token limit of 4000 in Vantage, apparently Epicor 9 is "wordier"? I also don't know if increasing the tok parameter will cause any degraded performance issues when all users are on Epicor 9, now it's just me on the test server.
> >
> > Thought I'd report my findings in the hopes that it will help someone else out :)
> >
> > Sue
> > --- In vantage@yahoogroups.com, "snielsen28" <snielsen.hipco@> wrote:
> > >
> > > We're Progress. I may toss this over to support and see what they make of it. I appreciate the verification that there do appear to be some limitations working with BAQs.
> > >
> > > --- In vantage@yahoogroups.com, "Vic Drecchio" <vic.drecchio@> wrote:
> > > >
> > > > Sue, I’ve hit the virtual ceiling on BAQs in the past. Although I have no confirmation, I’ve “heard†there are query-length limitations...... so an “If-Then-Else†limitation wouldn’t surprise me either.
> > > >
> > > > Any chance you’re a SQL customer (vs Progress db)? If so, let me know.
> > > >
> > > > From: snielsen28
> > > > Sent: Tuesday, April 17, 2012 4:10 PM
> > > > To: vantage@yahoogroups.com
> > > > Subject: [Vantage] BAQ calculated field limitation?
> > > >
> > > >
> > > > I'm testing BAQs in Epicor 9.05.607B. I'm having trouble with a couple of calculated fields in BAQs that are working fine in Vantage 8.03.409A. The BAQs are used in a dashboard to tell HR when an employee may be reaching his PTO max or needs to have his PTO accrual rate changed. A version of the 1st problem BAQ that works in Epicor 9 reads:
> > > >
> > > > If CalcWorkYears > 23 Then 6.16 Else If CalcWorkYears > 20 Then 5.85 Else If CalcWorkYears > 17 Then 5.54 Else If CalcWorkYears > 14 Then 5.24 Else If CalcWorkYears > 11 Then 4.93 Else If CalcWorkYears > 8 Then 4.62 Else 2
> > > >
> > > > However, if I add one more else-if-then so it reads:
> > > >
> > > > If CalcWorkYears > 23 Then 6.16 Else If CalcWorkYears > 20 Then 5.85 Else If CalcWorkYears > 17 Then 5.54 Else If CalcWorkYears > 14 Then 5.24 Else If CalcWorkYears > 11 Then 4.93 Else If CalcWorkYears > 8 Then 4.62 Else If CalcWorkYears > 0 THEN 3.08 Else 2
> > > >
> > > > I receive the informative message "Text Business Execution error. Please contact your System Administrator." No problems with syntax.
> > > >
> > > > The same thing happens if I use parenthesis:
> > > > (If (CalcWorkYears > 23) Then 6.16 Else (If (CalcWorkYears > 20) Then 5.85 Else (If (CalcWorkYears > 17) Then 5.54 Else (If (CalcWorkYears > 14) Then 5.24 Else (If (CalcWorkYears > 11) Then 4.93 Else (If(CalcWorkYears > 8) Then 4.62 Else (If (CalcWorkYears > 0) Then 3.08 Else 2)))))))
> > > >
> > > > The 2nd problem calculated field stops working even sooner:
> > > > (If (CalcWorkYears > 24) Then 320 else (If (CalcWorkYears > 23) Then 312 Else (If (CalcWorkYears > 21) Then 304 Else (If (CalcWorkYears > 20) Then 296 Else (If (CalcWorkYears > 18) Then 288 Else (If (CalcWorkYears > 17) Then 280 Else (If (CalcWorkYears > 15) Then 272 Else (IF (CalcWorkYears > 14) Then 264 Else (If (CalcWorkYears > 12) then 256 Else (IF (CalcWorkYears > 11) Then 248 Else (If (CalcWorkYears > 9) Then 240 Else (If (CalcWorkYears > 8) Then 200 Else (If (CalcWorkYears > 1) Then 160 Else (If (CalcWorkYears > 0) Then 120 Else 40))))))))))))))
> > > >
> > > > That one won't go past the 3rd If-Then-Else. It seems to be related to comparison to another calculated field. I can substitute a value or a field for the calculated field (CalcWorkYears) and don't receive the error. Does anyone know if there's some kind of limitation on using calculated fields in IF-THEN-ELSE statements? The calculated fields are defined as signed decimal fields that are larger than any of the values. The CalcWorkYears field is a signed integer field that is larger than any of the values. It seems from searching the user group that E9 BAQs are pickier than Vantage BAQs which may explain why the same BAQs work fine there. I've tried everything I can think of...I'm hoping someone will point me in the right direction. Maybe I need to put the values in a UD table instead of hardcoding them into the BAQ. Any ideas?
> > > >
> > > > Sue
> > > >
> > > >
> > > >
> > > >
> > > > No virus found in this message.
> > > > Checked by AVG - www.avg.com
> > > > Version: 2012.0.1913 / Virus Database: 2411/4942 - Release Date: 04/17/12
> > > >
> > > >
> > > > [Non-text portions of this message have been removed]
> > > >
> > >
> >
>