8.0 Production Detail

Yahoo Archive
1
Many great ideas for a work around! What is frustrating is that Epicor
should re-write the report!! Isn't there a way for this user group to put
collective pressure on Epcior since we are all experiencing the problem?



_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Andrei Prodan
Sent: Thursday, January 24, 2008 7:51 AM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] 8.0 Production Detail

If you're running SQL skipping the middle-man and running ODBC directly
on SQL Server is at least an order of magnitude faster than going
through Progress (on smaller datasets).

My times were 40 minutes for the generation of a very large Production
Detail report using BAQ - this is still almost twice as fast as the
standard report - running the same on ODBC directly with SQL Server, on
a dataset twice the size did the job in *cough* 0.300 seconds.

I assumed this would be because of the XML conversion, but it's not, I
wrote a quick C# app that read 15 MB of data using the same query (.300
one), and wrote them to XML (SQL Server can do it directly, but I chose
the slower path intentionally) and this took some 5-10 seconds on my
development computer. The resulting XML was a near perfect replica of
the one Vantage generates, and fully compatible with Crystal.

Note that these queries were not the original Vantage report, but my own
Detailed Production Report.

Conclusion is - Progress is not terribly fast.

I eventually remade the BAQ with far fewer fields in it, and it runs
fast enough now - but if you need a very large report, avoid going
through Progress.

Please note that I did not ever test Progress directly - so this
conclusion is only an educated guess - the only information I have is
that the XML file gets generated after 40 minutes or more, while SQL
server is doing nothing and could generate that data in less than 5
seconds.

We only use ODBC access for reports that need unions or for extremely
large datasets - using a specialized reader user with access only to the
needed tables.

Andrei

Posted by: "Gary Parfrey" garyp@dotnetit. <mailto:garyp%40dotnetit.co.uk>
co.uk
<mailto:garyp@dotnetit. <mailto:garyp%40dotnetit.co.uk>
co.uk?Subject=%20Re%3A%208%2E0%20Production%20Det
ail> gparfrey <http://profiles. <http://profiles.yahoo.com/gparfrey>
yahoo.com/gparfrey>

Wed Jan 23, 2008 4:08 pm (PST)

Rewrite the report in Crystal using ODBC. Runs in seconds/minutes
instead of minutes/hours

Posted by: "Jason Claggett" jason@2wtech. <mailto:jason%402wtech.com> com
<mailto:jason@2wtech. <mailto:jason%402wtech.com>
com?Subject=%20Re%3A%208%2E0%20Production%20Detail>
jason_claggett <http://profiles. <http://profiles.yahoo.com/jason_claggett>
yahoo.com/jason_claggett>

Wed Jan 23, 2008 9:09 pm (PST)

Gary,

While this might be faster/better. I don't agree with this practice. In
the past, yes, this was the only way to do it, however, now with BAQs
and the ability to create your own datasets within Vantage someone with
a little time could create a dataset that only has the information
needed.

****************************************************************************
****************************************************************************
****************************************************************************
*******************************************
This email is intended for the addressee only and may contain information
that is privileged and confidential. If you are not the intended recipient,
you must not copy, distribute or take any
action in reliance on it. If this email has been sent to you in error,
please notify us immediately by telephone.
This has been transmitted by -

Planned Storage Systems Ltd
Murdock Road
Dorcan Industrial Estate
Swindon

SN3 5HY

Company Registration No: 01028915.

The views within this email are those of the author and not
necessarily those of Planned Storage Systems Ltd.

** This email has been scanned for viruses, vandals and malicious content **
****************************************************************************
****************************************************************************
****************************************

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



[Non-text portions of this message have been removed]
2
As with most other Crystal reports in Vantage 8.x, the Production
Detail is dreadfully slow. I understand why it's slow as there are
a ton of tables to retrieve data from to generate the report. This
is a key step for us in monthly job closings. Typically we run
around 1200 jobs per month and each one is reviewed first by the
department supervisor as a candidate. That is to determine that all
materials were issued correctly and the proper amount of labor was
recorded. Following that, there is an accounting overcheck, to
assure that all the job costs and AR numbers are accurate. So at
1200 job per month the total time spent waiting for the reports for
each of the two step process is about 40 minutes. At 30 seconds
each, the time goes to 10 hours. We've submitted our db to Epicor
and the performance is the same. So it is not a hardware issue or
server settings. Their response was ". . .we are seeing the same
times to preview and that is not unusual. . ."
I am running 8.03.400 in this testing - one of the major differences
in that 400 release/service pack was to improve Crystal run time.

Suggestions anyone?

Thanks!
3
So you don't see a change in the speed from .305 to .403?



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of stanchmura
Sent: Wednesday, January 23, 2008 8:42 AM
To: vantage@yahoogroups.com
Subject: [Vantage] 8.0 Production Detail



As with most other Crystal reports in Vantage 8.x, the Production
Detail is dreadfully slow. I understand why it's slow as there are
a ton of tables to retrieve data from to generate the report. This
is a key step for us in monthly job closings. Typically we run
around 1200 jobs per month and each one is reviewed first by the
department supervisor as a candidate. That is to determine that all
materials were issued correctly and the proper amount of labor was
recorded. Following that, there is an accounting overcheck, to
assure that all the job costs and AR numbers are accurate. So at
1200 job per month the total time spent waiting for the reports for
each of the two step process is about 40 minutes. At 30 seconds
each, the time goes to 10 hours. We've submitted our db to Epicor
and the performance is the same. So it is not a hardware issue or
server settings. Their response was ". . .we are seeing the same
times to preview and that is not unusual. . ."
I am running 8.03.400 in this testing - one of the major differences
in that 400 release/service pack was to improve Crystal run time.

Suggestions anyone?

Thanks!





[Non-text portions of this message have been removed]
4
Hi Stan,
> As with most other Crystal reports in Vantage 8.x, the Production
> Detail is dreadfully slow. I understand why it's slow as there are
> a ton of tables to retrieve data from to generate the report. This
> is a key step for us in monthly job closings. Typically we run
> around 1200 jobs per month and each one is reviewed first by the
> department supervisor as a candidate. That is to determine that all
> materials were issued correctly and the proper amount of labor was
> recorded. Following that, there is an accounting overcheck, to
> assure that all the job costs and AR numbers are accurate. So at
> 1200 job per month the total time spent waiting for the reports for
> each of the two step process is about 40 minutes. At 30 seconds
> each, the time goes to 10 hours.
...
> Suggestions anyone?

If this was a manufacturing problem, what would you do? Why wait until the end
of the month to do this work? Why not weekly or even daily? Sure, the
aggregate time for the reports will still take ten hours but spread out over
20+ days. The other benefit is that department supervisors won't have to
remember what happened three or four weeks ago to follow up on a job
exception.

Better yet, why run the Production Detail Report for jobs that don't have any
issues? You could create a BAQ that looks at the JobAsmbl table to find
candidates for review and then just print the production detail report for
those.

Mark W.
5
We had a similar problem when we went from 6.1 to 8.03. Our costing
people were using the report basically to look for zeros indicating
missing material cost. Due to the complexity of our products the
Production Detail report was often 200 pages long. After sitting down
with the users and finding out how they were using the reports, I
created a couple simple BAQ's and added them to our own version of the
Job Status Tracker. Now they get their information much quicker and
don't need to look through all the lines that don't have problems.



Mark



________________________________

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of stanchmura
Sent: Wednesday, January 23, 2008 7:42 AM
To: vantage@yahoogroups.com
Subject: [Vantage] 8.0 Production Detail



As with most other Crystal reports in Vantage 8.x, the Production
Detail is dreadfully slow. I understand why it's slow as there are
a ton of tables to retrieve data from to generate the report. This
is a key step for us in monthly job closings. Typically we run
around 1200 jobs per month and each one is reviewed first by the
department supervisor as a candidate. That is to determine that all
materials were issued correctly and the proper amount of labor was
recorded. Following that, there is an accounting overcheck, to
assure that all the job costs and AR numbers are accurate. So at
1200 job per month the total time spent waiting for the reports for
each of the two step process is about 40 minutes. At 30 seconds
each, the time goes to 10 hours. We've submitted our db to Epicor
and the performance is the same. So it is not a hardware issue or
server settings. Their response was ". . .we are seeing the same
times to preview and that is not unusual. . ."
I am running 8.03.400 in this testing - one of the major differences
in that 400 release/service pack was to improve Crystal run time.

Suggestions anyone?

Thanks!





[Non-text portions of this message have been removed]
6
You can also use the Job Comlpete/Closing process to search for issues.


Edward F. Fox, Jr., CPA

Controller

Maxson Automatic Machinery Company

Phone 401-596-0162 a Fax 401-596-1050

www.maxsonautomatic.com <http://www.maxsonautomatic.com/>



_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Mark Tellefson
Sent: Wednesday, January 23, 2008 9:36 AM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] 8.0 Production Detail



We had a similar problem when we went from 6.1 to 8.03. Our costing
people were using the report basically to look for zeros indicating
missing material cost. Due to the complexity of our products the
Production Detail report was often 200 pages long. After sitting down
with the users and finding out how they were using the reports, I
created a couple simple BAQ's and added them to our own version of the
Job Status Tracker. Now they get their information much quicker and
don't need to look through all the lines that don't have problems.

Mark

________________________________

From: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
[mailto:vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com] On
Behalf
Of stanchmura
Sent: Wednesday, January 23, 2008 7:42 AM
To: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
Subject: [Vantage] 8.0 Production Detail

As with most other Crystal reports in Vantage 8.x, the Production
Detail is dreadfully slow. I understand why it's slow as there are
a ton of tables to retrieve data from to generate the report. This
is a key step for us in monthly job closings. Typically we run
around 1200 jobs per month and each one is reviewed first by the
department supervisor as a candidate. That is to determine that all
materials were issued correctly and the proper amount of labor was
recorded. Following that, there is an accounting overcheck, to
assure that all the job costs and AR numbers are accurate. So at
1200 job per month the total time spent waiting for the reports for
each of the two step process is about 40 minutes. At 30 seconds
each, the time goes to 10 hours. We've submitted our db to Epicor
and the performance is the same. So it is not a hardware issue or
server settings. Their response was ". . .we are seeing the same
times to preview and that is not unusual. . ."
I am running 8.03.400 in this testing - one of the major differences
in that 400 release/service pack was to improve Crystal run time.

Suggestions anyone?

Thanks!

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






[Non-text portions of this message have been removed]
7
Rewrite the report in Crystal using ODBC. Runs in seconds/minutes
instead of minutes/hours



I have written versions of it for clients in the past

Gary Parfrey

Dot Net IT Limited, Reg No 4412519

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of stanchmura
Sent: 23 January 2008 13:42
To: vantage@yahoogroups.com
Subject: [Vantage] 8.0 Production Detail



As with most other Crystal reports in Vantage 8.x, the Production
Detail is dreadfully slow. I understand why it's slow as there are
a ton of tables to retrieve data from to generate the report. This
is a key step for us in monthly job closings. Typically we run
around 1200 jobs per month and each one is reviewed first by the
department supervisor as a candidate. That is to determine that all
materials were issued correctly and the proper amount of labor was
recorded. Following that, there is an accounting overcheck, to
assure that all the job costs and AR numbers are accurate. So at
1200 job per month the total time spent waiting for the reports for
each of the two step process is about 40 minutes. At 30 seconds
each, the time goes to 10 hours. We've submitted our db to Epicor
and the performance is the same. So it is not a hardware issue or
server settings. Their response was ". . .we are seeing the same
times to preview and that is not unusual. . ."
I am running 8.03.400 in this testing - one of the major differences
in that 400 release/service pack was to improve Crystal run time.

Suggestions anyone?

Thanks!





[Non-text portions of this message have been removed]
8
Gary,



While this might be faster/better. I don't agree with this practice. In
the past, yes, this was the only way to do it, however, now with BAQs
and the ability to create your own datasets within Vantage someone with
a little time could create a dataset that only has the information
needed.



Why this is a problem? Epicor could come out with a patch that moves a
field or changes a table around and then you have to figure out why your
report no longer works (often a call to Epicor support) and then modify
your report.



Don't get me wrong...the "out of the box" production detail report is
not blazing fast, but this is not the way to go about the solution - in
my own opinion. I would find a way to create my own dataset and create a
custom BAQ that ran the report just as fast.



Just offering a different approach.





Jason Claggett

Microsoft Small Business Specialist

MCP #3856159

2W Technologies, LLC

312.533.4033 x8039

jason@...



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Gary Parfrey
Sent: Wednesday, January 23, 2008 7:08 PM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] 8.0 Production Detail





Rewrite the report in Crystal using ODBC. Runs in seconds/minutes
instead of minutes/hours

I have written versions of it for clients in the past

Gary Parfrey

Dot Net IT Limited, Reg No 4412519

From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf
Of stanchmura
Sent: 23 January 2008 13:42
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Subject: [Vantage] 8.0 Production Detail

As with most other Crystal reports in Vantage 8.x, the Production
Detail is dreadfully slow. I understand why it's slow as there are
a ton of tables to retrieve data from to generate the report. This
is a key step for us in monthly job closings. Typically we run
around 1200 jobs per month and each one is reviewed first by the
department supervisor as a candidate. That is to determine that all
materials were issued correctly and the proper amount of labor was
recorded. Following that, there is an accounting overcheck, to
assure that all the job costs and AR numbers are accurate. So at
1200 job per month the total time spent waiting for the reports for
each of the two step process is about 40 minutes. At 30 seconds
each, the time goes to 10 hours. We've submitted our db to Epicor
and the performance is the same. So it is not a hardware issue or
server settings. Their response was ". . .we are seeing the same
times to preview and that is not unusual. . ."
I am running 8.03.400 in this testing - one of the major differences
in that 400 release/service pack was to improve Crystal run time.

Suggestions anyone?

Thanks!

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





[Non-text portions of this message have been removed]
9
Jason



I don't directly disagree with your comment,



If Epicor change the schema, you still may need to change the BAQ,
Editing BAQ's is buggy as hell (Especially in 803.400).



If you learn't your table structures, this would be less of a problem.



I definitely do not think that BAQ reports is there yet.



The poster asked for suggestion of why this report takes so long, and
how he can get a report that takes a small percentage of the time. This
was one.



I definitely do not think that BAQ's and BAQ reports are there yet,
performance or flexibility. If they were I would 100% agree with your
comments



Gary



From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Jason Claggett
Sent: 24 January 2008 05:10
To: vantage@yahoogroups.com
Subject: RE: [Vantage] 8.0 Production Detail



Gary,

While this might be faster/better. I don't agree with this practice. In
the past, yes, this was the only way to do it, however, now with BAQs
and the ability to create your own datasets within Vantage someone with
a little time could create a dataset that only has the information
needed.

Why this is a problem? Epicor could come out with a patch that moves a
field or changes a table around and then you have to figure out why your
report no longer works (often a call to Epicor support) and then modify
your report.

Don't get me wrong...the "out of the box" production detail report is
not blazing fast, but this is not the way to go about the solution - in
my own opinion. I would find a way to create my own dataset and create a
custom BAQ that ran the report just as fast.

Just offering a different approach.

Jason Claggett

Microsoft Small Business Specialist

MCP #3856159

2W Technologies, LLC

312.533.4033 x8039

jason@... <mailto:jason%402wtech.com>

From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ] On
Behalf
Of Gary Parfrey
Sent: Wednesday, January 23, 2008 7:08 PM
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
Subject: RE: [Vantage] 8.0 Production Detail

Rewrite the report in Crystal using ODBC. Runs in seconds/minutes
instead of minutes/hours

I have written versions of it for clients in the past

Gary Parfrey

Dot Net IT Limited, Reg No 4412519

From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com>
[mailto:vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com> ] On
Behalf
Of stanchmura
Sent: 23 January 2008 13:42
To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
<mailto:vantage%40yahoogroups.com>
Subject: [Vantage] 8.0 Production Detail

As with most other Crystal reports in Vantage 8.x, the Production
Detail is dreadfully slow. I understand why it's slow as there are
a ton of tables to retrieve data from to generate the report. This
is a key step for us in monthly job closings. Typically we run
around 1200 jobs per month and each one is reviewed first by the
department supervisor as a candidate. That is to determine that all
materials were issued correctly and the proper amount of labor was
recorded. Following that, there is an accounting overcheck, to
assure that all the job costs and AR numbers are accurate. So at
1200 job per month the total time spent waiting for the reports for
each of the two step process is about 40 minutes. At 30 seconds
each, the time goes to 10 hours. We've submitted our db to Epicor
and the performance is the same. So it is not a hardware issue or
server settings. Their response was ". . .we are seeing the same
times to preview and that is not unusual. . ."
I am running 8.03.400 in this testing - one of the major differences
in that 400 release/service pack was to improve Crystal run time.

Suggestions anyone?

Thanks!

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

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





[Non-text portions of this message have been removed]
10
If you're running SQL skipping the middle-man and running ODBC directly
on SQL Server is at least an order of magnitude faster than going
through Progress (on smaller datasets).

My times were 40 minutes for the generation of a very large Production
Detail report using BAQ - this is still almost twice as fast as the
standard report - running the same on ODBC directly with SQL Server, on
a dataset twice the size did the job in *cough* 0.300 seconds.

I assumed this would be because of the XML conversion, but it's not, I
wrote a quick C# app that read 15 MB of data using the same query (.300
one), and wrote them to XML (SQL Server can do it directly, but I chose
the slower path intentionally) and this took some 5-10 seconds on my
development computer. The resulting XML was a near perfect replica of
the one Vantage generates, and fully compatible with Crystal.

Note that these queries were not the original Vantage report, but my own
Detailed Production Report.

Conclusion is - Progress is not terribly fast.



I eventually remade the BAQ with far fewer fields in it, and it runs
fast enough now - but if you need a very large report, avoid going
through Progress.

Please note that I did not ever test Progress directly - so this
conclusion is only an educated guess - the only information I have is
that the XML file gets generated after 40 minutes or more, while SQL
server is doing nothing and could generate that data in less than 5
seconds.



We only use ODBC access for reports that need unions or for extremely
large datasets - using a specialized reader user with access only to the
needed tables.





Andrei







Posted by: "Gary Parfrey" garyp@...
<mailto:garyp@...?Subject=%20Re%3A%208%2E0%20Production%20Det
ail> gparfrey <http://profiles.yahoo.com/gparfrey>

Wed Jan 23, 2008 4:08 pm (PST)



Rewrite the report in Crystal using ODBC. Runs in seconds/minutes
instead of minutes/hours



Posted by: "Jason Claggett" jason@...
<mailto:jason@...?Subject=%20Re%3A%208%2E0%20Production%20Detail>
jason_claggett <http://profiles.yahoo.com/jason_claggett>

Wed Jan 23, 2008 9:09 pm (PST)

Gary,

While this might be faster/better. I don't agree with this practice. In
the past, yes, this was the only way to do it, however, now with BAQs
and the ability to create your own datasets within Vantage someone with
a little time could create a dataset that only has the information
needed.

*******************************************************************************************************************************************************************************************************************************************************************************
This email is intended for the addressee only and may contain information that is privileged and confidential. If you are not the intended recipient, you must not copy, distribute or take any
action in reliance on it. If this email has been sent to you in error, please notify us immediately by telephone.
This has been transmitted by -

Planned Storage Systems Ltd
Murdock Road
Dorcan Industrial Estate
Swindon

SN3 5HY

Company Registration No: 01028915.

The views within this email are those of the author and not
necessarily those of Planned Storage Systems Ltd.

** This email has been scanned for viruses, vandals and malicious content **
************************************************************************************************************************************************************************************************



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