Vantage 6.1.538 & converting from Progress 9.1D to SQL 2000

Yahoo Archive
1
John,

Do I ever feel like a idiot. I completly overlooked the save
password checkbox.

This worked great.

Thank you very much!!!
Tony

--- In vantage@yahoogroups.com, John Sage <list@...> wrote:
>
> Tony,
>
> I haven't noticed the problem you mentioned. Have you saved the
ODBC
> password in the Linked Table Manager when you link to the Progress
> tables from Access?
>
> From the Access menu:
>
> ->File
> -->Get External Data
> --->Link Tables
>
> This opens a Link dialog:
>
> Files of Type
> ->ODBC Databases
> -->Machine Data Source
> --->PROGRESS (or whatever you've called your Merant driver)
> ---->OK
>
> This opens the Progress SQL92 Driver Logon:
> ->(Input Password)
> -->OK
>
> This opens the Link Tables dialog:
> ->select table(s)
> -->check "Save Password"
> --->OK
>
>
> If using MSQuery, you have to manually edit the DSN part of the
query
> file (*.dqy) as follows (use Notepad):
>
> XLODBC
> 1
>
DSN=PROGRESS;UID=SYSPROGRESS;PWD=sysprogress;HOST=hostname;PORT=port;
DB=mfgsys
> (Your SQL statement here)
>
> In the above example, the DSN name is assumed to be PROGRESS, UID
and
> PWD are the ODBC credentials (you can set up your own, and you
should,
> for security), HOST is the Progress server, PORT is the port
number, and
> DB is the name of the Vantage database.
>
> When the resulting dqy files is double-clicked, it will launch
Excel and
> populate the spreadsheet with the results of the query.
>
>
> have fun,
> john
>
>
>
>
>
>
> sheehanam21 wrote:
> >
> >
> > John,
> >
> > Thank you for your comments.
> >
> > I am familiar with ODBC and I do use MS Access to extract data.
> > However, and I've spoken with Epicor about this, after linking to
> > the tables in Progress via ODBC I am able to do what I want. The
> > problem I have with the Merant ODBC DSN is that after closing and
> > reopening Access I cannot view the data from the linked table,
nor
> > can I recreate the links. I basically have to start an entirly
new
> > session of Access before this will work. I'm not sure if this is
an
> > Access problem or a Merant problem.
> >
> > Maybe this is something you've experienced and can share your
> > solution?
> >
> > Thank you,
> > Tony
>
2
I am looking to convert my database very soon. However, I hear rumors
about horriable performance issues with SQL.

I spoke with Epicor and was told that Vantage should perform just as
well on SQL as it does with Progress. I was also told that those
user's hardware could have played a big part in the issues I am
hearing about.

My question to you is: How true are these rumors? And, if I have
dual 3 GHz Xeon processors with 2 Gigs of RAM, will I have performance
issues?

Thank you in advance,
Tony
3
I wouldn't do it at V6.1. There is no way the two are comparable in performance. Some even say that SQL performance at V8 is slower than OpenEdge. I looked at changing over when going V8 but I just couldn't come up with enough compelling reasons to do so. If you are serious about changing I would take a hard look at what you are going to gain and I would set it up in a test environment and attempt quantify Epicors performance claims in your environment with your data.

Todd

________________________________

From: vantage@yahoogroups.com on behalf of sheehanam21
Sent: Thu 2/15/2007 5:38 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Vantage 6.1.538 & converting from Progress 9.1D to SQL 2000



I am looking to convert my database very soon. However, I hear rumors
about horriable performance issues with SQL.

I spoke with Epicor and was told that Vantage should perform just as
well on SQL as it does with Progress. I was also told that those
user's hardware could have played a big part in the issues I am
hearing about.

My question to you is: How true are these rumors? And, if I have
dual 3 GHz Xeon processors with 2 Gigs of RAM, will I have performance
issues?

Thank you in advance,
Tony






This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other
than the intended recipient is unauthorized and may be illegal.

[Non-text portions of this message have been removed]
4
Thank you for the information Todd but what I'm looking for is some
concrete proof that this is a bad idea. I have not purchased SQL
yet and do not want to spend the money on it if it is going to be a
waist.

You say you couldn't come up with enough compelling reasons to
convert to SQL. With me knowing SQL the way I do, I can come up
with a lot of compelling reasons. The only thing holding me back
right now is the performance of Vantage.

If I may, what are the reasons why you decided not to covert to SQL
and what are you backing those reasons up with?

Thank you,
Tony

--- In vantage@yahoogroups.com, "Todd Hofert" <todd@...> wrote:
>
> I wouldn't do it at V6.1. There is no way the two are comparable
in performance. Some even say that SQL performance at V8 is slower
than OpenEdge. I looked at changing over when going V8 but I just
couldn't come up with enough compelling reasons to do so. If you are
serious about changing I would take a hard look at what you are
going to gain and I would set it up in a test environment and
attempt quantify Epicors performance claims in your environment with
your data.
>
> Todd
>
> ________________________________
>
> From: vantage@yahoogroups.com on behalf of sheehanam21
> Sent: Thu 2/15/2007 5:38 PM
> To: vantage@yahoogroups.com
> Subject: [Vantage] Vantage 6.1.538 & converting from Progress 9.1D
to SQL 2000
>
>
>
> I am looking to convert my database very soon. However, I hear
rumors
> about horriable performance issues with SQL.
>
> I spoke with Epicor and was told that Vantage should perform just
as
> well on SQL as it does with Progress. I was also told that those
> user's hardware could have played a big part in the issues I am
> hearing about.
>
> My question to you is: How true are these rumors? And, if I have
> dual 3 GHz Xeon processors with 2 Gigs of RAM, will I have
performance
> issues?
>
> Thank you in advance,
> Tony
>
>
>
>
>
>
> This e-mail and any attachments may contain confidential and
privileged
> information. If you are not the intended recipient, please notify
the
> sender immediately by return e-mail, delete this e-mail and
destroy any
> copies. Any dissemination or use of this information by a person
other
> than the intended recipient is unauthorized and may be illegal.
>
> [Non-text portions of this message have been removed]
>
5
I don't know what your environment is but in ours I struggled to find
value that out weighed the performance issues. In our environment, my
first priority is the end user experience. And let's face it if
performance wasn't an issue there wouldn't be as much discussion on the
topic as there is.



I have 4 SQL Servers running 7 databases, I have an Oracle server and I
have three servers running various versions of Progress/OpenEdge
databases. My original intent to move Vantage to SQL was more
flexibility with the admin tools, the more commonly used language etc..
When it comes down to it however, I am from the school of if it ain't
broke don't fix it. In the 10 years of supporting the Progress
environment I really can't come up with a time when I couldn't do what I
needed to do with the Progress tools. In the end I was not willing to
sacrifice the efficiency of our entire business operation to provide
myself with some convenient tools that would occasionally come in handy.
Personally, if it were me I wouldn't do it without concrete proof
either. The only way I can think of coming up with that concrete proof
would be to test it in my own environment.



Todd







From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
Of sheehanam21
Sent: Thursday, February 15, 2007 7:42 PM
To: vantage@yahoogroups.com
Subject: [Vantage] Re: Vantage 6.1.538 & converting from Progress 9.1D
to SQL 2000



Thank you for the information Todd but what I'm looking for is some
concrete proof that this is a bad idea. I have not purchased SQL
yet and do not want to spend the money on it if it is going to be a
waist.

You say you couldn't come up with enough compelling reasons to
convert to SQL. With me knowing SQL the way I do, I can come up
with a lot of compelling reasons. The only thing holding me back
right now is the performance of Vantage.

If I may, what are the reasons why you decided not to covert to SQL
and what are you backing those reasons up with?

Thank you,
Tony

--- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
"Todd Hofert" <todd@...> wrote:
>
> I wouldn't do it at V6.1. There is no way the two are comparable
in performance. Some even say that SQL performance at V8 is slower
than OpenEdge. I looked at changing over when going V8 but I just
couldn't come up with enough compelling reasons to do so. If you are
serious about changing I would take a hard look at what you are
going to gain and I would set it up in a test environment and
attempt quantify Epicors performance claims in your environment with
your data.
>
> Todd
>
> ________________________________
>
> From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> on
behalf of sheehanam21
> Sent: Thu 2/15/2007 5:38 PM
> To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> Subject: [Vantage] Vantage 6.1.538 & converting from Progress 9.1D
to SQL 2000
>
>
>
> I am looking to convert my database very soon. However, I hear
rumors
> about horriable performance issues with SQL.
>
> I spoke with Epicor and was told that Vantage should perform just
as
> well on SQL as it does with Progress. I was also told that those
> user's hardware could have played a big part in the issues I am
> hearing about.
>
> My question to you is: How true are these rumors? And, if I have
> dual 3 GHz Xeon processors with 2 Gigs of RAM, will I have
performance
> issues?
>
> Thank you in advance,
> Tony
>
>
>
>
>
>
> This e-mail and any attachments may contain confidential and
privileged
> information. If you are not the intended recipient, please notify
the
> sender immediately by return e-mail, delete this e-mail and
destroy any
> copies. Any dissemination or use of this information by a person
other
> than the intended recipient is unauthorized and may be illegal.
>
> [Non-text portions of this message have been removed]
>





This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other
than the intended recipient is unauthorized and may be illegal.

[Non-text portions of this message have been removed]
6
This is all great information to know Todd and I appreciate your
honesty.

I too believe if it aint broke don't fix it. However, our system is
broken in a way that the users are not using Vantage the way it is
supposed to be used and no one is willing to take to time to learn the
right way because they are all too busy. I continuously promote tools
for training and have scheduled people to come in and train them.

Instead of forcing people to change I figured I'd try to provide them
with tools like automated reporting and integrate departmentalize
databases that work with Vantage to provide them the information they
need that Vantage does not provide; or cost a small fortune to purchase.

As discussed on the CIO website about "The Shadow IT Department" I
believe it is big part of my problem. Users will find a way to get
there job done, and instead of forcing them to change I believe that
working with them to provide the information needed is key.

Unfortunate for me, I am not well versed in Progress and have a
difficult time working with it. Mainly because I cannot accomplish
anything until 3am when no one is logged into the database. Because
of this I believe SQL will allow me to provide the necessary
information they need, which can also keep the users who only need
reports out of Vantage. I realize this will not keep everyone out but
it can lower the need to log in as often.

Sorry if I got a little carried away but I thought that understanding
where I'm coming from and what I am trying to accomplish could help
you better understand what I'm trying to accomplish.

Beings that you've worked with Progress for some time maybe you can
offer up a solution that will allow me to accomplish what I'm trying
to accomplish.

I've thought about BI but that is an extremely expensive solution that
I would have to bring in a consultant to implement and I know my
company is not willing to pay for at this time; maybe in a couple years.

Thanks,
Tony

--- In vantage@yahoogroups.com, "Todd Hofert" <todd@...> wrote:
>
> I don't know what your environment is but in ours I struggled to find
> value that out weighed the performance issues. In our environment, my
> first priority is the end user experience. And let's face it if
> performance wasn't an issue there wouldn't be as much discussion on the
> topic as there is.
>
>
>
> I have 4 SQL Servers running 7 databases, I have an Oracle server and I
> have three servers running various versions of Progress/OpenEdge
> databases. My original intent to move Vantage to SQL was more
> flexibility with the admin tools, the more commonly used language etc..
> When it comes down to it however, I am from the school of if it ain't
> broke don't fix it. In the 10 years of supporting the Progress
> environment I really can't come up with a time when I couldn't do what I
> needed to do with the Progress tools. In the end I was not willing to
> sacrifice the efficiency of our entire business operation to provide
> myself with some convenient tools that would occasionally come in handy.
> Personally, if it were me I wouldn't do it without concrete proof
> either. The only way I can think of coming up with that concrete proof
> would be to test it in my own environment.
>
>
>
> Todd
>
>
>
>
>
>
>
> From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf
> Of sheehanam21
> Sent: Thursday, February 15, 2007 7:42 PM
> To: vantage@yahoogroups.com
> Subject: [Vantage] Re: Vantage 6.1.538 & converting from Progress 9.1D
> to SQL 2000
>
>
>
> Thank you for the information Todd but what I'm looking for is some
> concrete proof that this is a bad idea. I have not purchased SQL
> yet and do not want to spend the money on it if it is going to be a
> waist.
>
> You say you couldn't come up with enough compelling reasons to
> convert to SQL. With me knowing SQL the way I do, I can come up
> with a lot of compelling reasons. The only thing holding me back
> right now is the performance of Vantage.
>
> If I may, what are the reasons why you decided not to covert to SQL
> and what are you backing those reasons up with?
>
> Thank you,
> Tony
>
> --- In vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> ,
> "Todd Hofert" <todd@> wrote:
> >
> > I wouldn't do it at V6.1. There is no way the two are comparable
> in performance. Some even say that SQL performance at V8 is slower
> than OpenEdge. I looked at changing over when going V8 but I just
> couldn't come up with enough compelling reasons to do so. If you are
> serious about changing I would take a hard look at what you are
> going to gain and I would set it up in a test environment and
> attempt quantify Epicors performance claims in your environment with
> your data.
> >
> > Todd
> >
> > ________________________________
> >
> > From: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com> on
> behalf of sheehanam21
> > Sent: Thu 2/15/2007 5:38 PM
> > To: vantage@yahoogroups.com <mailto:vantage%40yahoogroups.com>
> > Subject: [Vantage] Vantage 6.1.538 & converting from Progress 9.1D
> to SQL 2000
> >
> >
> >
> > I am looking to convert my database very soon. However, I hear
> rumors
> > about horriable performance issues with SQL.
> >
> > I spoke with Epicor and was told that Vantage should perform just
> as
> > well on SQL as it does with Progress. I was also told that those
> > user's hardware could have played a big part in the issues I am
> > hearing about.
> >
> > My question to you is: How true are these rumors? And, if I have
> > dual 3 GHz Xeon processors with 2 Gigs of RAM, will I have
> performance
> > issues?
> >
> > Thank you in advance,
> > Tony
> >
> >
> >
> >
> >
> >
> > This e-mail and any attachments may contain confidential and
> privileged
> > information. If you are not the intended recipient, please notify
> the
> > sender immediately by return e-mail, delete this e-mail and
> destroy any
> > copies. Any dissemination or use of this information by a person
> other
> > than the intended recipient is unauthorized and may be illegal.
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>
>
>
> This e-mail and any attachments may contain confidential and privileged
> information. If you are not the intended recipient, please notify the
> sender immediately by return e-mail, delete this e-mail and destroy any
> copies. Any dissemination or use of this information by a person other
> than the intended recipient is unauthorized and may be illegal.
>
> [Non-text portions of this message have been removed]
>
7
Tony,

If you're considering SQL Server in order to facilitate reporting
solutions, you've followed the wrong branch in your decision tree. In
this case, the back end is going to have little impact on your ability
to extract data.

We make extensive use of clickable queries (msqry32.exe) and MS Access
reports via ODBC connection to the Progress database. Examples of the
solutions we've deployed via this method are:

Automated multi-level BOM extraction
Production analysis & planning
Raw material analysis & planning
Planned/Actual departmental budget analysis & planning
Vendor OTD & spending
Customer OTD
Attendance tracking & analysis

... and many, many others.

SQL Server with Open Edge / Vantage / Progress will leave you at a very
sub-optimal level of performance if you trust the experiences of the
users on this list.

OTOH, Progress is stable, solid, reliable ... and fast.

If you are at all familiar with ODBC, then you'll have zero difficulty
extracting the data your users need from Progress.


john



sheehanam21 wrote:
>
>
>
> Unfortunate for me, I am not well versed in Progress and have a
> difficult time working with it. Mainly because I cannot accomplish
> anything until 3am when no one is logged into the database. Because
> of this I believe SQL will allow me to provide the necessary
> information they need, which can also keep the users who only need
> reports out of Vantage. I realize this will not keep everyone out but
> it can lower the need to log in as often.
8
John,

Thank you for your comments.

I am familiar with ODBC and I do use MS Access to extract data.
However, and I've spoken with Epicor about this, after linking to
the tables in Progress via ODBC I am able to do what I want. The
problem I have with the Merant ODBC DSN is that after closing and
reopening Access I cannot view the data from the linked table, nor
can I recreate the links. I basically have to start an entirly new
session of Access before this will work. I'm not sure if this is an
Access problem or a Merant problem.

Maybe this is something you've experienced and can share your
solution?

Thank you,
Tony

--- In vantage@yahoogroups.com, John Sage <list@...> wrote:
>
> Tony,
>
> If you're considering SQL Server in order to facilitate reporting
> solutions, you've followed the wrong branch in your decision
tree. In
> this case, the back end is going to have little impact on your
ability
> to extract data.
>
> We make extensive use of clickable queries (msqry32.exe) and MS
Access
> reports via ODBC connection to the Progress database. Examples of
the
> solutions we've deployed via this method are:
>
> Automated multi-level BOM extraction
> Production analysis & planning
> Raw material analysis & planning
> Planned/Actual departmental budget analysis & planning
> Vendor OTD & spending
> Customer OTD
> Attendance tracking & analysis
>
> ... and many, many others.
>
> SQL Server with Open Edge / Vantage / Progress will leave you at a
very
> sub-optimal level of performance if you trust the experiences of
the
> users on this list.
>
> OTOH, Progress is stable, solid, reliable ... and fast.
>
> If you are at all familiar with ODBC, then you'll have zero
difficulty
> extracting the data your users need from Progress.
>
>
> john
>
>
>
> sheehanam21 wrote:
> >
> >
> >
> > Unfortunate for me, I am not well versed in Progress and have a
> > difficult time working with it. Mainly because I cannot
accomplish
> > anything until 3am when no one is logged into the database.
Because
> > of this I believe SQL will allow me to provide the necessary
> > information they need, which can also keep the users who only
need
> > reports out of Vantage. I realize this will not keep everyone
out but
> > it can lower the need to log in as often.
>
9
Tony,

I haven't noticed the problem you mentioned. Have you saved the ODBC
password in the Linked Table Manager when you link to the Progress
tables from Access?

From the Access menu:

->File
-->Get External Data
--->Link Tables

This opens a Link dialog:

Files of Type
->ODBC Databases
-->Machine Data Source
--->PROGRESS (or whatever you've called your Merant driver)
---->OK

This opens the Progress SQL92 Driver Logon:
->(Input Password)
-->OK

This opens the Link Tables dialog:
->select table(s)
-->check "Save Password"
--->OK


If using MSQuery, you have to manually edit the DSN part of the query
file (*.dqy) as follows (use Notepad):

XLODBC
1
DSN=PROGRESS;UID=SYSPROGRESS;PWD=sysprogress;HOST=hostname;PORT=port;DB=mfgsys
(Your SQL statement here)

In the above example, the DSN name is assumed to be PROGRESS, UID and
PWD are the ODBC credentials (you can set up your own, and you should,
for security), HOST is the Progress server, PORT is the port number, and
DB is the name of the Vantage database.

When the resulting dqy files is double-clicked, it will launch Excel and
populate the spreadsheet with the results of the query.


have fun,
john






sheehanam21 wrote:
>
>
> John,
>
> Thank you for your comments.
>
> I am familiar with ODBC and I do use MS Access to extract data.
> However, and I've spoken with Epicor about this, after linking to
> the tables in Progress via ODBC I am able to do what I want. The
> problem I have with the Merant ODBC DSN is that after closing and
> reopening Access I cannot view the data from the linked table, nor
> can I recreate the links. I basically have to start an entirly new
> session of Access before this will work. I'm not sure if this is an
> Access problem or a Merant problem.
>
> Maybe this is something you've experienced and can share your
> solution?
>
> Thank you,
> Tony