SQL vs. Progress for Epicor 9

[system]

We have major performance issues. And pretty much every report we print
is used through ODBC. This may very well be the cause of our troubles.
What options do we have if we don't want to use ODBC anymore?



Thanks,

Blake Clemens

IT Systems Engineer

Delmarva Millwork Corporation

(800) 360-2364 x132

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Hatcher, John
Sent: Wednesday, September 16, 2009 12:35 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re:ODBC Performance Hit?





We use ODBC almost exclusively with our web server which runs Cold
Fusion.

My experience has shown me that:

1. ODBC is a processor hog. 1 thread will peg up all 4 processor
cores at 25%.
2. The implementation of ODBC provided by Progress doesn't support
anything close to the latest releases of ODBC. Many times I find that
certain features have not been implemented. A good example is the use
of subqueries.
3. The optimizer for Progress when an ODBC request comes in is not
particularly good at building an execution plan. Seemingly simple WHERE
clauses will cause the query performance to nosedive. Let's say we have
million row table. I write a query that uses indexed columns and the
result when I test is 1000 records. If I then add another condition to
the WHERE clause which isn't indexed, my query may suddenly take an
inordinate amount of time or never return. The optimizer should be
smart enough to extract the same 1000 records and then parse out the
subset.

The morale of the story is to be very careful how your queries are
constructed and have a very good understanding of the data dictionary.

John A. Hatcher

Manager of IS

Versa Products Co., Inc.

(201) 518-5948

(201) 843-2400 x4148

(201) 843-2931 (fax)

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





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

[system]

It depends on what version you are on, but I've had a lot of success using BAQ reports. Between the BAQ and the Crystal functionality you can do just about everything you want. There are some limitations, but there are ways around them. For example, you can't link a table more then once in a 8.03.4xx BAQ, but by using BPMs I have grabbed the data we need and dropped them into UD fields. This has the added advantage of making them available in dashboards and customized maintenance screens.

Or you could use a combination of BAQ and ODBC reports. Start with a BAQ report and then pull in the subset of data you need using ODBC inside of Crystal. This would cut down on the amount of overhead cased by the ODBC.

Remember to always set your ODBC to read only. I think its "Read Uncommitted" in the Progress ODBC driver.




________________________________
From: Blake Clemens <blake.clemens@...>
To: vantage@yahoogroups.com
Sent: Wednesday, September 16, 2009 3:00:33 PM
Subject: RE: [Vantage] Re:ODBC Performance Hit?

Â
We have major performance issues. And pretty much every report we print
is used through ODBC. This may very well be the cause of our troubles.
What options do we have if we don't want to use ODBC anymore?

Thanks,

Blake Clemens

IT Systems Engineer

Delmarva Millwork Corporation

(800) 360-2364 x132

From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf
Of Hatcher, John
Sent: Wednesday, September 16, 2009 12:35 PM
To: vantage@yahoogroups .com
Subject: [Vantage] Re:ODBC Performance Hit?

We use ODBC almost exclusively with our web server which runs Cold
Fusion.

My experience has shown me that:

1. ODBC is a processor hog. 1 thread will peg up all 4 processor
cores at 25%.
2. The implementation of ODBC provided by Progress doesn't support
anything close to the latest releases of ODBC. Many times I find that
certain features have not been implemented. A good example is the use
of subqueries.
3. The optimizer for Progress when an ODBC request comes in is not
particularly good at building an execution plan. Seemingly simple WHERE
clauses will cause the query performance to nosedive. Let's say we have
million row table. I write a query that uses indexed columns and the
result when I test is 1000 records. If I then add another condition to
the WHERE clause which isn't indexed, my query may suddenly take an
inordinate amount of time or never return. The optimizer should be
smart enough to extract the same 1000 records and then parse out the
subset.

The morale of the story is to be very careful how your queries are
constructed and have a very good understanding of the data dictionary.

John A. Hatcher

Manager of IS

Versa Products Co., Inc.

(201) 518-5948

(201) 843-2400 x4148

(201) 843-2931 (fax)

[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]

[system]

We use BAQ reports exclusively with Crystal. No ODBC. I didn't want to
distribute throughout the company the ability to hit on the Progress
database via ODBC. I have found that I'm able to extend any report
throught



That said, Do you have any sample queries from Crystal that are causing
you problems? I'd be willing to take a look to see if there are any
obvious problems in their construction.



John A. Hatcher

Manager of IS

Versa Products Co., Inc.

(201) 518-5948

(201) 843-2400 x4148

(201) 843-2931 (fax)





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

[system]

All of our reports use ODBC... pretty much.



Thanks,

Blake Clemens

IT Systems Engineer

Delmarva Millwork Corporation

(800) 360-2364 x132

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Hatcher, John
Sent: Wednesday, September 16, 2009 3:51 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: ODBC Performance Hit?





We use BAQ reports exclusively with Crystal. No ODBC. I didn't want to
distribute throughout the company the ability to hit on the Progress
database via ODBC. I have found that I'm able to extend any report
throught

That said, Do you have any sample queries from Crystal that are causing
you problems? I'd be willing to take a look to see if there are any
obvious problems in their construction.

John A. Hatcher

Manager of IS

Versa Products Co., Inc.

(201) 518-5948

(201) 843-2400 x4148

(201) 843-2931 (fax)

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





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

[system]

We had performance issues with ODBC as well. To do ODBC with SQL, we added a "with (NOLOCK)" to the from section of our views for all tables. You can also set your session to read uncommitted by using stored procedures instead of views.

Using Read un-committed ODBC queries helped us very much with our ODBC reports.

--- In vantage@yahoogroups.com, Steven Gotschall <sgotschall@...> wrote:
>
> It depends on what version you are on, but I've had a lot of success using BAQ reports. Between the BAQ and the Crystal functionality you can do just about everything you want. There are some limitations, but there are ways around them. For example, you can't link a table more then once in a 8.03.4xx BAQ, but by using BPMs I have grabbed the data we need and dropped them into UD fields. This has the added advantage of making them available in dashboards and customized maintenance screens.
>
> Or you could use a combination of BAQ and ODBC reports. Start with a BAQ report and then pull in the subset of data you need using ODBC inside of Crystal. This would cut down on the amount of overhead cased by the ODBC.
>
> Remember to always set your ODBC to read only. I think its "Read Uncommitted" in the Progress ODBC driver.
>
>
>
>
> ________________________________
> From: Blake Clemens <blake.clemens@...>
> To: vantage@yahoogroups.com
> Sent: Wednesday, September 16, 2009 3:00:33 PM
> Subject: RE: [Vantage] Re:ODBC Performance Hit?
>
> Â
> We have major performance issues. And pretty much every report we print
> is used through ODBC. This may very well be the cause of our troubles.
> What options do we have if we don't want to use ODBC anymore?
>
> Thanks,
>
> Blake Clemens
>
> IT Systems Engineer
>
> Delmarva Millwork Corporation
>
> (800) 360-2364 x132
>
> From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf
> Of Hatcher, John
> Sent: Wednesday, September 16, 2009 12:35 PM
> To: vantage@yahoogroups .com
> Subject: [Vantage] Re:ODBC Performance Hit?
>
> We use ODBC almost exclusively with our web server which runs Cold
> Fusion.
>
> My experience has shown me that:
>
> 1. ODBC is a processor hog. 1 thread will peg up all 4 processor
> cores at 25%.
> 2. The implementation of ODBC provided by Progress doesn't support
> anything close to the latest releases of ODBC. Many times I find that
> certain features have not been implemented. A good example is the use
> of subqueries.
> 3. The optimizer for Progress when an ODBC request comes in is not
> particularly good at building an execution plan. Seemingly simple WHERE
> clauses will cause the query performance to nosedive. Let's say we have
> million row table. I write a query that uses indexed columns and the
> result when I test is 1000 records. If I then add another condition to
> the WHERE clause which isn't indexed, my query may suddenly take an
> inordinate amount of time or never return. The optimizer should be
> smart enough to extract the same 1000 records and then parse out the
> subset.
>
> The morale of the story is to be very careful how your queries are
> constructed and have a very good understanding of the data dictionary.
>
> John A. Hatcher
>
> Manager of IS
>
> Versa Products Co., Inc.
>
> (201) 518-5948
>
> (201) 843-2400 x4148
>
> (201) 843-2931 (fax)
>
> [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]
>

[system]

We're already set up with Read Uncommitted.



Thanks,

Blake Clemens

IT Systems Engineer

Delmarva Millwork Corporation

(800) 360-2364 x132

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of lapulsifer
Sent: Wednesday, September 16, 2009 4:19 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re:ODBC Performance Hit?





We had performance issues with ODBC as well. To do ODBC with SQL, we
added a "with (NOLOCK)" to the from section of our views for all tables.
You can also set your session to read uncommitted by using stored
procedures instead of views.

Using Read un-committed ODBC queries helped us very much with our ODBC
reports.

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
Steven Gotschall <sgotschall@...> wrote:

>
> It depends on what version you are on, but I've had a lot of success

using BAQ reports. Between the BAQ and the Crystal functionality you
can do just about everything you want. There are some limitations, but
there are ways around them. For example, you can't link a table more
then once in a 8.03.4xx BAQ, but by using BPMs I have grabbed the data
we need and dropped them into UD fields. This has the added advantage
of making them available in dashboards and customized maintenance
screens.

>
> Or you could use a combination of BAQ and ODBC reports. Start with a

BAQ report and then pull in the subset of data you need using ODBC
inside of Crystal. This would cut down on the amount of overhead cased
by the ODBC.

>
> Remember to always set your ODBC to read only. I think its "Read

Uncommitted" in the Progress ODBC driver.

>
>
>
>
> ________________________________
> From: Blake Clemens <blake.clemens@...>
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Sent: Wednesday, September 16, 2009 3:00:33 PM
> Subject: RE: [Vantage] Re:ODBC Performance Hit?
>
>
> We have major performance issues. And pretty much every report we

print

> is used through ODBC. This may very well be the cause of our troubles.
> What options do we have if we don't want to use ODBC anymore?
>
> Thanks,
>
> Blake Clemens
>
> IT Systems Engineer
>
> Delmarva Millwork Corporation
>
> (800) 360-2364 x132
>
> From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On

Behalf

> Of Hatcher, John
> Sent: Wednesday, September 16, 2009 12:35 PM
> To: vantage@yahoogroups .com
> Subject: [Vantage] Re:ODBC Performance Hit?
>
> We use ODBC almost exclusively with our web server which runs Cold
> Fusion.
>
> My experience has shown me that:
>
> 1. ODBC is a processor hog. 1 thread will peg up all 4 processor
> cores at 25%.
> 2. The implementation of ODBC provided by Progress doesn't support
> anything close to the latest releases of ODBC. Many times I find that
> certain features have not been implemented. A good example is the use
> of subqueries.
> 3. The optimizer for Progress when an ODBC request comes in is not
> particularly good at building an execution plan. Seemingly simple

WHERE

> clauses will cause the query performance to nosedive. Let's say we

have

> million row table. I write a query that uses indexed columns and the
> result when I test is 1000 records. If I then add another condition to
> the WHERE clause which isn't indexed, my query may suddenly take an
> inordinate amount of time or never return. The optimizer should be
> smart enough to extract the same 1000 records and then parse out the
> subset.
>
> The morale of the story is to be very careful how your queries are
> constructed and have a very good understanding of the data dictionary.
>
> John A. Hatcher
>
> Manager of IS
>
> Versa Products Co., Inc.
>
> (201) 518-5948
>
> (201) 843-2400 x4148
>
> (201) 843-2931 (fax)
>
> [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]
>

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

[system]

Steven wrote:

> It depends on what version you are on, but I've had a lot of
> success using BAQ reports. Between the BAQ and the Crystal
> functionality you can do just about everything you want.
> There are some limitations, but there are ways around them.
> For example, you can't link a table more then once in a
> 8.03.4xx

True. You can do so in Epicor 9 however.

Also, BAQs respect application security. Users can't see customers out of
their territory, etc.

Mark W.

[system]

Vic Drecchio wrote:

>
> My logic is converse to your question. I ask: What reason would I have
> to go with Vantage on a Progress database?

Because, at the heart, Vantage 8/Epicor 9 is a Progress application.

Epicor marketing seems to be hiding this fact alltogether.
They only talk about Epicor using Microsoft Technlogy.

Sure, it is not untrue; the client is written in .Net (using Progress
Open Client technology) and the backend can be a third party database,
using ODBC, SQL Server in this case. But the core technology is Progress.

That means the Progress database is native to the application.
Progress Appservers use shared memory to access the Progress database.

If you want to replace the Progress database with SQL Server, you are
actually replacing the Progress database with a Progress dataserver,
a process that translates Progress 4GL data requests to ODBC.
Go figure how efficient that could ever be. It also means you still
need to know about Progress to keep things running. In fact you
need to know even more, because you need to install more Progress
software modules than native Progress database users have to.

Of course, you could spend more on hardware in order to compensate for
the inefficiency. But spending that extra money on even better hardware
for Progress will be more rewarding. You need all the performance you
can get to keep your users satisfied.

Having said that, it should also be said that Epicor 9 allows you to
benefit from the best of both worlds. Epicor 9 now allows your Progress
database to be replicated to an external SQL Server database, allowing
you to do all your reporting, data mining and business intelligence
from that secondary database.

This is really ideal. Your Progress database is only used to efficiently
serve your core application, and reporting is done on a platform that
excels in that area.

Having this secondary server running SQL Server is a good idea for other
stuff too. It's the best place for Service Connect, for Portal, for
Information Worker, for PLM, for APM and lots of other modules that
require SQL Server for their private storage.

Epicor 9 Enterprise Search (which is really cool) _requires_ this kind of
setup if you use a Progress database.

Pim

[system]

Pim wrote:

> Having said that, it should also be said that Epicor 9 allows you to
> benefit from the best of both worlds. Epicor 9 now allows your Progress
> database to be replicated to an external SQL Server database, allowing
> you to do all your reporting, data mining and business intelligence
> from that secondary database.
>
> This is really ideal. Your Progress database is only used to
> efficiently serve your core application, and reporting is done on a
> platform that excels in that area.

If I were to do it all over, this is exactly how I would set up our company
and we're moving in this direction. We've already added a server for Portal,
Enterprise Search, SharePoint, and the Connect Products (also our terminal
server for four users). We didn't spring for the full SQL Server license or
Replication Server then so we'll have to wait until the budget improves so
we can take advantage of some of these new features. I believe that
Replication Server is an extra too if I'm not mistaken.

> Having this secondary server running SQL Server is a good idea for other
> stuff too. It's the best place for Service Connect, for Portal, for
> Information Worker, for PLM, for APM and lots of other modules that
> require SQL Server for their private storage.
>
> Epicor 9 Enterprise Search (which is really cool) _requires_ this kind of
> setup if you use a Progress database.

Excellent post Pim.

Mark W.

[system]

You don't have to put it in the query if you setup your DSN default isolation level to "READ UNCOMMITTED" (advanced tab).

--- In vantage@yahoogroups.com, "lapulsifer" <sharon.pulsifer@...> wrote:
>
> We had performance issues with ODBC as well. To do ODBC with SQL, we added a "with (NOLOCK)" to the from section of our views for all tables. You can also set your session to read uncommitted by using stored procedures instead of views.
>
> Using Read un-committed ODBC queries helped us very much with our ODBC reports.
>
>
>
> --- In vantage@yahoogroups.com, Steven Gotschall <sgotschall@> wrote:
> >
> > It depends on what version you are on, but I've had a lot of success using BAQ reports. Between the BAQ and the Crystal functionality you can do just about everything you want. There are some limitations, but there are ways around them. For example, you can't link a table more then once in a 8.03.4xx BAQ, but by using BPMs I have grabbed the data we need and dropped them into UD fields. This has the added advantage of making them available in dashboards and customized maintenance screens.
> >
> > Or you could use a combination of BAQ and ODBC reports. Start with a BAQ report and then pull in the subset of data you need using ODBC inside of Crystal. This would cut down on the amount of overhead cased by the ODBC.
> >
> > Remember to always set your ODBC to read only. I think its "Read Uncommitted" in the Progress ODBC driver.
> >
> >
> >
> >
> > ________________________________
> > From: Blake Clemens <blake.clemens@>
> > To: vantage@yahoogroups.com
> > Sent: Wednesday, September 16, 2009 3:00:33 PM
> > Subject: RE: [Vantage] Re:ODBC Performance Hit?
> >
> > Â
> > We have major performance issues. And pretty much every report we print
> > is used through ODBC. This may very well be the cause of our troubles.
> > What options do we have if we don't want to use ODBC anymore?
> >
> > Thanks,
> >
> > Blake Clemens
> >
> > IT Systems Engineer
> >
> > Delmarva Millwork Corporation
> >
> > (800) 360-2364 x132
> >
> > From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf
> > Of Hatcher, John
> > Sent: Wednesday, September 16, 2009 12:35 PM
> > To: vantage@yahoogroups .com
> > Subject: [Vantage] Re:ODBC Performance Hit?
> >
> > We use ODBC almost exclusively with our web server which runs Cold
> > Fusion.
> >
> > My experience has shown me that:
> >
> > 1. ODBC is a processor hog. 1 thread will peg up all 4 processor
> > cores at 25%.
> > 2. The implementation of ODBC provided by Progress doesn't support
> > anything close to the latest releases of ODBC. Many times I find that
> > certain features have not been implemented. A good example is the use
> > of subqueries.
> > 3. The optimizer for Progress when an ODBC request comes in is not
> > particularly good at building an execution plan. Seemingly simple WHERE
> > clauses will cause the query performance to nosedive. Let's say we have
> > million row table. I write a query that uses indexed columns and the
> > result when I test is 1000 records. If I then add another condition to
> > the WHERE clause which isn't indexed, my query may suddenly take an
> > inordinate amount of time or never return. The optimizer should be
> > smart enough to extract the same 1000 records and then parse out the
> > subset.
> >
> > The morale of the story is to be very careful how your queries are
> > constructed and have a very good understanding of the data dictionary.
> >
> > John A. Hatcher
> >
> > Manager of IS
> >
> > Versa Products Co., Inc.
> >
> > (201) 518-5948
> >
> > (201) 843-2400 x4148
> >
> > (201) 843-2931 (fax)
> >
> > [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]
> >
>

[system]

Thanks Pim! This sounds like the best option I've heard. Best of both worlds like you said. It seems we are looking at midyear 2010 at the earliest for the upgrade so we have some time to investigate these new options with E9. MUCH APPRECIATED!!!

--- In vantage@yahoogroups.com, Pim Zandbergen <P.Zandbergen@...> wrote:
>
> Vic Drecchio wrote:
> >
> > My logic is converse to your question. I ask: What reason would I have
> > to go with Vantage on a Progress database?
> Because, at the heart, Vantage 8/Epicor 9 is a Progress application.
>
> Epicor marketing seems to be hiding this fact alltogether.
> They only talk about Epicor using Microsoft Technlogy.
>
> Sure, it is not untrue; the client is written in .Net (using Progress
> Open Client technology) and the backend can be a third party database,
> using ODBC, SQL Server in this case. But the core technology is Progress.
>
> That means the Progress database is native to the application.
> Progress Appservers use shared memory to access the Progress database.
>
> If you want to replace the Progress database with SQL Server, you are
> actually replacing the Progress database with a Progress dataserver,
> a process that translates Progress 4GL data requests to ODBC.
> Go figure how efficient that could ever be. It also means you still
> need to know about Progress to keep things running. In fact you
> need to know even more, because you need to install more Progress
> software modules than native Progress database users have to.
>
> Of course, you could spend more on hardware in order to compensate for
> the inefficiency. But spending that extra money on even better hardware
> for Progress will be more rewarding. You need all the performance you
> can get to keep your users satisfied.
>
> Having said that, it should also be said that Epicor 9 allows you to
> benefit from the best of both worlds. Epicor 9 now allows your Progress
> database to be replicated to an external SQL Server database, allowing
> you to do all your reporting, data mining and business intelligence
> from that secondary database.
>
> This is really ideal. Your Progress database is only used to efficiently
> serve your core application, and reporting is done on a platform that
> excels in that area.
>
> Having this secondary server running SQL Server is a good idea for other
> stuff too. It's the best place for Service Connect, for Portal, for
> Information Worker, for PLM, for APM and lots of other modules that
> require SQL Server for their private storage.
>
> Epicor 9 Enterprise Search (which is really cool) _requires_ this kind of
> setup if you use a Progress database.
>
> Pim
>

[system]

This is not an "option" this is the way the SQL works every time. It's not
truly SQL progress still sits in the middle.



~Charlie

_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
saab_barracuda
Sent: Thursday, September 17, 2009 10:33 AM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: SQL vs. Progress for Epicor 9





Thanks Pim! This sounds like the best option I've heard. Best of both worlds
like you said. It seems we are looking at midyear 2010 at the earliest for
the upgrade so we have some time to investigate these new options with E9.
MUCH APPRECIATED!!!

--- In vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com, Pim
Zandbergen <P.Zandbergen@...> wrote:

>
> Vic Drecchio wrote:
> >
> > My logic is converse to your question. I ask: What reason would I have
> > to go with Vantage on a Progress database?
> Because, at the heart, Vantage 8/Epicor 9 is a Progress application.
>
> Epicor marketing seems to be hiding this fact alltogether.
> They only talk about Epicor using Microsoft Technlogy.
>
> Sure, it is not untrue; the client is written in .Net (using Progress
> Open Client technology) and the backend can be a third party database,
> using ODBC, SQL Server in this case. But the core technology is Progress.
>
> That means the Progress database is native to the application.
> Progress Appservers use shared memory to access the Progress database.
>
> If you want to replace the Progress database with SQL Server, you are
> actually replacing the Progress database with a Progress dataserver,
> a process that translates Progress 4GL data requests to ODBC.
> Go figure how efficient that could ever be. It also means you still
> need to know about Progress to keep things running. In fact you
> need to know even more, because you need to install more Progress
> software modules than native Progress database users have to.
>
> Of course, you could spend more on hardware in order to compensate for
> the inefficiency. But spending that extra money on even better hardware
> for Progress will be more rewarding. You need all the performance you
> can get to keep your users satisfied.
>
> Having said that, it should also be said that Epicor 9 allows you to
> benefit from the best of both worlds. Epicor 9 now allows your Progress
> database to be replicated to an external SQL Server database, allowing
> you to do all your reporting, data mining and business intelligence
> from that secondary database.
>
> This is really ideal. Your Progress database is only used to efficiently
> serve your core application, and reporting is done on a platform that
> excels in that area.
>
> Having this secondary server running SQL Server is a good idea for other
> stuff too. It's the best place for Service Connect, for Portal, for
> Information Worker, for PLM, for APM and lots of other modules that
> require SQL Server for their private storage.
>
> Epicor 9 Enterprise Search (which is really cool) _requires_ this kind of
> setup if you use a Progress database.
>
> Pim
>

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

[system]

Pim, very good points. I realize Vantage & Vista are native Progress
apps and you bring up a point that many overlook: Even if you are a SQL
customer you are still running Progress either way.

The way Vantage / Vista is currently developed it will always be faster
(screen renderings, searching, etc) with straight Progress. But I still
hold firm to my opinion that the benefit of freedom of SQL server
outweighs any small speed degradation.

Epicor also owns an ERP product called Manage2000 which I also used to
support and implement. It runs on IBM U2 database. Another old-school,
antiquated database.

Why? Because it's cheaper licensing for a developer to use and sell vs
MSSQL. But in recent tech years, this is now a moot point. Why not go
with an open-source, free database such as Postgres or MySQL?

Why not write a complete open source ERP system using RubyOnRails or ASP
and a free back end database?

Perhaps we should all pool our talent and develop one..... Well,
OpenBravo (www.openbravo.com) has been out for a while now... not sure
how successful.





-----Original Message-----
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of Pim Zandbergen
Sent: Thursday, September 17, 2009 6:04 AM
To: vantage@yahoogroups.com; Vic Drecchio
Subject: Re: [Vantage] SQL vs. Progress for Epicor 9

Vic Drecchio wrote:

>
> My logic is converse to your question. I ask: What reason would I

have

> to go with Vantage on a Progress database?

Because, at the heart, Vantage 8/Epicor 9 is a Progress application.

Epicor marketing seems to be hiding this fact alltogether.
They only talk about Epicor using Microsoft Technlogy.

Sure, it is not untrue; the client is written in .Net (using Progress
Open Client technology) and the backend can be a third party database,
using ODBC, SQL Server in this case. But the core technology is
Progress.

That means the Progress database is native to the application.
Progress Appservers use shared memory to access the Progress database.

If you want to replace the Progress database with SQL Server, you are
actually replacing the Progress database with a Progress dataserver,
a process that translates Progress 4GL data requests to ODBC.
Go figure how efficient that could ever be. It also means you still
need to know about Progress to keep things running. In fact you
need to know even more, because you need to install more Progress
software modules than native Progress database users have to.

Of course, you could spend more on hardware in order to compensate for
the inefficiency. But spending that extra money on even better hardware
for Progress will be more rewarding. You need all the performance you
can get to keep your users satisfied.

Having said that, it should also be said that Epicor 9 allows you to
benefit from the best of both worlds. Epicor 9 now allows your Progress
database to be replicated to an external SQL Server database, allowing
you to do all your reporting, data mining and business intelligence
from that secondary database.

This is really ideal. Your Progress database is only used to efficiently
serve your core application, and reporting is done on a platform that
excels in that area.

Having this secondary server running SQL Server is a good idea for other
stuff too. It's the best place for Service Connect, for Portal, for
Information Worker, for PLM, for APM and lots of other modules that
require SQL Server for their private storage.

Epicor 9 Enterprise Search (which is really cool) _requires_ this kind
of
setup if you use a Progress database.

Pim



------------------------------------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
have already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder
and Crystal Reports and other 'goodies', please goto:
http://groups.yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups.yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links

[system]

WE could make millions on technical support contracts!!!!



~Charlie

_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
Vic Drecchio
Sent: Thursday, September 17, 2009 10:48 AM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] SQL vs. Progress for Epicor 9





Pim, very good points. I realize Vantage & Vista are native Progress
apps and you bring up a point that many overlook: Even if you are a SQL
customer you are still running Progress either way.

The way Vantage / Vista is currently developed it will always be faster
(screen renderings, searching, etc) with straight Progress. But I still
hold firm to my opinion that the benefit of freedom of SQL server
outweighs any small speed degradation.

Epicor also owns an ERP product called Manage2000 which I also used to
support and implement. It runs on IBM U2 database. Another old-school,
antiquated database.

Why? Because it's cheaper licensing for a developer to use and sell vs
MSSQL. But in recent tech years, this is now a moot point. Why not go
with an open-source, free database such as Postgres or MySQL?

Why not write a complete open source ERP system using RubyOnRails or ASP
and a free back end database?

Perhaps we should all pool our talent and develop one..... Well,
OpenBravo (www.openbravo.com) has been out for a while now... not sure
how successful.

-----Original Message-----
From: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com
[mailto:vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com] On
Behalf
Of Pim Zandbergen
Sent: Thursday, September 17, 2009 6:04 AM
To: vantage@yahoogroups <mailto:vantage%40yahoogroups.com> .com; Vic
Drecchio
Subject: Re: [Vantage] SQL vs. Progress for Epicor 9

Vic Drecchio wrote:

>
> My logic is converse to your question. I ask: What reason would I

have

> to go with Vantage on a Progress database?

Because, at the heart, Vantage 8/Epicor 9 is a Progress application.

Epicor marketing seems to be hiding this fact alltogether.
They only talk about Epicor using Microsoft Technlogy.

Sure, it is not untrue; the client is written in .Net (using Progress
Open Client technology) and the backend can be a third party database,
using ODBC, SQL Server in this case. But the core technology is
Progress.

That means the Progress database is native to the application.
Progress Appservers use shared memory to access the Progress database.

If you want to replace the Progress database with SQL Server, you are
actually replacing the Progress database with a Progress dataserver,
a process that translates Progress 4GL data requests to ODBC.
Go figure how efficient that could ever be. It also means you still
need to know about Progress to keep things running. In fact you
need to know even more, because you need to install more Progress
software modules than native Progress database users have to.

Of course, you could spend more on hardware in order to compensate for
the inefficiency. But spending that extra money on even better hardware
for Progress will be more rewarding. You need all the performance you
can get to keep your users satisfied.

Having said that, it should also be said that Epicor 9 allows you to
benefit from the best of both worlds. Epicor 9 now allows your Progress
database to be replicated to an external SQL Server database, allowing
you to do all your reporting, data mining and business intelligence
from that secondary database.

This is really ideal. Your Progress database is only used to efficiently
serve your core application, and reporting is done on a platform that
excels in that area.

Having this secondary server running SQL Server is a good idea for other
stuff too. It's the best place for Service Connect, for Portal, for
Information Worker, for PLM, for APM and lots of other modules that
require SQL Server for their private storage.

Epicor 9 Enterprise Search (which is really cool) _requires_ this kind
of
setup if you use a Progress database.

Pim

------------------------------------

Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
have already linked your email address to a yahoo id to enable access. )
(1) To access the Files Section of our Yahoo!Group for Report Builder
and Crystal Reports and other 'goodies', please goto:
http://groups. <http://groups.yahoo.com/group/vantage/files/>
yahoo.com/group/vantage/files/.
(2) To search through old msg's goto:
http://groups. <http://groups.yahoo.com/group/vantage/messages>
yahoo.com/group/vantage/messages
(3) To view links to Vendors that provide Vantage services goto:
http://groups. <http://groups.yahoo.com/group/vantage/linksYahoo>
yahoo.com/group/vantage/linksYahoo! Groups Links





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

[system]

Vic Drecchio wrote:

> But I still
> hold firm to my opinion that the benefit of freedom of SQL server
> outweighs any small speed degradation.

Vic, you make it sound like SQL Server is open source software or
something. It is just as proprietary as Progress. It's even more
proprietary,
because it runs on Windows only, whereas Progress supports multiple
platforms.

Few people know that Epicor 9 is supported on Linux and HP/UX
besides Windows. Which proves there is no Microsoft technology
at the core of the application, just Progress.

It is true that more people have SQL Server knowledge than there are people
with Progress knowledge, but I would hardly call that freedom.

I would also agree that SQL Server management tools are superior over
that of Progress, but like I said, you are not relieved of Progress
maintenance duties when using SQL Server for Epicor 9.

> Why not go
> with an open-source, free database such as Postgres or MySQL?

It really should not matter what kind of database is used. It is not the
database technology that is important, it is the application platform that
is your most important choice when developing an application. Epicor
happened
to have chosen for Progress as their development platform, so using a
Progress
database is just a natural choice.

Also, the philosophy of Service Oriented Architecture based applications
is that noone should touch the database other than the application.
Users shouldn't be accessing the database directly using ODBC or whatever,
but should only use the application. That means using Webservices if
you don't want to do things through the GUI.

If you stick to that philosophy, then the database is really just an
internal resource and noone should have to know how and where it is stored.

Pim

[system]

Vic and I have had this argument for years.
The mainstay of the argument is that you can do more easier in SQL then you can do in Progress. I like Progress more then SQL, but I do have to agree Progress has more bugs and is a bit nastier to work worth.
Â
Jonathan LangÂ
Oil Rite Corporation
Sr. Network Administrator
Ph: (920) 682-6173 Ext: 126
Fax: (920) 682-7699

--- On Thu, 9/17/09, Pim Zandbergen <P.Zandbergen@...> wrote:


From: Pim Zandbergen <P.Zandbergen@...>
Subject: Re: [Vantage] SQL vs. Progress for Epicor 9
To: vantage@yahoogroups.com
Date: Thursday, September 17, 2009, 11:09 AM


Â



Vic Drecchio wrote:
> But I still
> hold firm to my opinion that the benefit of freedom of SQL server
> outweighs any small speed degradation.
Vic, you make it sound like SQL Server is open source software or
something. It is just as proprietary as Progress. It's even more
proprietary,
because it runs on Windows only, whereas Progress supports multiple
platforms.

Few people know that Epicor 9 is supported on Linux and HP/UX
besides Windows. Which proves there is no Microsoft technology
at the core of the application, just Progress.

It is true that more people have SQL Server knowledge than there are people
with Progress knowledge, but I would hardly call that freedom.

I would also agree that SQL Server management tools are superior over
that of Progress, but like I said, you are not relieved of Progress
maintenance duties when using SQL Server for Epicor 9.

> Why not go
> with an open-source, free database such as Postgres or MySQL?
It really should not matter what kind of database is used. It is not the
database technology that is important, it is the application platform that
is your most important choice when developing an application. Epicor
happened
to have chosen for Progress as their development platform, so using a
Progress
database is just a natural choice.

Also, the philosophy of Service Oriented Architecture based applications
is that noone should touch the database other than the application.
Users shouldn't be accessing the database directly using ODBC or whatever,
but should only use the application. That means using Webservices if
you don't want to do things through the GUI.

If you stick to that philosophy, then the database is really just an
internal resource and noone should have to know how and where it is stored.

Pim


















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

[system]

Hi Pim,



Do you know what technology is being used to perform the Progress to SQL
server replication?



I'm assuming that it is a Progress product that Epicor is using. If so,
what is stopping Epicor 803 users from doing the same?



Any thoughts would be appreciated. Thanks,



John A. Hatcher

Manager of IS

Versa Products Co., Inc.

(201) 518-5948

(201) 843-2400 x4148

(201) 843-2931 (fax)





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

[system]

I heard that you could use the Progress product to replicate your 8.03.4xx Progress database in real time to SQL. I thought about looking into it, but I never did. If it is the same for 9, then I bet the big difference is that Epicor supports it in 9 but you are on your own in 8.03.




________________________________
From: "Hatcher, John" <johnh@...>
To: vantage@yahoogroups.com
Sent: Thursday, September 17, 2009 2:52:11 PM
Subject: [Vantage] Re: SQL vs. Progress for Epicor 9

Â
Hi Pim,

Do you know what technology is being used to perform the Progress to SQL
server replication?

I'm assuming that it is a Progress product that Epicor is using. If so,
what is stopping Epicor 803 users from doing the same?

Any thoughts would be appreciated. Thanks,

John A. Hatcher

Manager of IS

Versa Products Co., Inc.

(201) 518-5948

(201) 843-2400 x4148

(201) 843-2931 (fax)

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







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

[system]

From the outside of this conversation, looking in, I am not sure how it is
actually supposed to work.

I am guessing it will use SonicMQ in order to do this replication.

A similar use of SonicMQ is already in use in the Mobile Connect product.
That products quality aside, it is a good example of how the DB replication
would be done, the initial population would probably take quite awhile, but
once up and running it's speed is probably pretty decent, also assuming that
you don't need to have it real time and a lag would be acceptable for data
population.

----- Original Message -----
From: "Hatcher, John" <johnh@...>
To: <vantage@yahoogroups.com>
Sent: Thursday, September 17, 2009 2:52 PM
Subject: [Vantage] Re: SQL vs. Progress for Epicor 9


> Hi Pim,
>
>
>
> Do you know what technology is being used to perform the Progress to SQL
> server replication?
>
>
>
> I'm assuming that it is a Progress product that Epicor is using. If so,
> what is stopping Epicor 803 users from doing the same?
>
>
>
> Any thoughts would be appreciated. Thanks,
>
>
>
> John A. Hatcher
>
> Manager of IS
>
> Versa Products Co., Inc.
>
> (201) 518-5948
>
> (201) 843-2400 x4148
>
> (201) 843-2931 (fax)
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Useful links for the Yahoo!Groups Vantage Board are: ( Note: You must
> have already linked your email address to a yahoo id to enable access. )
> (1) To access the Files Section of our Yahoo!Group for Report Builder and
> Crystal Reports and other 'goodies', please goto:
> http://groups.yahoo.com/group/vantage/files/.
> (2) To search through old msg's goto:
> http://groups.yahoo.com/group/vantage/messages
> (3) To view links to Vendors that provide Vantage services goto:
> http://groups.yahoo.com/group/vantage/linksYahoo! Groups Links
>
>
>

[system]

Hatcher, John wrote:

>
>
> Do you know what technology is being used to perform the Progress to SQL
> server replication?
>
>
>

It is custom Progress 4GL code that pushes data into SonicMQ 7.6.
Then there is a Windows service that pulls the data off SonicMQ
and stores it into SQL Server.

> I'm assuming that it is a Progress product that Epicor is using. If so,
> what is stopping Epicor 803 users from doing the same?

I know there is a Progress product called Fathom that does
replication. But I suppose it does Progress to Progress
replication only.

Maybe you could get it to replicate to a Progress database
with a SQL Server backend, but I would not bet that any of
the Epicor solutions that use the replicated database work
with anything else than their own stuff.

Pim