To SQL or not to SQL

Ok, I have to admit it. I really enjoy this topic because it
presumably begins as an earnest technical discourse and quickly
devolves into a kind of "my father can beat up your father" political
exercise. Truth is, both the SQL Server and Progress persistence
engines are fairly ordinary derivatives of the page based relational
model invented by Oracle. They both implement the same ACID
transaction persistence principles, albeit in slightly different ways,
and aside from some minor implementation differences no one has yet to
conclusively demonstrate a capability present in one that is
absolutely precluded in the other. That being said it is academically
true that you cannot execute Transact SQL syntax in Progress and SQL
Server only runs on a single OS. These are rather inconsequential
differences, however, considering the market realities of the ERP
application that serves as the context of this discussion.

There remain two unrefuted truisms from the discussion thus far. As
Jason accurately pointed out, Vantage requires an additional
communication layer through the Progress schema handlers in order to
communicate with SQL Server and, universally agreed upon by all, SQL
Server has a larger talent pool who are familiar with the product. So
the big "To SQL or not to SQL" $64 questions becomes "Are you better
off selecting the persistence engine that is technically better suited
to the application but has a much smaller support talent pool from
which to draw or to select the persistence engine less suited to the
application that has a much larger support talent pool from which to
draw"?

From the discussion thread so far, the distinction seems to be that
those who have a penchant for "backdoor" customizations tend to prefer
SQL Server....

Regards,

Michael

Michael Barry
Aspacia Systems Inc
866.566.9600
312.803.0730 fax
http://www.aspacia.com/

On Mar 27, 2009, at 10:50 AM, Karl Dash wrote:

> Ron,
> Sorry to rain on your parade but are you concerned with who comes
> after you to keep the system running? No one is indispensable. All
> the whiz-bang things you can do in SQL need to be carefully
> documented and management needs to understand that your replacement
> will need to be someone with at least your skills level to keep the
> ship afloat.
> -Karl
>
> --- On Fri, 3/27/09, Ron B <obersenf@...> wrote:
>
> From: Ron B <obersenf@...>
> Subject: [Vantage] Re: To SQL or not to SQL
> To: vantage@yahoogroups.com
> Date: Friday, March 27, 2009, 9:39 AM
>
> I also agree with the statement Robert makes. I have been a SQL
> Server user since 6.5 and was thankful that Epicor had this option.
> We seriously considered just going with Progress for speed, but SQL
> won in the end after having some frank discussions with Epicor.
>
> We have been live for about a year and already are moving items away
> from the Vantage UI such as reporting and using triggers instead of
> BPM's. I can browse data easily, utilize SQL Server Agent and have a
> great comfort level with my server. I haven't started on views or
> SP's yet, but will soon.
>
> So what I've sacrificed in speed I've gained in freedom. This has a
> payback to users as well. As I move more services away from the
> Vantage UI, staff on the shop floor can see the information they
> need without utilizing existing licensing and Progress's resources.
>
> Ron B
>
> --- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...>
> wrote:
> >
> > It really comes down to comfort level (which devil do you prefer? :)
> >
>
> [Non-text portions of this message have been removed]
>
>



[Non-text portions of this message have been removed]
Just to add to the SQL discussion, here are the Epicor Products that require
SQL:

Epicor Portal (Full version, no express versions)
Advanced Print
Replication Server
Enterprise Search
(Progress users apparently have to purchase Replication Server to use
Enterprise search)
Service Connect
SharePoint Services (if used for attachments in Epicor 9)
Cube-Connect
Performance Canvas/FRx

There may be others (Open 4? AQM?)...
Also, just to point out an Epicor "Requirment" - all these products need to
use a seperate installation of MS-SQL, and they cannot overlap with the
installation that is used to run the Vantage Database. If you have ANY type
of performance problems, the first thing support and development will tell
you is that you shouldn't be running any of the third party apps on the same
machine as Vantage. Stop that, and then call back if you still have
performance problems. You can however usually combine most of these apps
into one installation of MS-SQL.

In general it is reccomended that anyone buying Vantage plans on at least
one MS-SQL license no matter what, and at least 2 if you plan to use MS-SQL
as your DB type.

Some of these can use the Express Version and some 100% cannot use the
Express Version.

Open4 does not use MS-SQL, it is strictly progress based right now.

Also, be forewarned that buying MS Small Business Server 2003 is not a
recomended choice to use for the MS-SQL Server or the Vantage Server due to
an unknown number of built in security "features" and settings for the
"Small Business Owner" that it defaults to differently from a normal
standard or enterprise installation of Server 2003.

Also, only in very rare instances will anyone need the enterprise version of
MS-SQL server, along with very rarely will anyone need to be running their
MS-SQL DB in Unicode.


----- Original Message -----
From: "Mark Wonsil" <mark_wonsil@...>
To: <vantage@yahoogroups.com>
Sent: Thursday, March 26, 2009 11:33 AM
Subject: [Vantage] To SQL or not to SQL


> Just to add to the SQL discussion, here are the Epicor Products that
> require
> SQL:
>
> Epicor Portal (Full version, no express versions)
> Advanced Print
> Replication Server
> Enterprise Search
> (Progress users apparently have to purchase Replication Server to use
> Enterprise search)
> Service Connect
> SharePoint Services (if used for attachments in Epicor 9)
> Cube-Connect
> Performance Canvas/FRx
>
> There may be others (Open 4? AQM?)...
>
>
>
> ------------------------------------
>
> 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
>
>
>
Ned,

While I don't disagree with much of what you are saying. I will have to say that putting Vantage on MS-SQL is not necessarily a good idea and has been a topic of many debates. Here are a couple of reasons to not put your Vantage database on SQL Server.

#1 Currently, Epicor Vantage and Epicor 9 do not natively use ODBC calls for the application - reports, yes, application, no. So that means when any of the clients open up a session it still has to go through the mfgsyssh files (the schema holders) and do the translations between the two connection types making things slower. I know that there are tuning and other indexing that can be done, but there is added complexity to the problem. Using ODBC for reports has its own complications and is not necessarily the best practice. While most still do this to gain speed, moving servers or updating to the latest patch level can prove to be quite an undertaking.

#2 The backend code is still written in 4GL code and only the frontend is .NET. This means that the code actually running the programs are stored in .r or .p files. This has been known to cause issues with SQL server installations.

Running SQL Server for other third party apps is the way to go and while I agree that Epicor recommends you should keep everything as "clean" as possible, it's not a practical solution for companies to spend tons of money on a server farm for Vantage, Service Connect, APM, AQM, Portal, Enterprise Search, Replication, etc. for 20-30 users. I cannot with a clean conscience recommend a separate server for each one of these applications - I'd be fired.

Although, SBS 2003 is not recommended, we have plenty of smaller customers running on SBS 2003 Premium edition with no problems. Again, there's much debate on this and it's not the perfect solution for every customer, but it does work and there are very few - if any problems with it. For the 3-party apps, most will run on the SQL Server provided with the Premium Edition. I only know of one component (the APM web client and web server piece) that will not work on it and it's due to the fact that SBS 2003 is a domain controller.


Jason Claggett
Microsoft Small Business Specialist
MCP #3856159
2W Technologies, LLC
312.533.4033 x8039
jason@...<mailto:jason@...>

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Ned
Sent: Thursday, March 26, 2009 12:37 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] To SQL or not to SQL


Also, just to point out an Epicor "Requirment" - all these products need to
use a seperate installation of MS-SQL, and they cannot overlap with the
installation that is used to run the Vantage Database. If you have ANY type
of performance problems, the first thing support and development will tell
you is that you shouldn't be running any of the third party apps on the same
machine as Vantage. Stop that, and then call back if you still have
performance problems. You can however usually combine most of these apps
into one installation of MS-SQL.

In general it is reccomended that anyone buying Vantage plans on at least
one MS-SQL license no matter what, and at least 2 if you plan to use MS-SQL
as your DB type.

Some of these can use the Express Version and some 100% cannot use the
Express Version.

Open4 does not use MS-SQL, it is strictly progress based right now.

Also, be forewarned that buying MS Small Business Server 2003 is not a
recomended choice to use for the MS-SQL Server or the Vantage Server due to
an unknown number of built in security "features" and settings for the
"Small Business Owner" that it defaults to differently from a normal
standard or enterprise installation of Server 2003.

Also, only in very rare instances will anyone need the enterprise version of
MS-SQL server, along with very rarely will anyone need to be running their
MS-SQL DB in Unicode.

----- Original Message -----
From: "Mark Wonsil" <mark_wonsil@...<mailto:mark_wonsil%40yahoo.com>>
To: <vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>>
Sent: Thursday, March 26, 2009 11:33 AM
Subject: [Vantage] To SQL or not to SQL

> Just to add to the SQL discussion, here are the Epicor Products that
> require
> SQL:
>
> Epicor Portal (Full version, no express versions)
> Advanced Print
> Replication Server
> Enterprise Search
> (Progress users apparently have to purchase Replication Server to use
> Enterprise search)
> Service Connect
> SharePoint Services (if used for attachments in Epicor 9)
> Cube-Connect
> Performance Canvas/FRx
>
> There may be others (Open 4? AQM?)...
>
>
>
> ------------------------------------
>
> 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/.<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
>
>
>



[Non-text portions of this message have been removed]
Well, given no other factors to the situation. I personally don't see any
difference between SQL or Progress. Either one is going to give you the same
product. The differences between them are really minor, and the difference
in speed due to the SH files is really nothing to be concerned with from my
POV.

The difference on MS-SQL versus Progress all shifts back to the staff on
hand, what their abilities are, what your resources are, and how much they
already know about one or both of those systems. That's where the decision
making between the 2 really lies, not in the potential +/- in performance
between the 2, which is really a nominal difference from my experience.

I am not promoting one over the other, just putting the information out
there that anyone who is buying the system needs to play on at least one SQL
license, and be warned that SBS can cause problems.

I was at plenty of customer sited where SBS was the root cause of the
problem, often times due to the policies it automatically enacted. It is
also possible that because of your experience with SBS that you are able to
prevent those problems or you customize things differently when you do the
installation. Congratulations on that, but it doesn't change the fact that
many people have problems which are rooted in there, and not all of them pop
up right off the bat.

For the right customers, SQL's advantages far outweigh any possible
disadvantages.


----- Original Message -----
From: "Jason Claggett" <jason@...>
To: <vantage@yahoogroups.com>
Sent: Thursday, March 26, 2009 1:15 PM
Subject: RE: [Vantage] To SQL or not to SQL


> Ned,
>
> While I don't disagree with much of what you are saying. I will have to
> say that putting Vantage on MS-SQL is not necessarily a good idea and has
> been a topic of many debates. Here are a couple of reasons to not put your
> Vantage database on SQL Server.
>
> #1 Currently, Epicor Vantage and Epicor 9 do not natively use ODBC calls
> for the application - reports, yes, application, no. So that means when
> any of the clients open up a session it still has to go through the
> mfgsyssh files (the schema holders) and do the translations between the
> two connection types making things slower. I know that there are tuning
> and other indexing that can be done, but there is added complexity to the
> problem. Using ODBC for reports has its own complications and is not
> necessarily the best practice. While most still do this to gain speed,
> moving servers or updating to the latest patch level can prove to be quite
> an undertaking.
>
> #2 The backend code is still written in 4GL code and only the frontend is
> .NET. This means that the code actually running the programs are stored in
> .r or .p files. This has been known to cause issues with SQL server
> installations.
>
> Running SQL Server for other third party apps is the way to go and while I
> agree that Epicor recommends you should keep everything as "clean" as
> possible, it's not a practical solution for companies to spend tons of
> money on a server farm for Vantage, Service Connect, APM, AQM, Portal,
> Enterprise Search, Replication, etc. for 20-30 users. I cannot with a
> clean conscience recommend a separate server for each one of these
> applications - I'd be fired.
>
> Although, SBS 2003 is not recommended, we have plenty of smaller customers
> running on SBS 2003 Premium edition with no problems. Again, there's much
> debate on this and it's not the perfect solution for every customer, but
> it does work and there are very few - if any problems with it. For the
> 3-party apps, most will run on the SQL Server provided with the Premium
> Edition. I only know of one component (the APM web client and web server
> piece) that will not work on it and it's due to the fact that SBS 2003 is
> a domain controller.
>
>
> Jason Claggett
> Microsoft Small Business Specialist
> MCP #3856159
> 2W Technologies, LLC
> 312.533.4033 x8039
> jason@...<mailto:jason@...>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of Ned
> Sent: Thursday, March 26, 2009 12:37 PM
> To: vantage@yahoogroups.com
> Subject: Re: [Vantage] To SQL or not to SQL
>
>
> Also, just to point out an Epicor "Requirment" - all these products need
> to
> use a seperate installation of MS-SQL, and they cannot overlap with the
> installation that is used to run the Vantage Database. If you have ANY
> type
> of performance problems, the first thing support and development will tell
> you is that you shouldn't be running any of the third party apps on the
> same
> machine as Vantage. Stop that, and then call back if you still have
> performance problems. You can however usually combine most of these apps
> into one installation of MS-SQL.
>
> In general it is reccomended that anyone buying Vantage plans on at least
> one MS-SQL license no matter what, and at least 2 if you plan to use
> MS-SQL
> as your DB type.
>
> Some of these can use the Express Version and some 100% cannot use the
> Express Version.
>
> Open4 does not use MS-SQL, it is strictly progress based right now.
>
> Also, be forewarned that buying MS Small Business Server 2003 is not a
> recomended choice to use for the MS-SQL Server or the Vantage Server due
> to
> an unknown number of built in security "features" and settings for the
> "Small Business Owner" that it defaults to differently from a normal
> standard or enterprise installation of Server 2003.
>
> Also, only in very rare instances will anyone need the enterprise version
> of
> MS-SQL server, along with very rarely will anyone need to be running their
> MS-SQL DB in Unicode.
>
> ----- Original Message -----
> From: "Mark Wonsil"
> <mark_wonsil@...<mailto:mark_wonsil%40yahoo.com>>
> To: <vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>>
> Sent: Thursday, March 26, 2009 11:33 AM
> Subject: [Vantage] To SQL or not to SQL
>
>> Just to add to the SQL discussion, here are the Epicor Products that
>> require
>> SQL:
>>
>> Epicor Portal (Full version, no express versions)
>> Advanced Print
>> Replication Server
>> Enterprise Search
>> (Progress users apparently have to purchase Replication Server to use
>> Enterprise search)
>> Service Connect
>> SharePoint Services (if used for attachments in Epicor 9)
>> Cube-Connect
>> Performance Canvas/FRx
>>
>> There may be others (Open 4? AQM?)...
>>
>>
>>
>> ------------------------------------
>>
>> 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/.<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
>>
>>
>>
>
>
>
> [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
>
>
>
Here are some advantages Progress has over SQL.

No need for Full-Text Catalogs. Progress supports text searching natively.

Due to variable-length records and fields, a Progress database takes 1/6 the space of SQL.

Progress has better performance... as stated in Epicor's Hardware Sizing Guide. They recommend a separate server for the App Servers, based on user licenses, on SQL way before Progress.

--- In vantage@yahoogroups.com, "Ned" <TechnoBabbly@...> wrote:
>
> Well, given no other factors to the situation. I personally don't see any
> difference between SQL or Progress. Either one is going to give you the same
> product. The differences between them are really minor, and the difference
> in speed due to the SH files is really nothing to be concerned with from my
> POV.
>
> The difference on MS-SQL versus Progress all shifts back to the staff on
> hand, what their abilities are, what your resources are, and how much they
> already know about one or both of those systems. That's where the decision
> making between the 2 really lies, not in the potential +/- in performance
> between the 2, which is really a nominal difference from my experience.
>
> I am not promoting one over the other, just putting the information out
> there that anyone who is buying the system needs to play on at least one SQL
> license, and be warned that SBS can cause problems.
>
> I was at plenty of customer sited where SBS was the root cause of the
> problem, often times due to the policies it automatically enacted. It is
> also possible that because of your experience with SBS that you are able to
> prevent those problems or you customize things differently when you do the
> installation. Congratulations on that, but it doesn't change the fact that
> many people have problems which are rooted in there, and not all of them pop
> up right off the bat.
>
> For the right customers, SQL's advantages far outweigh any possible
> disadvantages.
>
>
> ----- Original Message -----
> From: "Jason Claggett" <jason@...>
> To: <vantage@yahoogroups.com>
> Sent: Thursday, March 26, 2009 1:15 PM
> Subject: RE: [Vantage] To SQL or not to SQL
>
>
> > Ned,
> >
> > While I don't disagree with much of what you are saying. I will have to
> > say that putting Vantage on MS-SQL is not necessarily a good idea and has
> > been a topic of many debates. Here are a couple of reasons to not put your
> > Vantage database on SQL Server.
> >
> > #1 Currently, Epicor Vantage and Epicor 9 do not natively use ODBC calls
> > for the application - reports, yes, application, no. So that means when
> > any of the clients open up a session it still has to go through the
> > mfgsyssh files (the schema holders) and do the translations between the
> > two connection types making things slower. I know that there are tuning
> > and other indexing that can be done, but there is added complexity to the
> > problem. Using ODBC for reports has its own complications and is not
> > necessarily the best practice. While most still do this to gain speed,
> > moving servers or updating to the latest patch level can prove to be quite
> > an undertaking.
> >
> > #2 The backend code is still written in 4GL code and only the frontend is
> > .NET. This means that the code actually running the programs are stored in
> > .r or .p files. This has been known to cause issues with SQL server
> > installations.
> >
> > Running SQL Server for other third party apps is the way to go and while I
> > agree that Epicor recommends you should keep everything as "clean" as
> > possible, it's not a practical solution for companies to spend tons of
> > money on a server farm for Vantage, Service Connect, APM, AQM, Portal,
> > Enterprise Search, Replication, etc. for 20-30 users. I cannot with a
> > clean conscience recommend a separate server for each one of these
> > applications - I'd be fired.
> >
> > Although, SBS 2003 is not recommended, we have plenty of smaller customers
> > running on SBS 2003 Premium edition with no problems. Again, there's much
> > debate on this and it's not the perfect solution for every customer, but
> > it does work and there are very few - if any problems with it. For the
> > 3-party apps, most will run on the SQL Server provided with the Premium
> > Edition. I only know of one component (the APM web client and web server
> > piece) that will not work on it and it's due to the fact that SBS 2003 is
> > a domain controller.
> >
> >
> > Jason Claggett
> > Microsoft Small Business Specialist
> > MCP #3856159
> > 2W Technologies, LLC
> > 312.533.4033 x8039
> > jason@...<mailto:jason@...>
> >
> > From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> > Of Ned
> > Sent: Thursday, March 26, 2009 12:37 PM
> > To: vantage@yahoogroups.com
> > Subject: Re: [Vantage] To SQL or not to SQL
> >
> >
> > Also, just to point out an Epicor "Requirment" - all these products need
> > to
> > use a seperate installation of MS-SQL, and they cannot overlap with the
> > installation that is used to run the Vantage Database. If you have ANY
> > type
> > of performance problems, the first thing support and development will tell
> > you is that you shouldn't be running any of the third party apps on the
> > same
> > machine as Vantage. Stop that, and then call back if you still have
> > performance problems. You can however usually combine most of these apps
> > into one installation of MS-SQL.
> >
> > In general it is reccomended that anyone buying Vantage plans on at least
> > one MS-SQL license no matter what, and at least 2 if you plan to use
> > MS-SQL
> > as your DB type.
> >
> > Some of these can use the Express Version and some 100% cannot use the
> > Express Version.
> >
> > Open4 does not use MS-SQL, it is strictly progress based right now.
> >
> > Also, be forewarned that buying MS Small Business Server 2003 is not a
> > recomended choice to use for the MS-SQL Server or the Vantage Server due
> > to
> > an unknown number of built in security "features" and settings for the
> > "Small Business Owner" that it defaults to differently from a normal
> > standard or enterprise installation of Server 2003.
> >
> > Also, only in very rare instances will anyone need the enterprise version
> > of
> > MS-SQL server, along with very rarely will anyone need to be running their
> > MS-SQL DB in Unicode.
> >
> > ----- Original Message -----
> > From: "Mark Wonsil"
> > <mark_wonsil@...<mailto:mark_wonsil%40yahoo.com>>
> > To: <vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>>
> > Sent: Thursday, March 26, 2009 11:33 AM
> > Subject: [Vantage] To SQL or not to SQL
> >
> >> Just to add to the SQL discussion, here are the Epicor Products that
> >> require
> >> SQL:
> >>
> >> Epicor Portal (Full version, no express versions)
> >> Advanced Print
> >> Replication Server
> >> Enterprise Search
> >> (Progress users apparently have to purchase Replication Server to use
> >> Enterprise search)
> >> Service Connect
> >> SharePoint Services (if used for attachments in Epicor 9)
> >> Cube-Connect
> >> Performance Canvas/FRx
> >>
> >> There may be others (Open 4? AQM?)...
> >>
> >>
> >>
> >> ------------------------------------
> >>
> >> 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/.<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
> >>
> >>
> >>
> >
> >
> >
> > [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
> >
> >
> >
>
My 2 cents:

SQL will save you money and give you freedom.

I have saved my company over well over $100,000 dollars in the last 12 months due to us using SQL.

How did I figure this?

With SQL I can use triggers, SQL Agent & SP's in lieu of Vantage custom code. I've carefully manipulated data on the fly. If you are on Progress, the alternative is the Custom Solutions Group @ $250/hr. or possibly BPMs which are cryptic.

SQL makes data forensics a heck of a lot easier, too. We all get those questions where we need to poke through raw data for hours. How do you efficiently do that in Progress?

I've had to mass update tables on the back end... For example changing the ClassID of our Part table. We had a ClassID that we needed to break apart and I was able to do that with a nice Update statement. 40K parts updated in 27 seconds.

I developed an enormous ASP-based time entry/logging/management system for our Engineering Group that hits Vantage UD tables from our intranet. Hourly I run a stored proc that carefully moves/updates that data from UD tables to LaborHed, LaborDtl and JobOper. We have 75 engineers using this for costing.

Our alternative? Buying 75 MES licenses and paying maintenance on those forever.

I've written "dashboards" that hit SQL Views I've created in which a BAQ-based dashboard could never do because of the capability in SQL to use UDF's (user defined functions). I put EpiButtons all over our various screens linking it to "SQL Dashboards" in ASP. Super Quick, massage-able and can be used without the need of Vantage.

Our Execs can open Internet Explorer, hit our intranet and get all the data and metrics they want without ever seeing the Vantage splash screen. Again, thereby saving money on licenses and maintenance.

In a nutshell: SQL gives you freedom. I have circumvented the Vantage UI on many occasions; and if feels great. :-)

Albeit, SQL does add another layer the way the developer clowns at Epicor designed it. Progress will always be quicker. However, the difference is very insignificant since the .400 release. .305? I'd hate to be on SQL.



Vic Drecchio
ERP Administrator
TIMCO Aviation Services
Greensboro, NC
Email:Â Â vic.drecchio@...
Mobile:Â 704.530.3092
Office:Â 336.668.4410 x3159



-----Original Message-----
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Ned
Sent: Thursday, March 26, 2009 3:30 PM
To: vantage@yahoogroups.com
Subject: Re: [Vantage] To SQL or not to SQL

Well, given no other factors to the situation. I personally don't see any
difference between SQL or Progress. Either one is going to give you the same
product. The differences between them are really minor, and the difference
in speed due to the SH files is really nothing to be concerned with from my
POV.

The difference on MS-SQL versus Progress all shifts back to the staff on
hand, what their abilities are, what your resources are, and how much they
already know about one or both of those systems. That's where the decision
making between the 2 really lies, not in the potential +/- in performance
between the 2, which is really a nominal difference from my experience.

I am not promoting one over the other, just putting the information out
there that anyone who is buying the system needs to play on at least one SQL
license, and be warned that SBS can cause problems.

I was at plenty of customer sited where SBS was the root cause of the
problem, often times due to the policies it automatically enacted. It is
also possible that because of your experience with SBS that you are able to
prevent those problems or you customize things differently when you do the
installation. Congratulations on that, but it doesn't change the fact that
many people have problems which are rooted in there, and not all of them pop
up right off the bat.

For the right customers, SQL's advantages far outweigh any possible
disadvantages.


----- Original Message -----
From: "Jason Claggett" <jason@...>
To: <vantage@yahoogroups.com>
Sent: Thursday, March 26, 2009 1:15 PM
Subject: RE: [Vantage] To SQL or not to SQL


> Ned,
>
> While I don't disagree with much of what you are saying. I will have to
> say that putting Vantage on MS-SQL is not necessarily a good idea and has
> been a topic of many debates. Here are a couple of reasons to not put your
> Vantage database on SQL Server.
>
> #1 Currently, Epicor Vantage and Epicor 9 do not natively use ODBC calls
> for the application - reports, yes, application, no. So that means when
> any of the clients open up a session it still has to go through the
> mfgsyssh files (the schema holders) and do the translations between the
> two connection types making things slower. I know that there are tuning
> and other indexing that can be done, but there is added complexity to the
> problem. Using ODBC for reports has its own complications and is not
> necessarily the best practice. While most still do this to gain speed,
> moving servers or updating to the latest patch level can prove to be quite
> an undertaking.
>
> #2 The backend code is still written in 4GL code and only the frontend is
> .NET. This means that the code actually running the programs are stored in
> .r or .p files. This has been known to cause issues with SQL server
> installations.
>
> Running SQL Server for other third party apps is the way to go and while I
> agree that Epicor recommends you should keep everything as "clean" as
> possible, it's not a practical solution for companies to spend tons of
> money on a server farm for Vantage, Service Connect, APM, AQM, Portal,
> Enterprise Search, Replication, etc. for 20-30 users. I cannot with a
> clean conscience recommend a separate server for each one of these
> applications - I'd be fired.
>
> Although, SBS 2003 is not recommended, we have plenty of smaller customers
> running on SBS 2003 Premium edition with no problems. Again, there's much
> debate on this and it's not the perfect solution for every customer, but
> it does work and there are very few - if any problems with it. For the
> 3-party apps, most will run on the SQL Server provided with the Premium
> Edition. I only know of one component (the APM web client and web server
> piece) that will not work on it and it's due to the fact that SBS 2003 is
> a domain controller.
>
>
> Jason Claggett
> Microsoft Small Business Specialist
> MCP #3856159
> 2W Technologies, LLC
> 312.533.4033 x8039
> jason@...<mailto:jason@...>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of Ned
> Sent: Thursday, March 26, 2009 12:37 PM
> To: vantage@yahoogroups.com
> Subject: Re: [Vantage] To SQL or not to SQL
>
>
> Also, just to point out an Epicor "Requirment" - all these products need
> to
> use a seperate installation of MS-SQL, and they cannot overlap with the
> installation that is used to run the Vantage Database. If you have ANY
> type
> of performance problems, the first thing support and development will tell
> you is that you shouldn't be running any of the third party apps on the
> same
> machine as Vantage. Stop that, and then call back if you still have
> performance problems. You can however usually combine most of these apps
> into one installation of MS-SQL.
>
> In general it is reccomended that anyone buying Vantage plans on at least
> one MS-SQL license no matter what, and at least 2 if you plan to use
> MS-SQL
> as your DB type.
>
> Some of these can use the Express Version and some 100% cannot use the
> Express Version.
>
> Open4 does not use MS-SQL, it is strictly progress based right now.
>
> Also, be forewarned that buying MS Small Business Server 2003 is not a
> recomended choice to use for the MS-SQL Server or the Vantage Server due
> to
> an unknown number of built in security "features" and settings for the
> "Small Business Owner" that it defaults to differently from a normal
> standard or enterprise installation of Server 2003.
>
> Also, only in very rare instances will anyone need the enterprise version
> of
> MS-SQL server, along with very rarely will anyone need to be running their
> MS-SQL DB in Unicode.
>
> ----- Original Message -----
> From: "Mark Wonsil"
> <mark_wonsil@...<mailto:mark_wonsil%40yahoo.com>>
> To: <vantage@yahoogroups.com<mailto:vantage%40yahoogroups.com>>
> Sent: Thursday, March 26, 2009 11:33 AM
> Subject: [Vantage] To SQL or not to SQL
>
>> Just to add to the SQL discussion, here are the Epicor Products that
>> require
>> SQL:
>>
>> Epicor Portal (Full version, no express versions)
>> Advanced Print
>> Replication Server
>> Enterprise Search
>> (Progress users apparently have to purchase Replication Server to use
>> Enterprise search)
>> Service Connect
>> SharePoint Services (if used for attachments in Epicor 9)
>> Cube-Connect
>> Performance Canvas/FRx
>>
>> There may be others (Open 4? AQM?)...
>>
>>
>>
>> ------------------------------------
>>
>> 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/.<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
>>
>>
>>
>
>
>
> [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
>
>
>



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

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
We achieved nearly everything you speak of (web apps, back end data correction, etc.,) on Progress via open edge odbc (SQL).

We only chose Progress over SQL because, at the time of purchase, only a handful of 8.03 installations were Live on SQL platform and it had no track record.

We also had some concerns that with the inherent Progress code layers (that will NEVER change no matter what Epicor says about .NET) the need for another data server translation layer to translate to SQL Server was just asking for even slower performance. (That assumption may have been wrong but with no Live users out there, we had no way to poll actual users to find out.)

Frankly Vic, I think someone as talented as yourself would have found you would have achieved the same results with either platform.

It really comes down to comfort level (which devil do you prefer? :)



--- On Thu, 3/26/09, Vic Drecchio <vic.drecchio@...> wrote:

From: Vic Drecchio <vic.drecchio@...>
Subject: RE: [Vantage] To SQL or not to SQL
To: vantage@yahoogroups.com
Date: Thursday, March 26, 2009, 3:59 PM






My 2 cents:

SQL will save you money and give you freedom.

I have saved my company over well over $100,000 dollars in the last 12 months due to us using SQL.

How did I figure this?

With SQL I can use triggers, SQL Agent & SP's in lieu of Vantage custom code. I've carefully manipulated data on the fly. If you are on Progress, the alternative is the Custom Solutions Group @ $250/hr. or possibly BPMs which are cryptic.

SQL makes data forensics a heck of a lot easier, too. We all get those questions where we need to poke through raw data for hours. How do you efficiently do that in Progress?

I've had to mass update tables on the back end... For example changing the ClassID of our Part table. We had a ClassID that we needed to break apart and I was able to do that with a nice Update statement. 40K parts updated in 27 seconds.

I developed an enormous ASP-based time entry/logging/ management system for our Engineering Group that hits Vantage UD tables from our intranet. Hourly I run a stored proc that carefully moves/updates that data from UD tables to LaborHed, LaborDtl and JobOper. We have 75 engineers using this for costing.

Our alternative? Buying 75 MES licenses and paying maintenance on those forever.

I've written "dashboards" that hit SQL Views I've created in which a BAQ-based dashboard could never do because of the capability in SQL to use UDF's (user defined functions). I put EpiButtons all over our various screens linking it to "SQL Dashboards" in ASP. Super Quick, massage-able and can be used without the need of Vantage.

Our Execs can open Internet Explorer, hit our intranet and get all the data and metrics they want without ever seeing the Vantage splash screen. Again, thereby saving money on licenses and maintenance.

In a nutshell: SQL gives you freedom. I have circumvented the Vantage UI on many occasions; and if feels great. :-)

Albeit, SQL does add another layer the way the developer clowns at Epicor designed it. Progress will always be quicker. However, the difference is very insignificant since the .400 release. .305? I'd hate to be on SQL.

Vic Drecchio
ERP Administrator
TIMCO Aviation Services
Greensboro, NC
Email:Â Â vic.drecchio@ timco.aero
Mobile:Â 704.530.3092
Office:Â 336.668.4410 x3159

-----Original Message-----
From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf Of Ned
Sent: Thursday, March 26, 2009 3:30 PM
To: vantage@yahoogroups .com
Subject: Re: [Vantage] To SQL or not to SQL

Well, given no other factors to the situation. I personally don't see any
difference between SQL or Progress. Either one is going to give you the same
product. The differences between them are really minor, and the difference
in speed due to the SH files is really nothing to be concerned with from my
POV.

The difference on MS-SQL versus Progress all shifts back to the staff on
hand, what their abilities are, what your resources are, and how much they
already know about one or both of those systems. That's where the decision
making between the 2 really lies, not in the potential +/- in performance
between the 2, which is really a nominal difference from my experience.

I am not promoting one over the other, just putting the information out
there that anyone who is buying the system needs to play on at least one SQL
license, and be warned that SBS can cause problems.

I was at plenty of customer sited where SBS was the root cause of the
problem, often times due to the policies it automatically enacted. It is
also possible that because of your experience with SBS that you are able to
prevent those problems or you customize things differently when you do the
installation. Congratulations on that, but it doesn't change the fact that
many people have problems which are rooted in there, and not all of them pop
up right off the bat.

For the right customers, SQL's advantages far outweigh any possible
disadvantages.

----- Original Message -----
From: "Jason Claggett" <jason@2wtech. com>
To: <vantage@yahoogroups .com>
Sent: Thursday, March 26, 2009 1:15 PM
Subject: RE: [Vantage] To SQL or not to SQL

> Ned,
>
> While I don't disagree with much of what you are saying. I will have to
> say that putting Vantage on MS-SQL is not necessarily a good idea and has
> been a topic of many debates. Here are a couple of reasons to not put your
> Vantage database on SQL Server.
>
> #1 Currently, Epicor Vantage and Epicor 9 do not natively use ODBC calls
> for the application - reports, yes, application, no. So that means when
> any of the clients open up a session it still has to go through the
> mfgsyssh files (the schema holders) and do the translations between the
> two connection types making things slower. I know that there are tuning
> and other indexing that can be done, but there is added complexity to the
> problem. Using ODBC for reports has its own complications and is not
> necessarily the best practice. While most still do this to gain speed,
> moving servers or updating to the latest patch level can prove to be quite
> an undertaking.
>
> #2 The backend code is still written in 4GL code and only the frontend is
> .NET. This means that the code actually running the programs are stored in
> .r or .p files. This has been known to cause issues with SQL server
> installations.
>
> Running SQL Server for other third party apps is the way to go and while I
> agree that Epicor recommends you should keep everything as "clean" as
> possible, it's not a practical solution for companies to spend tons of
> money on a server farm for Vantage, Service Connect, APM, AQM, Portal,
> Enterprise Search, Replication, etc. for 20-30 users. I cannot with a
> clean conscience recommend a separate server for each one of these
> applications - I'd be fired.
>
> Although, SBS 2003 is not recommended, we have plenty of smaller customers
> running on SBS 2003 Premium edition with no problems. Again, there's much
> debate on this and it's not the perfect solution for every customer, but
> it does work and there are very few - if any problems with it. For the
> 3-party apps, most will run on the SQL Server provided with the Premium
> Edition. I only know of one component (the APM web client and web server
> piece) that will not work on it and it's due to the fact that SBS 2003 is
> a domain controller.
>
>
> Jason Claggett
> Microsoft Small Business Specialist
> MCP #3856159
> 2W Technologies, LLC
> 312.533.4033 x8039
> jason@2wtech. com<mailto:jason@2wtech. com>
>
> From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf
> Of Ned
> Sent: Thursday, March 26, 2009 12:37 PM
> To: vantage@yahoogroups .com
> Subject: Re: [Vantage] To SQL or not to SQL
>
>
> Also, just to point out an Epicor "Requirment" - all these products need
> to
> use a seperate installation of MS-SQL, and they cannot overlap with the
> installation that is used to run the Vantage Database. If you have ANY
> type
> of performance problems, the first thing support and development will tell
> you is that you shouldn't be running any of the third party apps on the
> same
> machine as Vantage. Stop that, and then call back if you still have
> performance problems. You can however usually combine most of these apps
> into one installation of MS-SQL.
>
> In general it is reccomended that anyone buying Vantage plans on at least
> one MS-SQL license no matter what, and at least 2 if you plan to use
> MS-SQL
> as your DB type.
>
> Some of these can use the Express Version and some 100% cannot use the
> Express Version.
>
> Open4 does not use MS-SQL, it is strictly progress based right now.
>
> Also, be forewarned that buying MS Small Business Server 2003 is not a
> recomended choice to use for the MS-SQL Server or the Vantage Server due
> to
> an unknown number of built in security "features" and settings for the
> "Small Business Owner" that it defaults to differently from a normal
> standard or enterprise installation of Server 2003.
>
> Also, only in very rare instances will anyone need the enterprise version
> of
> MS-SQL server, along with very rarely will anyone need to be running their
> MS-SQL DB in Unicode.
>
> ----- Original Message -----
> From: "Mark Wonsil"
> <mark_wonsil@ yahoo.com<mailto:mark_ wonsil%40yahoo. com>>
> To: <vantage@yahoogroups .com<mailto:vantage% 40yahoogroups. com>>
> Sent: Thursday, March 26, 2009 11:33 AM
> Subject: [Vantage] To SQL or not to SQL
>
>> Just to add to the SQL discussion, here are the Epicor Products that
>> require
>> SQL:
>>
>> Epicor Portal (Full version, no express versions)
>> Advanced Print
>> Replication Server
>> Enterprise Search
>> (Progress users apparently have to purchase Replication Server to use
>> Enterprise search)
>> Service Connect
>> SharePoint Services (if used for attachments in Epicor 9)
>> Cube-Connect
>> Performance Canvas/FRx
>>
>> There may be others (Open 4? AQM?)...
>>
>>
>>
>> ------------ --------- --------- ------
>>
>> 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/.<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
>>
>>
>>
>
>
>
> [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
>
>
>

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

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
Robert,

Your last sentence says it perfectly. True. :-)



Vic


-----Original Message-----
From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of Robert Brown
Sent: Thursday, March 26, 2009 6:05 PM
To: vantage@yahoogroups.com
Subject: RE: [Vantage] To SQL or not to SQL


We achieved nearly everything you speak of (web apps, back end data correction, etc.,) on Progress via open edge odbc (SQL).

We only chose Progress over SQL because, at the time of purchase, only a handful of 8.03 installations were Live on SQL platform and it had no track record.

We also had some concerns that with the inherent Progress code layers (that will NEVER change no matter what Epicor says about .NET) the need for another data server translation layer to translate to SQL Server was just asking for even slower performance. (That assumption may have been wrong but with no Live users out there, we had no way to poll actual users to find out.)

Frankly Vic, I think someone as talented as yourself would have found you would have achieved the same results with either platform.

It really comes down to comfort level (which devil do you prefer? :)



--- On Thu, 3/26/09, Vic Drecchio <vic.drecchio@...> wrote:

From: Vic Drecchio <vic.drecchio@...>
Subject: RE: [Vantage] To SQL or not to SQL
To: vantage@yahoogroups.com
Date: Thursday, March 26, 2009, 3:59 PM






My 2 cents:

SQL will save you money and give you freedom.

I have saved my company over well over $100,000 dollars in the last 12 months due to us using SQL.

How did I figure this?

With SQL I can use triggers, SQL Agent & SP's in lieu of Vantage custom code. I've carefully manipulated data on the fly. If you are on Progress, the alternative is the Custom Solutions Group @ $250/hr. or possibly BPMs which are cryptic.

SQL makes data forensics a heck of a lot easier, too. We all get those questions where we need to poke through raw data for hours. How do you efficiently do that in Progress?

I've had to mass update tables on the back end... For example changing the ClassID of our Part table. We had a ClassID that we needed to break apart and I was able to do that with a nice Update statement. 40K parts updated in 27 seconds.

I developed an enormous ASP-based time entry/logging/ management system for our Engineering Group that hits Vantage UD tables from our intranet. Hourly I run a stored proc that carefully moves/updates that data from UD tables to LaborHed, LaborDtl and JobOper. We have 75 engineers using this for costing.

Our alternative? Buying 75 MES licenses and paying maintenance on those forever.

I've written "dashboards" that hit SQL Views I've created in which a BAQ-based dashboard could never do because of the capability in SQL to use UDF's (user defined functions). I put EpiButtons all over our various screens linking it to "SQL Dashboards" in ASP. Super Quick, massage-able and can be used without the need of Vantage.

Our Execs can open Internet Explorer, hit our intranet and get all the data and metrics they want without ever seeing the Vantage splash screen. Again, thereby saving money on licenses and maintenance.

In a nutshell: SQL gives you freedom. I have circumvented the Vantage UI on many occasions; and if feels great. :-)

Albeit, SQL does add another layer the way the developer clowns at Epicor designed it. Progress will always be quicker. However, the difference is very insignificant since the .400 release. .305? I'd hate to be on SQL.

Vic Drecchio
ERP Administrator
TIMCO Aviation Services
Greensboro, NC
Email:Â Â vic.drecchio@ timco.aero
Mobile:Â 704.530.3092
Office:Â 336.668.4410 x3159

-----Original Message-----
From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf Of Ned
Sent: Thursday, March 26, 2009 3:30 PM
To: vantage@yahoogroups .com
Subject: Re: [Vantage] To SQL or not to SQL

Well, given no other factors to the situation. I personally don't see any
difference between SQL or Progress. Either one is going to give you the same
product. The differences between them are really minor, and the difference
in speed due to the SH files is really nothing to be concerned with from my
POV.

The difference on MS-SQL versus Progress all shifts back to the staff on
hand, what their abilities are, what your resources are, and how much they
already know about one or both of those systems. That's where the decision
making between the 2 really lies, not in the potential +/- in performance
between the 2, which is really a nominal difference from my experience.

I am not promoting one over the other, just putting the information out
there that anyone who is buying the system needs to play on at least one SQL
license, and be warned that SBS can cause problems.

I was at plenty of customer sited where SBS was the root cause of the
problem, often times due to the policies it automatically enacted. It is
also possible that because of your experience with SBS that you are able to
prevent those problems or you customize things differently when you do the
installation. Congratulations on that, but it doesn't change the fact that
many people have problems which are rooted in there, and not all of them pop
up right off the bat.

For the right customers, SQL's advantages far outweigh any possible
disadvantages.

----- Original Message -----
From: "Jason Claggett" <jason@2wtech. com>
To: <vantage@yahoogroups .com>
Sent: Thursday, March 26, 2009 1:15 PM
Subject: RE: [Vantage] To SQL or not to SQL

> Ned,
>
> While I don't disagree with much of what you are saying. I will have to
> say that putting Vantage on MS-SQL is not necessarily a good idea and has
> been a topic of many debates. Here are a couple of reasons to not put your
> Vantage database on SQL Server.
>
> #1 Currently, Epicor Vantage and Epicor 9 do not natively use ODBC calls
> for the application - reports, yes, application, no. So that means when
> any of the clients open up a session it still has to go through the
> mfgsyssh files (the schema holders) and do the translations between the
> two connection types making things slower. I know that there are tuning
> and other indexing that can be done, but there is added complexity to the
> problem. Using ODBC for reports has its own complications and is not
> necessarily the best practice. While most still do this to gain speed,
> moving servers or updating to the latest patch level can prove to be quite
> an undertaking.
>
> #2 The backend code is still written in 4GL code and only the frontend is
> .NET. This means that the code actually running the programs are stored in
> .r or .p files. This has been known to cause issues with SQL server
> installations.
>
> Running SQL Server for other third party apps is the way to go and while I
> agree that Epicor recommends you should keep everything as "clean" as
> possible, it's not a practical solution for companies to spend tons of
> money on a server farm for Vantage, Service Connect, APM, AQM, Portal,
> Enterprise Search, Replication, etc. for 20-30 users. I cannot with a
> clean conscience recommend a separate server for each one of these
> applications - I'd be fired.
>
> Although, SBS 2003 is not recommended, we have plenty of smaller customers
> running on SBS 2003 Premium edition with no problems. Again, there's much
> debate on this and it's not the perfect solution for every customer, but
> it does work and there are very few - if any problems with it. For the
> 3-party apps, most will run on the SQL Server provided with the Premium
> Edition. I only know of one component (the APM web client and web server
> piece) that will not work on it and it's due to the fact that SBS 2003 is
> a domain controller.
>
>
> Jason Claggett
> Microsoft Small Business Specialist
> MCP #3856159
> 2W Technologies, LLC
> 312.533.4033 x8039
> jason@2wtech. com<mailto:jason@2wtech. com>
>
> From: vantage@yahoogroups .com [mailto:vantage@yahoogroups .com] On Behalf
> Of Ned
> Sent: Thursday, March 26, 2009 12:37 PM
> To: vantage@yahoogroups .com
> Subject: Re: [Vantage] To SQL or not to SQL
>
>
> Also, just to point out an Epicor "Requirment" - all these products need
> to
> use a seperate installation of MS-SQL, and they cannot overlap with the
> installation that is used to run the Vantage Database. If you have ANY
> type
> of performance problems, the first thing support and development will tell
> you is that you shouldn't be running any of the third party apps on the
> same
> machine as Vantage. Stop that, and then call back if you still have
> performance problems. You can however usually combine most of these apps
> into one installation of MS-SQL.
>
> In general it is reccomended that anyone buying Vantage plans on at least
> one MS-SQL license no matter what, and at least 2 if you plan to use
> MS-SQL
> as your DB type.
>
> Some of these can use the Express Version and some 100% cannot use the
> Express Version.
>
> Open4 does not use MS-SQL, it is strictly progress based right now.
>
> Also, be forewarned that buying MS Small Business Server 2003 is not a
> recomended choice to use for the MS-SQL Server or the Vantage Server due
> to
> an unknown number of built in security "features" and settings for the
> "Small Business Owner" that it defaults to differently from a normal
> standard or enterprise installation of Server 2003.
>
> Also, only in very rare instances will anyone need the enterprise version
> of
> MS-SQL server, along with very rarely will anyone need to be running their
> MS-SQL DB in Unicode.
>
> ----- Original Message -----
> From: "Mark Wonsil"
> <mark_wonsil@ yahoo.com<mailto:mark_ wonsil%40yahoo. com>>
> To: <vantage@yahoogroups .com<mailto:vantage% 40yahoogroups. com>>
> Sent: Thursday, March 26, 2009 11:33 AM
> Subject: [Vantage] To SQL or not to SQL
>
>> Just to add to the SQL discussion, here are the Epicor Products that
>> require
>> SQL:
>>
>> Epicor Portal (Full version, no express versions)
>> Advanced Print
>> Replication Server
>> Enterprise Search
>> (Progress users apparently have to purchase Replication Server to use
>> Enterprise search)
>> Service Connect
>> SharePoint Services (if used for attachments in Epicor 9)
>> Cube-Connect
>> Performance Canvas/FRx
>>
>> There may be others (Open 4? AQM?)...
>>
>>
>>
>> ------------ --------- --------- ------
>>
>> 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/.<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
>>
>>
>>
>
>
>
> [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
>
>
>

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

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





















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

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
To add my two cents:



I'm the guy who is doing the back-end stuff that Rob was referring to.



While I am getting the job done using the OpenEdge ODBC driver, the
implementation of ODBC that Progress has provided is way below the
capabilities of what can be done using SQL server.



The most frustrating part is whenever it becomes necessary to use nested
queries or correlated subqueries. A simple task of updating a user
defined field in thousands of records becomes an incredibly painful,
time consuming effort. The optimization steps in the SQL interpreter is
also deficient. It's all to easy to have a relatively simple query take
an inordinate amount of time because of its apparent desire to link
thousands of records first instead of applying the WHERE filters which
would limit the record set dramatically.



The development/design tools relating to SQL are also very limited.



SQL/Progress are the same? Not by a long shot if you are talking about
integration efforts.



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]
I also agree with the statement Robert makes. I have been a SQL Server user since 6.5 and was thankful that Epicor had this option. We seriously considered just going with Progress for speed, but SQL won in the end after having some frank discussions with Epicor.

We have been live for about a year and already are moving items away from the Vantage UI such as reporting and using triggers instead of BPM's. I can browse data easily, utilize SQL Server Agent and have a great comfort level with my server. I haven't started on views or SP's yet, but will soon.

So what I've sacrificed in speed I've gained in freedom. This has a payback to users as well. As I move more services away from the Vantage UI, staff on the shop floor can see the information they need without utilizing existing licensing and Progress's resources.


Ron B


--- In vantage@yahoogroups.com, Robert Brown <robertb_versa@...> wrote:
>
> It really comes down to comfort level (which devil do you prefer? :)
>
Ron,
Sorry to rain on your parade but are you concerned with who comes after you to keep the system running? No one is indispensable. All the whiz-bang things you can do in SQL need to be carefully documented and management needs to understand that your replacement will need to be someone with at least your skills level to keep the ship afloat.
-Karl

--- On Fri, 3/27/09, Ron B <obersenf@...> wrote:


From: Ron B <obersenf@...>
Subject: [Vantage] Re: To SQL or not to SQL
To: vantage@yahoogroups.com
Date: Friday, March 27, 2009, 9:39 AM







I also agree with the statement Robert makes. I have been a SQL Server user since 6.5 and was thankful that Epicor had this option. We seriously considered just going with Progress for speed, but SQL won in the end after having some frank discussions with Epicor.

We have been live for about a year and already are moving items away from the Vantage UI such as reporting and using triggers instead of BPM's. I can browse data easily, utilize SQL Server Agent and have a great comfort level with my server. I haven't started on views or SP's yet, but will soon.

So what I've sacrificed in speed I've gained in freedom. This has a payback to users as well. As I move more services away from the Vantage UI, staff on the shop floor can see the information they need without utilizing existing licensing and Progress's resources.

Ron B

--- In vantage@yahoogroups .com, Robert Brown <robertb_versa@ ...> wrote:
>
> It really comes down to comfort level (which devil do you prefer? :)
>



















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