Showing posts with label versus. Show all posts
Showing posts with label versus. Show all posts

Friday, March 30, 2012

Pros and Cons of saving to serverstorage versus file system

What are the pros and cons of saving the SSIS package using serverstorage versus file system? It appears to me that the file system is much flexible and can be promoted anywhere without going through the hassle of exporting off from msdb etc.

Thanks,
Lito

Lito wrote:

What are the pros and cons of saving the SSIS package using serverstorage versus file system? It appears to me that the file system is much flexible and can be promoted anywhere without going through the hassle of exporting off from msdb etc.

Thanks,
Lito

I agree. The single biggest issue I have with server deployment is that you bring a whole new layer of management into play if you're using the Execute Package task (which likely many people will be).
i.e. At design time you use a file connection manager for calling other packages...at runtime you use OLE DB connection manager. So not only do you have to tell the package which environment its running in so that it knows which connection manager to use...promoting from dev-->test-->live becomes a real headache because you don't have uniformity across environments.

Just my 2 penneth worth!

-Jamie|||Kirk has blogged about some of the Pros and Cons of saving to SQL Server Vs File System. See

http://sqljunkies.com/WebLog/knight_reign/archive/2005/05/05/13523.aspx

- Ranjeeta

Pros and Cons of saving to serverstorage versus file system

What are the pros and cons of saving the SSIS package using serverstorage versus file system? It appears to me that the file system is much flexible and can be promoted anywhere without going through the hassle of exporting off from msdb etc.

Thanks,
Lito

Lito wrote:

What are the pros and cons of saving the SSIS package using serverstorage versus file system? It appears to me that the file system is much flexible and can be promoted anywhere without going through the hassle of exporting off from msdb etc.

Thanks,
Lito

I agree. The single biggest issue I have with server deployment is that you bring a whole new layer of management into play if you're using the Execute Package task (which likely many people will be).
i.e. At design time you use a file connection manager for calling other packages...at runtime you use OLE DB connection manager. So not only do you have to tell the package which environment its running in so that it knows which connection manager to use...promoting from dev-->test-->live becomes a real headache because you don't have uniformity across environments.

Just my 2 penneth worth!

-Jamie|||Kirk has blogged about some of the Pros and Cons of saving to SQL Server Vs File System. See

http://sqljunkies.com/WebLog/knight_reign/archive/2005/05/05/13523.aspx

- Ranjeeta

Monday, March 26, 2012

Proper name for average types

Is there a proper name for the type of Average which the AVG() function
returns, where NULLs are eliminated versus: an Average calculated by
dividing the SUM() of the column by the COUNT(*) of the table?
It seems as if the AVG() function by itself returns the same result as if
you assigned an 'average' value to the NULLs:
i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; you
would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }
It also seems as if dividing the SUM() of the column by the COUNT(*) of the
table gives the same result as if you treated NULLs as zero:
i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0)) would
return 10; SUM(column)/COUNT(*) would return 10 as well.
Anyway, just wondering if there was a proper name for these different
averages. Thanks.I do not think there is a proper name... The thing is that if you consider
NULLs you must give them some value, when you use sum/ Count(*) it act as
if the Null values are zero...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Michael C#" <xyz@.abcdef.com> wrote in message
news:2Bfte.15144$l_2.5675@.fe09.lga...
> Is there a proper name for the type of Average which the AVG() function
> returns, where NULLs are eliminated versus: an Average calculated by
> dividing the SUM() of the column by the COUNT(*) of the table?
> It seems as if the AVG() function by itself returns the same result as if
> you assigned an 'average' value to the NULLs:
> i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; you
> would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }
> It also seems as if dividing the SUM() of the column by the COUNT(*) of
> the table gives the same result as if you treated NULLs as zero:
> i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0))
> would return 10; SUM(column)/COUNT(*) would return 10 as well.
> Anyway, just wondering if there was a proper name for these different
> averages. Thanks.
>|||On Sun, 19 Jun 2005 10:48:23 -0400, Michael C# wrote:
>Is there a proper name for the type of Average which the AVG() function
>returns, where NULLs are eliminated versus: an Average calculated by
>dividing the SUM() of the column by the COUNT(*) of the table?
>It seems as if the AVG() function by itself returns the same result as if
>you assigned an 'average' value to the NULLs:
>i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; you
>would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }
>It also seems as if dividing the SUM() of the column by the COUNT(*) of the
>table gives the same result as if you treated NULLs as zero:
>i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0)) would
>return 10; SUM(column)/COUNT(*) would return 10 as well.
>Anyway, just wondering if there was a proper name for these different
>averages. Thanks.
>
Hi Michael,
The proper name is "average".
>i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; you
>would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }
I'd call this "average" or, if I really must be explicit, "average of
only the values that are not missing" (but since eliminating NULLS
before applying an aggregate is SOP in SQL, that's really just some
extra unnecessary redundancy).
>i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0)) would
>return 10; SUM(column)/COUNT(*) would return 10 as well.
I'd call this "average of the set after replacing missing values by the
arbitrarily chosen value of zero". Of course, the function itself is
still just called "average" - the rest actually described the COALESCE
expression that is used as argument for the AVG().
(Similarly, for AVG(A + B), I'd say "the average of the sum of A and B")
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||The AVG function is simply the Arithmetic Mean but with the additional rule
that NULL values are ignored. If you prefer to be a bit more explicit about
that calculation then maybe you could add x IS NOT NULL to your WHERE
clause. If you want to include NULLs in the computation then you can
substitute some alternative expression inside the AVG funcion. For example:
AVG(COALESCE(x,0)).
--
David Portas
SQL Server MVP
--|||"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:jqnbb19pig8vfd8ev7pgtqj59gact2h2ou@.4ax.com...
> On Sun, 19 Jun 2005 10:48:23 -0400, Michael C# wrote:
>>Is there a proper name for the type of Average which the AVG() function
>>returns, where NULLs are eliminated versus: an Average calculated by
>>dividing the SUM() of the column by the COUNT(*) of the table?
>>It seems as if the AVG() function by itself returns the same result as if
>>you assigned an 'average' value to the NULLs:
>>i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; you
>>would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }
>>It also seems as if dividing the SUM() of the column by the COUNT(*) of
>>the
>>table gives the same result as if you treated NULLs as zero:
>>i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0))
>>would
>>return 10; SUM(column)/COUNT(*) would return 10 as well.
>>Anyway, just wondering if there was a proper name for these different
>>averages. Thanks.
> Hi Michael,
> The proper name is "average".
>>i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; you
>>would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }
> I'd call this "average" or, if I really must be explicit, "average of
> only the values that are not missing" (but since eliminating NULLS
> before applying an aggregate is SOP in SQL, that's really just some
> extra unnecessary redundancy).
>>i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0))
>>would
>>return 10; SUM(column)/COUNT(*) would return 10 as well.
> I'd call this "average of the set after replacing missing values by the
> arbitrarily chosen value of zero". Of course, the function itself is
> still just called "average" - the rest actually described the COALESCE
> expression that is used as argument for the AVG().
> (Similarly, for AVG(A + B), I'd say "the average of the sum of A and B")
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)
It's all redundancy; that's why I was wondering if there was a more
'concise' way to say it.
I guess "10 words or less" is out of the question.|||Actually I was just wondering if there was a more concise way to say it.
Apparently "SQL AVG()" is about as concise as it gets; it seems there's no
concise term to describe how it arrives at an answer.
Thanks
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:hL2dna5IZ4cocyjfRVn-2w@.giganews.com...
> The AVG function is simply the Arithmetic Mean but with the additional
> rule that NULL values are ignored. If you prefer to be a bit more explicit
> about that calculation then maybe you could add x IS NOT NULL to your
> WHERE clause. If you want to include NULLs in the computation then you can
> substitute some alternative expression inside the AVG funcion. For
> example: AVG(COALESCE(x,0)).
> --
> David Portas
> SQL Server MVP
> --
>

Proper name for average types

Is there a proper name for the type of Average which the AVG() function
returns, where NULLs are eliminated versus: an Average calculated by
dividing the SUM() of the column by the COUNT(*) of the table?
It seems as if the AVG() function by itself returns the same result as if
you assigned an 'average' value to the NULLs:
i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; y
ou
would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 2
0 }
It also seems as if dividing the SUM() of the column by the COUNT(*) of the
table gives the same result as if you treated NULLs as zero:
i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0))
would
return 10; SUM(column)/COUNT(*) would return 10 as well.
Anyway, just wondering if there was a proper name for these different
averages. Thanks.I do not think there is a proper name... The thing is that if you consider
NULLs you must give them some value, when you use sum/ Count(*) it act as
if the Null values are zero...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Michael C#" <xyz@.abcdef.com> wrote in message
news:2Bfte.15144$l_2.5675@.fe09.lga...
> Is there a proper name for the type of Average which the AVG() function
> returns, where NULLs are eliminated versus: an Average calculated by
> dividing the SUM() of the column by the COUNT(*) of the table?
> It seems as if the AVG() function by itself returns the same result as if
> you assigned an 'average' value to the NULLs:
> i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5;
you
> would get the same result for the AVG() of the set { 5, 10, 15, 12.5,
20 }
> It also seems as if dividing the SUM() of the column by the COUNT(*) of
> the table gives the same result as if you treated NULLs as zero:
> i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0)
)
> would return 10; SUM(column)/COUNT(*) would return 10 as well.
> Anyway, just wondering if there was a proper name for these different
> averages. Thanks.
>|||On Sun, 19 Jun 2005 10:48:23 -0400, Michael C# wrote:

>Is there a proper name for the type of Average which the AVG() function
>returns, where NULLs are eliminated versus: an Average calculated by
>dividing the SUM() of the column by the COUNT(*) of the table?
>It seems as if the AVG() function by itself returns the same result as if
>you assigned an 'average' value to the NULLs:
>i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5;
you
>would get the same result for the AVG() of the set { 5, 10, 15, 12.5,
20 }
>It also seems as if dividing the SUM() of the column by the COUNT(*) of the
>table gives the same result as if you treated NULLs as zero:
>i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0))
would
>return 10; SUM(column)/COUNT(*) would return 10 as well.
>Anyway, just wondering if there was a proper name for these different
>averages. Thanks.
>
Hi Michael,
The proper name is "average".

>i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5;
you
>would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }[/vb
col]
I'd call this "average" or, if I really must be explicit, "average of
only the values that are not missing" (but since eliminating NULLS
before applying an aggregate is SOP in SQL, that's really just some
extra unnecessary redundancy).
[vbcol=seagreen]
>i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0))
would
>return 10; SUM(column)/COUNT(*) would return 10 as well.
I'd call this "average of the set after replacing missing values by the
arbitrarily chosen value of zero". Of course, the function itself is
still just called "average" - the rest actually described the COALESCE
expression that is used as argument for the AVG().
(Similarly, for AVG(A + B), I'd say "the average of the sum of A and B")
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||The AVG function is simply the Arithmetic Mean but with the additional rule
that NULL values are ignored. If you prefer to be a bit more explicit about
that calculation then maybe you could add x IS NOT NULL to your WHERE
clause. If you want to include NULLs in the computation then you can
substitute some alternative expression inside the AVG funcion. For example:
AVG(COALESCE(x,0)).
David Portas
SQL Server MVP
--|||"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:jqnbb19pig8vfd8ev7pgtqj59gact2h2ou@.
4ax.com...
> On Sun, 19 Jun 2005 10:48:23 -0400, Michael C# wrote:
>
> Hi Michael,
> The proper name is "average".
>
> I'd call this "average" or, if I really must be explicit, "average of
> only the values that are not missing" (but since eliminating NULLS
> before applying an aggregate is SOP in SQL, that's really just some
> extra unnecessary redundancy).
>
> I'd call this "average of the set after replacing missing values by the
> arbitrarily chosen value of zero". Of course, the function itself is
> still just called "average" - the rest actually described the COALESCE
> expression that is used as argument for the AVG().
> (Similarly, for AVG(A + B), I'd say "the average of the sum of A and B")
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)
It's all redundancy; that's why I was wondering if there was a more
'concise' way to say it.
I guess "10 words or less" is out of the question.|||Actually I was just wondering if there was a more concise way to say it.
Apparently "SQL AVG()" is about as concise as it gets; it seems there's no
concise term to describe how it arrives at an answer.
Thanks
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:hL2dna5IZ4cocyjfRVn-2w@.giganews.com...
> The AVG function is simply the Arithmetic Mean but with the additional
> rule that NULL values are ignored. If you prefer to be a bit more explicit
> about that calculation then maybe you could add x IS NOT NULL to your
> WHERE clause. If you want to include NULLs in the computation then you can
> substitute some alternative expression inside the AVG funcion. For
> example: AVG(COALESCE(x,0)).
> --
> David Portas
> SQL Server MVP
> --
>

Proper name for average types

Is there a proper name for the type of Average which the AVG() function
returns, where NULLs are eliminated versus: an Average calculated by
dividing the SUM() of the column by the COUNT(*) of the table?
It seems as if the AVG() function by itself returns the same result as if
you assigned an 'average' value to the NULLs:
i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; you
would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }
It also seems as if dividing the SUM() of the column by the COUNT(*) of the
table gives the same result as if you treated NULLs as zero:
i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0)) would
return 10; SUM(column)/COUNT(*) would return 10 as well.
Anyway, just wondering if there was a proper name for these different
averages. Thanks.
I do not think there is a proper name... The thing is that if you consider
NULLs you must give them some value, when you use sum/ Count(*) it act as
if the Null values are zero...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Michael C#" <xyz@.abcdef.com> wrote in message
news:2Bfte.15144$l_2.5675@.fe09.lga...
> Is there a proper name for the type of Average which the AVG() function
> returns, where NULLs are eliminated versus: an Average calculated by
> dividing the SUM() of the column by the COUNT(*) of the table?
> It seems as if the AVG() function by itself returns the same result as if
> you assigned an 'average' value to the NULLs:
> i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; you
> would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }
> It also seems as if dividing the SUM() of the column by the COUNT(*) of
> the table gives the same result as if you treated NULLs as zero:
> i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0))
> would return 10; SUM(column)/COUNT(*) would return 10 as well.
> Anyway, just wondering if there was a proper name for these different
> averages. Thanks.
>
|||On Sun, 19 Jun 2005 10:48:23 -0400, Michael C# wrote:

>Is there a proper name for the type of Average which the AVG() function
>returns, where NULLs are eliminated versus: an Average calculated by
>dividing the SUM() of the column by the COUNT(*) of the table?
>It seems as if the AVG() function by itself returns the same result as if
>you assigned an 'average' value to the NULLs:
>i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; you
>would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }
>It also seems as if dividing the SUM() of the column by the COUNT(*) of the
>table gives the same result as if you treated NULLs as zero:
>i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0)) would
>return 10; SUM(column)/COUNT(*) would return 10 as well.
>Anyway, just wondering if there was a proper name for these different
>averages. Thanks.
>
Hi Michael,
The proper name is "average".

>i.e., for the set { 5, 10, 15, NULL, 20 }, the AVG() average is 12.5; you
>would get the same result for the AVG() of the set { 5, 10, 15, 12.5, 20 }
I'd call this "average" or, if I really must be explicit, "average of
only the values that are not missing" (but since eliminating NULLS
before applying an aggregate is SOP in SQL, that's really just some
extra unnecessary redundancy).

>i.e., for the set {5, 10, 15, NULL, 20 }, the AVG(COALESCE(column, 0)) would
>return 10; SUM(column)/COUNT(*) would return 10 as well.
I'd call this "average of the set after replacing missing values by the
arbitrarily chosen value of zero". Of course, the function itself is
still just called "average" - the rest actually described the COALESCE
expression that is used as argument for the AVG().
(Similarly, for AVG(A + B), I'd say "the average of the sum of A and B")
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
|||The AVG function is simply the Arithmetic Mean but with the additional rule
that NULL values are ignored. If you prefer to be a bit more explicit about
that calculation then maybe you could add x IS NOT NULL to your WHERE
clause. If you want to include NULLs in the computation then you can
substitute some alternative expression inside the AVG funcion. For example:
AVG(COALESCE(x,0)).
David Portas
SQL Server MVP
|||"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:jqnbb19pig8vfd8ev7pgtqj59gact2h2ou@.4ax.com...
> On Sun, 19 Jun 2005 10:48:23 -0400, Michael C# wrote:
>
> Hi Michael,
> The proper name is "average".
>
> I'd call this "average" or, if I really must be explicit, "average of
> only the values that are not missing" (but since eliminating NULLS
> before applying an aggregate is SOP in SQL, that's really just some
> extra unnecessary redundancy).
>
> I'd call this "average of the set after replacing missing values by the
> arbitrarily chosen value of zero". Of course, the function itself is
> still just called "average" - the rest actually described the COALESCE
> expression that is used as argument for the AVG().
> (Similarly, for AVG(A + B), I'd say "the average of the sum of A and B")
> Best, Hugo
> --
> (Remove _NO_ and _SPAM_ to get my e-mail address)
It's all redundancy; that's why I was wondering if there was a more
'concise' way to say it.
I guess "10 words or less" is out of the question.
|||Actually I was just wondering if there was a more concise way to say it.
Apparently "SQL AVG()" is about as concise as it gets; it seems there's no
concise term to describe how it arrives at an answer.
Thanks
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:hL2dna5IZ4cocyjfRVn-2w@.giganews.com...
> The AVG function is simply the Arithmetic Mean but with the additional
> rule that NULL values are ignored. If you prefer to be a bit more explicit
> about that calculation then maybe you could add x IS NOT NULL to your
> WHERE clause. If you want to include NULLs in the computation then you can
> substitute some alternative expression inside the AVG funcion. For
> example: AVG(COALESCE(x,0)).
> --
> David Portas
> SQL Server MVP
> --
>

Tuesday, March 20, 2012

Progress Versus SQL Server

Progress is a piece of crap! Sure it runs on Unix. But the time
invested in learning and working with it obscene! With SQL Server I
could easily plan a maintenance backup plan and transaction backup plan
- Progress - well you have to learn about AI files, sizing the BI and
AI files as well as the data files. It's a freakin nightmare. If I
want to see data in a table, can I simply click on a table and open it
- NO! Instead, I have to learn the 4GL language to write a script to
return records (what if I want to resort those records - write another
4GL script and run it again). But hey, why do you want to see the data
in the tables (at least that's what I was told by my company) Progress
GUI - what a joke. This database server might have been popular with
unix but the world today is GUI and Microsoft are the GUI experts.
Even with the GUI tools in Progress, I still can't click on a table,
open it and see the records. Maybe that's not important to others but
as a dba, it sure is a necessity. We're working with different
versions of Progress and none of them integrate with the other. I've
spent 2 months now trying to run some simple database maintenance on
Progress and all I can say is that I hate BI, AI, and D1, D2, D3 files.
Give me SQL Server any day where at least I can manage databases in a
normal logical way without having to deal with a stinkin .ST files and
prostrct this...prostrct that!!! Any Progress responses are welcome
but I'll take you on any day against SQL Server. If you're a
Pro-Progress and anti-SQL Server, you're behind the times - get with
the newest technology and GUI (not a GUI in development.) I have yet
to see a true relational database designed in Progress. Upsizing a
Progress database into a GUI environment - HA!I worked with Progress for several years running mission critical
applications and all I can say is that is an excellent technology as good as
SQL Server or Oracle.
Ben Nevarez, MCDBA, OCP
Database Administrator
"pkohn@.charter.net" wrote:

> Progress is a piece of crap! Sure it runs on Unix. But the time
> invested in learning and working with it obscene! With SQL Server I
> could easily plan a maintenance backup plan and transaction backup plan
> - Progress - well you have to learn about AI files, sizing the BI and
> AI files as well as the data files. It's a freakin nightmare. If I
> want to see data in a table, can I simply click on a table and open it
> - NO! Instead, I have to learn the 4GL language to write a script to
> return records (what if I want to resort those records - write another
> 4GL script and run it again). But hey, why do you want to see the data
> in the tables (at least that's what I was told by my company) Progress
> GUI - what a joke. This database server might have been popular with
> unix but the world today is GUI and Microsoft are the GUI experts.
> Even with the GUI tools in Progress, I still can't click on a table,
> open it and see the records. Maybe that's not important to others but
> as a dba, it sure is a necessity. We're working with different
> versions of Progress and none of them integrate with the other. I've
> spent 2 months now trying to run some simple database maintenance on
> Progress and all I can say is that I hate BI, AI, and D1, D2, D3 files.
> Give me SQL Server any day where at least I can manage databases in a
> normal logical way without having to deal with a stinkin .ST files and
> prostrct this...prostrct that!!! Any Progress responses are welcome
> but I'll take you on any day against SQL Server. If you're a
> Pro-Progress and anti-SQL Server, you're behind the times - get with
> the newest technology and GUI (not a GUI in development.) I have yet
> to see a true relational database designed in Progress. Upsizing a
> Progress database into a GUI environment - HA!
>|||pkohn@.charter.net wrote:
> Progress is a piece of crap! Sure it runs on Unix. But the time
> invested in learning and working with it obscene! With SQL Server I
> could easily plan a maintenance backup plan and transaction backup plan
> - Progress - well you have to learn about AI files, sizing the BI and
> AI files as well as the data files. It's a freakin nightmare. If I
> want to see data in a table, can I simply click on a table and open it
> - NO! Instead, I have to learn the 4GL language to write a script to
> return records (what if I want to resort those records - write another
> 4GL script and run it again). But hey, why do you want to see the data
> in the tables (at least that's what I was told by my company) Progress
> GUI - what a joke. This database server might have been popular with
> unix but the world today is GUI and Microsoft are the GUI experts.
> Even with the GUI tools in Progress, I still can't click on a table,
> open it and see the records. Maybe that's not important to others but
> as a dba, it sure is a necessity. We're working with different
> versions of Progress and none of them integrate with the other. I've
> spent 2 months now trying to run some simple database maintenance on
> Progress and all I can say is that I hate BI, AI, and D1, D2, D3 files.
> Give me SQL Server any day where at least I can manage databases in a
> normal logical way without having to deal with a stinkin .ST files and
> prostrct this...prostrct that!!! Any Progress responses are welcome
> but I'll take you on any day against SQL Server. If you're a
> Pro-Progress and anti-SQL Server, you're behind the times - get with
> the newest technology and GUI (not a GUI in development.) I have yet
> to see a true relational database designed in Progress. Upsizing a
> Progress database into a GUI environment - HA!
>
Tossing in my 2-cents... I'm not a Progress guy, never touched it. I
do however find it interesting that your entire argument seems to be
based on SQL offering a better GUI. I blame that GUI for some of the
basic, everyday questions that cross this newsgroup on a daily basis.
My database has been running for 2 years, and my transaction log is
250GB, why? How can I export a database to a different server? The GUI
that you seem to cherish allows any Access user to think he's a SQL
Server DBA, without forcing him/her to learn the most basic tasks.
Point-and-click through the maintenance plan wizard, without
understanding a thing about what it's actually doing, all is well until
that plan begins to fail. Since they never understood what it was
doing, they have no idea where to start troubleshooting. Oh, look,
there's a "New Database Wizard", I can create a database! What's my
backup strategy? Do I need transactional recovery capabilities, or are
daily full backups enough? Dunno, the wizard didn't ask me those questions.
Personally, the only time I touch Enterprise Manager is when I have to
work with some DTS package that somebody dragged objects onto,
connecting them with workflow lines, because that's the only way they
know how to execute a stored procedure.