Custom CR's from BAQ Report Designer

Yahoo Archive
1
Epicor technical support recommended applying the "K" patch as they
were aware of the report problem - we were on 8.03.305i.
I applied the "K" patch and now our BAQ based report performance
problems seem to have been fixed - reports running now as one would
expect.

Bill

--- In vantage@yahoogroups.com, "Ken Williams" <ken@...> wrote:
>
> Perhaps background was a better word :).
>
> I meant it seemed you had the knowledge of proper links and what not,
> and that it's likely a system/patch issue as opposed to something you're
> doing or not doing.
>
2
Is anyone actually using the BAQ Report Designer to create Crystal
reports from your BAQ's?

We have been banging our heads against the wall trying to get this
functionality to work and are ready to give up and resort to ODBC.
Except for the limitations of the BAQ query phrase, and the
idiosyncrasies of the UI tools, and the SLOOOOOWWWW performance of the
generated report, it works well :~)

A VERY simple BAQ based Crystal Report can take many minutes to run -
some chug along for an hour or more, while the same tables and joins
done in CR using ODBC will take SECONDS! I have tried many variations
of joins to hopefully optimize the query but without success MOST of
the time. I have also taken the same query phrase and ran from within
the OpenEdge procedure editor and it will take seconds. There seems
to be an inherent functionality problem between Crystal reports
created from the Vantage BAQ Report Designer.

What a bunch of crap!
3
Forgot to add... running Vantage 8.03.305i on OpenEdge 10.0B SP5.
4
We avoid ODBC like the plague. The largest BAQ report I've written dumped 80mb of data and took 20 minutes to process. Otherwise, all reports print in under a minute.

So, your issues:

1. BAQ query limitations. Every time I've thought I've hit a limitation, I've figured away around it. The only time I couldn't get BAQ query to properly combine what I needed, I dumped it all into Crystal and did the link there. Tell me more about your limitations and I can perhaps offer some tips.

2. Idiosyncrasies of the UI. Okay, you've got a great one there, I freaking hate the 48 steps to get everything working, but having made ~50-75 reports, I've finally 'mastered' these issues.

3.Slow performance. I'm curious about your queries and your system agent setup. The system agent can be set to x amount of time to look for print jobs. We have ours set to 30 seconds which seems perfectly adequate. If yours is set to a few minutes this is going to be huge. Are your queries properly linked to each other? If I setup a bad BAQ it can get stuck anywhere from minutes to hours depending on how bad I screwed up.

Post more details, I love the BAQ/Crystal setup now that I've practiced enough in it.


________________________________

From: vantage@yahoogroups.com on behalf of hoomail4me
Sent: Tue 1/15/2008 6:59 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Custom CR's from BAQ Report Designer



Forgot to add... running Vantage 8.03.305i on OpenEdge 10.0B SP5.






[Non-text portions of this message have been removed]
5
> We avoid ODBC like the plague. The largest BAQ report I've written
dumped 80mb of data and took 20 minutes to process. Otherwise, all
reports print in under a minute.
>


I tried like hell to avoid ODBC but it is so easy and run rings around
the performance of BAQ/CR.


> So, your issues:
>
> 1. BAQ query limitations. Every time I've thought I've hit a
limitation, I've figured away around it. The only time I couldn't get
BAQ query to properly combine what I needed, I dumped it all into
Crystal and did the link there. Tell me more about your limitations
and I can perhaps offer some tips.
>

Query phrase very limiting - one simple example of what couldn't be done:
FOR EACH partmtl NO-LOCK WHERE partmtl.fixedqty = NO OR
(partmtl.fixedqty = YES AND (INTEGER(partmtl.qtyper) / partmtl.qtyper
<> 1))


> 2. Idiosyncrasies of the UI. Okay, you've got a great one there, I
freaking hate the 48 steps to get everything working, but having made
~50-75 reports, I've finally 'mastered' these issues.
>


Too many to list - something as simple as changing a query phase after
is is built. Most of the time it is easier to start over.


> 3.Slow performance. I'm curious about your queries and your system
agent setup. The system agent can be set to x amount of time to look
for print jobs. We have ours set to 30 seconds which seems perfectly
adequate. If yours is set to a few minutes this is going to be huge.
Are your queries properly linked to each other? If I setup a bad BAQ
it can get stuck anywhere from minutes to hours depending on how bad I
screwed up.
>


System agent is set to 5 seconds.
I keep hearing this "Are the query joins correct..." in the message
threads I have found on this subject. I cannot say that ALL are
optimized but I have been writing Progress code for 10 years and never
had a problem with query/report performance. What could I possibly be
doing wrong all the time with BAQ queries for CR.


> Post more details, I love the BAQ/Crystal setup now that I've
practiced enough in it.
>

I like the concept but the implementation doesn't seem to work!
6
Well with your history, it seems like something else is going on.

I can tell you my BAQ's & CR's that use the BAQ's are extremely fast for the vast majority, the ones that are slow I'd expect to be slow from the vast amounts of data being dumped.

Sounds like a configuration issue somewhere along the way. Wish I could be of more help.

________________________________

From: vantage@yahoogroups.com on behalf of hoomail4me
Sent: Tue 1/15/2008 11:19 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Custom CR's from BAQ Report Designer



> We avoid ODBC like the plague. The largest BAQ report I've written
dumped 80mb of data and took 20 minutes to process. Otherwise, all
reports print in under a minute.
>

I tried like hell to avoid ODBC but it is so easy and run rings around
the performance of BAQ/CR.

> So, your issues:
>
> 1. BAQ query limitations. Every time I've thought I've hit a
limitation, I've figured away around it. The only time I couldn't get
BAQ query to properly combine what I needed, I dumped it all into
Crystal and did the link there. Tell me more about your limitations
and I can perhaps offer some tips.
>

Query phrase very limiting - one simple example of what couldn't be done:
FOR EACH partmtl NO-LOCK WHERE partmtl.fixedqty = NO OR
(partmtl.fixedqty = YES AND (INTEGER(partmtl.qtyper) / partmtl.qtyper
<> 1))

> 2. Idiosyncrasies of the UI. Okay, you've got a great one there, I
freaking hate the 48 steps to get everything working, but having made
~50-75 reports, I've finally 'mastered' these issues.
>

Too many to list - something as simple as changing a query phase after
is is built. Most of the time it is easier to start over.

> 3.Slow performance. I'm curious about your queries and your system
agent setup. The system agent can be set to x amount of time to look
for print jobs. We have ours set to 30 seconds which seems perfectly
adequate. If yours is set to a few minutes this is going to be huge.
Are your queries properly linked to each other? If I setup a bad BAQ
it can get stuck anywhere from minutes to hours depending on how bad I
screwed up.
>

System agent is set to 5 seconds.
I keep hearing this "Are the query joins correct..." in the message
threads I have found on this subject. I cannot say that ALL are
optimized but I have been writing Progress code for 10 years and never
had a problem with query/report performance. What could I possibly be
doing wrong all the time with BAQ queries for CR.

> Post more details, I love the BAQ/Crystal setup now that I've
practiced enough in it.
>

I like the concept but the implementation doesn't seem to work!






[Non-text portions of this message have been removed]
7
Well, I am not sure what you mean by "...with your history,.." but
Epicor has been working with me and they seem to think that patch 305K
(we are on 305i) should correct some of the performance issues if not
all. If something else is going on, Epicor has not been able to
isolate either - everything looks to be in place and configured to
standard practices.

Note: I don't think I was making a rash judgment as I have heard of
performance issue's from others, especially if a BAQ had more than a
few joins, but don't know now if it was related to a certain patch level.

I will hold judgement until more testing after the "K" patch.


--- In vantage@yahoogroups.com, "Ken Williams" <ken@...> wrote:
>
> Well with your history, it seems like something else is going on.
>
> I can tell you my BAQ's & CR's that use the BAQ's are extremely fast
for the vast majority, the ones that are slow I'd expect to be slow
from the vast amounts of data being dumped.
>
> Sounds like a configuration issue somewhere along the way. Wish I
could be of more help.
>
8
Perhaps background was a better word :).

I meant it seemed you had the knowledge of proper links and what not,
and that it's likely a system/patch issue as opposed to something you're
doing or not doing.

________________________________

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of hoomail4me
Sent: Wednesday, January 16, 2008 9:43 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Custom CR's from BAQ Report Designer



Well, I am not sure what you mean by "...with your history,.." but
Epicor has been working with me and they seem to think that patch 305K
(we are on 305i) should correct some of the performance issues if not
all. If something else is going on, Epicor has not been able to
isolate either - everything looks to be in place and configured to
standard practices.

Note: I don't think I was making a rash judgment as I have heard of
performance issue's from others, especially if a BAQ had more than a
few joins, but don't know now if it was related to a certain patch
level.

I will hold judgement until more testing after the "K" patch.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> , "Ken
Williams" <ken@...> wrote:
>
> Well with your history, it seems like something else is going on.
>
> I can tell you my BAQ's & CR's that use the BAQ's are extremely fast
for the vast majority, the ones that are slow I'd expect to be slow
from the vast amounts of data being dumped.
>
> Sounds like a configuration issue somewhere along the way. Wish I
could be of more help.
>






[Non-text portions of this message have been removed]
9
We had some serious performance problems with BAQ reports also. I
found a thread on this site that mentioned that support has two .r
files that they can send you that fixes the problem. I contacted
support and after going back and forth for almost a month, they
finally sent me the files.

After installing the new .r files my part master report went from 4
hours to less than a minute (with no changes to the BAQ).

Support kept trying to tell me that the perfomance issue was fixed in
400. However, we cannot go to 400 because of other programs and
timing.

I felt frustrated that I had to coax the files out of them. I must
have talked to three people, all of whom wanted me to go t0 400 and
seemed unwilling to look any further.

If you can get them to dig a little deeper they will find that the .r
files are backward compatible to 8.03.305h.

Just a "Heads Up"

Dave Olender
dolender@...


--- In vantage@yahoogroups.com, "hoomail4me" <hoomail4me@...> wrote:
>
> Well, I am not sure what you mean by "...with your history,.." but
> Epicor has been working with me and they seem to think that patch
305K
> (we are on 305i) should correct some of the performance issues if
not
> all. If something else is going on, Epicor has not been able to
> isolate either - everything looks to be in place and configured to
> standard practices.
>
> Note: I don't think I was making a rash judgment as I have heard of
> performance issue's from others, especially if a BAQ had more than a
> few joins, but don't know now if it was related to a certain patch
level.
>
> I will hold judgement until more testing after the "K" patch.
>
>
> --- In vantage@yahoogroups.com, "Ken Williams" <ken@> wrote:
> >
> > Well with your history, it seems like something else is going on.
> >
> > I can tell you my BAQ's & CR's that use the BAQ's are extremely
fast
> for the vast majority, the ones that are slow I'd expect to be slow
> from the vast amounts of data being dumped.
> >
> > Sounds like a configuration issue somewhere along the way. Wish I
> could be of more help.
> >
>
10
Hi Dave,

Out of interest what are the .r files names that you are referring
too...



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Dave Olender
Sent: Friday, January 18, 2008 8:05 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Custom CR's from BAQ Report Designer



We had some serious performance problems with BAQ reports also. I
found a thread on this site that mentioned that support has two .r
files that they can send you that fixes the problem. I contacted
support and after going back and forth for almost a month, they
finally sent me the files.

After installing the new .r files my part master report went from 4
hours to less than a minute (with no changes to the BAQ).

Support kept trying to tell me that the perfomance issue was fixed in
400. However, we cannot go to 400 because of other programs and
timing.

I felt frustrated that I had to coax the files out of them. I must
have talked to three people, all of whom wanted me to go t0 400 and
seemed unwilling to look any further.

If you can get them to dig a little deeper they will find that the .r
files are backward compatible to 8.03.305h.

Just a "Heads Up"

Dave Olender
dolender@... <mailto:dolender%40olenderconsulting.com>


--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"hoomail4me" <hoomail4me@...> wrote:
>
> Well, I am not sure what you mean by "...with your history,.." but
> Epicor has been working with me and they seem to think that patch
305K
> (we are on 305i) should correct some of the performance issues if
not
> all. If something else is going on, Epicor has not been able to
> isolate either - everything looks to be in place and configured to
> standard practices.
>
> Note: I don't think I was making a rash judgment as I have heard of
> performance issue's from others, especially if a BAQ had more than a
> few joins, but don't know now if it was related to a certain patch
level.
>
> I will hold judgement until more testing after the "K" patch.
>
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Ken Williams" <ken@> wrote:
> >
> > Well with your history, it seems like something else is going on.
> >
> > I can tell you my BAQ's & CR's that use the BAQ's are extremely
fast
> for the vast majority, the ones that are slow I'd expect to be slow
> from the vast amounts of data being dumped.
> >
> > Sounds like a configuration issue somewhere along the way. Wish I
> could be of more help.
> >
>



[Non-text portions of this message have been removed]
11
Dave,



Can you share those .r files?



Joe Rojas

Information Technology Manager

Symmetry Medical TNCO

15 Colebrook Blvd

Whitman MA 02382

781.447.6661 x7506



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Dave Olender
Sent: Friday, January 18, 2008 9:05 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Custom CR's from BAQ Report Designer



We had some serious performance problems with BAQ reports also. I
found a thread on this site that mentioned that support has two .r
files that they can send you that fixes the problem. I contacted
support and after going back and forth for almost a month, they
finally sent me the files.

After installing the new .r files my part master report went from 4
hours to less than a minute (with no changes to the BAQ).

Support kept trying to tell me that the perfomance issue was fixed in
400. However, we cannot go to 400 because of other programs and
timing.

I felt frustrated that I had to coax the files out of them. I must
have talked to three people, all of whom wanted me to go t0 400 and
seemed unwilling to look any further.

If you can get them to dig a little deeper they will find that the .r
files are backward compatible to 8.03.305h.

Just a "Heads Up"

Dave Olender
dolender@... <mailto:dolender%40olenderconsulting.com>


--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"hoomail4me" <hoomail4me@...> wrote:
>
> Well, I am not sure what you mean by "...with your history,.." but
> Epicor has been working with me and they seem to think that patch
305K
> (we are on 305i) should correct some of the performance issues if
not
> all. If something else is going on, Epicor has not been able to
> isolate either - everything looks to be in place and configured to
> standard practices.
>
> Note: I don't think I was making a rash judgment as I have heard of
> performance issue's from others, especially if a BAQ had more than a
> few joins, but don't know now if it was related to a certain patch
level.
>
> I will hold judgement until more testing after the "K" patch.
>
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Ken Williams" <ken@> wrote:
> >
> > Well with your history, it seems like something else is going on.
> >
> > I can tell you my BAQ's & CR's that use the BAQ's are extremely
fast
> for the vast majority, the ones that are slow I'd expect to be slow
> from the vast amounts of data being dumped.
> >
> > Sounds like a configuration issue somewhere along the way. Wish I
> could be of more help.
> >
>





[Non-text portions of this message have been removed]
12
Hi all,

I'm kind of jumping into the middle of your discussion about BAQs and
CRs with a different type of question.

We are currently on 6.1 and working towards our 8.03 conversion. We
have been discussing when to use BAQs? when to use dashboards? when
to use Crystal? or when to use BAQs with Crystal. Does anyone have
any clear/semi-clear idea on when to use which? I know that
Dashboards are good for when you don't want to print, but other than
that I don't clearly understand when I should use what design for
reports.

Ideas from all would be great.

Thanks,

Debbie Smith

debsmithmich@...
Argonics, Inc
(906) 869-2247
--- In vantage@yahoogroups.com, "Ken Williams" <ken@...> wrote:
>
> We avoid ODBC like the plague. The largest BAQ report I've written
dumped 80mb of data and took 20 minutes to process. Otherwise, all
reports print in under a minute.
>
> So, your issues:
>
> 1. BAQ query limitations. Every time I've thought I've hit a
limitation, I've figured away around it. The only time I couldn't
get BAQ query to properly combine what I needed, I dumped it all into
Crystal and did the link there. Tell me more about your limitations
and I can perhaps offer some tips.
>
> 2. Idiosyncrasies of the UI. Okay, you've got a great one there, I
freaking hate the 48 steps to get everything working, but having made
~50-75 reports, I've finally 'mastered' these issues.
>
> 3.Slow performance. I'm curious about your queries and your system
agent setup. The system agent can be set to x amount of time to look
for print jobs. We have ours set to 30 seconds which seems perfectly
adequate. If yours is set to a few minutes this is going to be
huge. Are your queries properly linked to each other? If I setup a
bad BAQ it can get stuck anywhere from minutes to hours depending on
how bad I screwed up.
>
> Post more details, I love the BAQ/Crystal setup now that I've
practiced enough in it.
>
>
> ________________________________
>
> From: vantage@yahoogroups.com on behalf of hoomail4me
> Sent: Tue 1/15/2008 6:59 PM
> To: vantage@yahoogroups.com
> Subject: [Vantage] Re: Custom CR's from BAQ Report Designer
>
>
>
> Forgot to add... running Vantage 8.03.305i on OpenEdge 10.0B SP5.
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
13
--- In vantage@yahoogroups.com, "Dave Olender" <dolender@...> wrote:
>
> We had some serious performance problems with BAQ reports also. I
> found a thread on this site that mentioned that support has two .r
> files that they can send you that fixes the problem. I contacted
> support and after going back and forth for almost a month, they
> finally sent me the files.
>
> After installing the new .r files my part master report went from 4
> hours to less than a minute (with no changes to the BAQ).
>
> Support kept trying to tell me that the perfomance issue was fixed
in
> 400. However, we cannot go to 400 because of other programs and
> timing.
>
> I felt frustrated that I had to coax the files out of them. I must
> have talked to three people, all of whom wanted me to go t0 400 and
> seemed unwilling to look any further.
>
> If you can get them to dig a little deeper they will find that
the .r
> files are backward compatible to 8.03.305h.
>
> Just a "Heads Up"
>
> Dave Olender
> dolender@...
>
>
> --- In vantage@yahoogroups.com, "hoomail4me" <hoomail4me@> wrote:
> >
> > Well, I am not sure what you mean by "...with your history,.." but
> > Epicor has been working with me and they seem to think that patch
> 305K
> > (we are on 305i) should correct some of the performance issues if
> not
> > all. If something else is going on, Epicor has not been able to
> > isolate either - everything looks to be in place and configured to
> > standard practices.
> >
> > Note: I don't think I was making a rash judgment as I have heard
of
> > performance issue's from others, especially if a BAQ had more
than a
> > few joins, but don't know now if it was related to a certain
patch
> level.
> >
> > I will hold judgement until more testing after the "K" patch.
> >
> >
> > --- In vantage@yahoogroups.com, "Ken Williams" <ken@> wrote:
> > >
> > > Well with your history, it seems like something else is going
on.
> > >
> > > I can tell you my BAQ's & CR's that use the BAQ's are extremely
> fast
> > for the vast majority, the ones that are slow I'd expect to be
slow
> > from the vast amounts of data being dumped.
> > >
> > > Sounds like a configuration issue somewhere along the way.
Wish I
> > could be of more help.
> > >
> >
>
BAQ reports had a real perfomance issue before version 803.305i. I
started complaining to Epicor in March of 2007 and it was not until
September they finally admitted the problem and sent me the .r
files. They tried to come up with all kinds of reasons the report
was slow but I just kept pressing them.

Yes, the ".r" files they are backward compatible to version "h". I
don't know about anything prior to that. Performance problems are
related to the underlying code and must be fixed by the programming
staff. That seems to take forever. There are still a few issues
with some of their built in reports as well that have not been fixed,
e.g. print inventory labels for a full inventory and see how log it
takes. Be prepared for a 3 - 4 hour wait for 15-20 thousand part
labels.