Does SQL Server 2005 Support the List Statement?

We have a comprehensive windows based application which uses a database othe
r
than SQL Server. We have been considering moving our application to SQL
server but have been stymied by limitations in the ANS SQL implementation as
well has hidden restrictions in Decalarative Referential integrity.
One statement we use a lot in reporting is the ANS List statment (a scalar
aggregate function for strings which can return a set of results in a
appropriate delimited string).
Does anyone know if the List statement is implemented fully in SQL Server
2005.
If not, we would be interested in what techniques others use to get around
this limitation.
Thanks> One statement we use a lot in reporting is the ANS List statment (a scalar
> aggregate function for strings which can return a set of results in a
> appropriate delimited string).
> Does anyone know if the List statement is implemented fully in SQL Server
> 2005.
NO, it is not.

> If not, we would be interested in what techniques others use to get around
> this limitation.
http://www.aspfaq.com/2529|||"Glenn" wrote:

> We have a comprehensive windows based application which uses a database ot
her
> than SQL Server. We have been considering moving our application to SQL
> server but have been stymied by limitations in the ANS SQL implementation
as
> well has hidden restrictions in Decalarative Referential integrity.
> One statement we use a lot in reporting is the ANS List statment (a scalar
> aggregate function for strings which can return a set of results in a
> appropriate delimited string).
> Does anyone know if the List statement is implemented fully in SQL Server
> 2005.
> If not, we would be interested in what techniques others use to get around
> this limitation.
> Thanks
When you say "ANS SQL" do you mean ANSI SQL? If so, I think you are
mistaken. The LIST "aggregate" has never been part of standard SQL. It is a
proprietary feature in DB2 I believe (and possibly others).
There are a number of logical and practical problems with the concept of a
"string concatenation aggregate". The problems are to do with the fact that
concatentation implies order, which implies sorting. Furthermore, determinis
m
requires unique sorting. This means that "LIST" is A) potentially expensive
on performance B) difficult to ensure reliable results in queries C) totally
contrary to the way other SQL queries and aggregates work.
The ANSI response to "ordered" functions is the Windowed functions and these
*are* supported by SQL Server 2005. Theoretically you can kludge your own
string aggregate using standard SQL, provided you can set some reasdonable
upper limit to the number of items to be concatenated. Allternatively there
are non-standard workarounds in TSQL as there apparently are in your current
database.
Rather than try to support such a potential kludge in the database I suggest
you look at doing this client-side. In ADO you have the GetString method to
serve that purpose.
David Portas
SQL Server MVP
--|||Thanks very much for your response. This is a bit disappointing. We had so
hoped they would address this item as it is so commonly used in other SQL
implementations.
I took a look at the faq sample - and though helpful - and it looks like it
might add quite a lot of complexity to the SQL in many of our queries. I
think it is unfortunate that Microsoft continues to add many new features to
its SQL implementation, yet seems to have long ignored the ANS standard SQL.
It makes it difficult for developers and ISV's to move their applications
from other vendors to the M/S platform.
Glenn
"Aaron Bertrand [SQL Server MVP]" wrote:

> NO, it is not.
>
> http://www.aspfaq.com/2529
>
>|||> yet seems to have long ignored the ANS standard SQL.
Why do you think LIST is ANSI standard?
A|||Hi, this is pretty helpful, although it was my understanding that the SELECT
LIST command was ANSI standard although there were various vendor extensions
to the feature added for control of concatenation, separators, and order.
We are a bit spoiled by the iAnywhere implementation which works very
efficiently for our application and allows for ordering of the result (an
obvious Vendor extention). We have also tried doing this on the client side
,
and it was much-much slower.
Thanks for your help, looks like we are going to need to engage a SQL port
specialist.
BTW - We utilize quite a few Scalar Subqueries in our application, do you
feel that using these on SQL Server 2005 will introduce any special
performance or implementation problems.
Glenn
"David Portas" wrote:

> "Glenn" wrote:
>
> When you say "ANS SQL" do you mean ANSI SQL? If so, I think you are
> mistaken. The LIST "aggregate" has never been part of standard SQL. It is
a
> proprietary feature in DB2 I believe (and possibly others).
> There are a number of logical and practical problems with the concept of a
> "string concatenation aggregate". The problems are to do with the fact tha
t
> concatentation implies order, which implies sorting. Furthermore, determin
ism
> requires unique sorting. This means that "LIST" is A) potentially expensiv
e
> on performance B) difficult to ensure reliable results in queries C) total
ly
> contrary to the way other SQL queries and aggregates work.
> The ANSI response to "ordered" functions is the Windowed functions and the
se
> *are* supported by SQL Server 2005. Theoretically you can kludge your own
> string aggregate using standard SQL, provided you can set some reasdonable
> upper limit to the number of items to be concatenated. Allternatively ther
e
> are non-standard workarounds in TSQL as there apparently are in your curre
nt
> database.
> Rather than try to support such a potential kludge in the database I sugge
st
> you look at doing this client-side. In ADO you have the GetString method t
o
> serve that purpose.
> --
> David Portas
> SQL Server MVP
> --
>|||In our database documentation it was descibed as ANS 92/99 with optional
vendor extensions.
--
Glenn
"Aaron Bertrand [SQL Server MVP]" wrote:

> Why do you think LIST is ANSI standard?
> A
>
>|||LIST isn't ANSI Standard and never has been - I just checked the
standards docs. The reason is probably related to some of the logical
problems I mentioned. It just doesn't make sense as an "aggregate"
function.
I think SQL Server is actually reasonably good on standard SQL
compliance, and it goes further with 2005 - the SQL1999 OLAP functions
for example -although it certainly could do better.
David Portas
SQL Server MVP
--|||I do not wish to offend anyone, but this is - after all - the 21st century:
consider using XML (e.g. in SQL 2005) to replace the less useful LIST
function, if you really need to move sets of data about on the server.
ML|||Can you give me link to the ANSI SQL specification documents?
Thanks
--
Glenn
"David Portas" wrote:

> LIST isn't ANSI Standard and never has been - I just checked the
> standards docs. The reason is probably related to some of the logical
> problems I mentioned. It just doesn't make sense as an "aggregate"
> function.
> I think SQL Server is actually reasonably good on standard SQL
> compliance, and it goes further with 2005 - the SQL1999 OLAP functions
> for example -although it certainly could do better.
> --
> David Portas
> SQL Server MVP
> --
>