From: Minu Nair on
1. Open the project in Visual Studio
2. Click on the project properties
3. Go to the Database tab and click on the browse button next to the connection string. You will get the Add Database Reference dialog.
4. Click on Add New Reference
5. In the New Database Reference dialog, enter the details for the database where you want to deploy the assembly and create the user defined aggregate.
6. Build the project
7. Now register the assembly and the aggregate in the SQL Server database you want





Michael C wrote:

User defined aggregate
27-Jan-09

Hi All,

I'm trying to do some CLR integration with sql server 2005. I've created my
own stored proc in c# and got that working but now I'm trying to create my
own user defined aggregate. I've download a sample and copy/pasted it into a
new project. I can compile and add it to sqlserver via management studio
with no problems. But when I execute the CREATE AGGREGATE statement I get
this error:

CREATE AGGREGATE failed because type 'Concatenate' does not conform to UDAGG
specification due to method 'Accumulate'.

Every search result I find refers to VB.Net and suggests removing the
ComClass attribute. However I am using C# which does not have the ComClass
attribute and this attribute is definately not on my class (or any other com
attribute). Is there any solution to this? I've tried all the obvious stuff
such as giving the assembly a strong name, putting ComVisible(false) on the
class and functions etc, ticking/unticking ComVisible at the project level.

Thanks in advance,
Michael

Here's the link to the sample:
http://msdn.microsoft.com/en-us/library/ms131056.aspx

Here's the C# code I'm using

using System;
using System.Data;
using Microsoft.SqlServer.Server;
using System.Data.SqlTypes;
using System.IO;
using System.Text;

[Serializable]
[SqlUserDefinedAggregate(
Format.UserDefined, //use clr serialization to serialize the
intermediate result
IsInvariantToNulls = true, //optimizer property
IsInvariantToDuplicates = false, //optimizer property
IsInvariantToOrder = false, //optimizer property
MaxByteSize = 8000) //maximum size in bytes of persisted value
]
public class Concatenate : IBinarySerialize
{
/// <summary>
/// The variable that holds the intermediate result of the concatenation
/// </summary>
private StringBuilder intermediateResult;

/// <summary>
/// Initialize the internal data structures
/// </summary>
public void Init()
{
this.intermediateResult = new StringBuilder();
}

/// <summary>
/// Accumulate the next value, not if the value is null
/// </summary>
/// <param name="value"></param>
public void Accumulate(SqlString value)
{
if (value.IsNull)
{
return;
}

this.intermediateResult.Append(value.Value).Append(',');
}

/// <summary>
/// Merge the partially computed aggregate with this aggregate.
/// </summary>
/// <param name="other"></param>
public void Merge(Concatenate other)
{
this.intermediateResult.Append(other.intermediateResult);
}

/// <summary>
/// Called at the end of aggregation, to return the results of the
aggregation.
/// </summary>
/// <returns></returns>
public SqlString Terminate()
{
string output = string.Empty;
//delete the trailing comma, if any
if (this.intermediateResult != null
&& this.intermediateResult.Length > 0)
{
output = this.intermediateResult.ToString(0,
this.intermediateResult.Length - 1);
}

return new SqlString(output);
}

public void Read(BinaryReader r)
{
intermediateResult = new StringBuilder(r.ReadString());
}

public void Write(BinaryWriter w)
{
w.Write(this.intermediateResult.ToString());
}
}

Previous Posts In This Thread:

On Tuesday, January 27, 2009 8:28 PM
Michael C wrote:

User defined aggregate
Hi All,

I'm trying to do some CLR integration with sql server 2005. I've created my
own stored proc in c# and got that working but now I'm trying to create my
own user defined aggregate. I've download a sample and copy/pasted it into a
new project. I can compile and add it to sqlserver via management studio
with no problems. But when I execute the CREATE AGGREGATE statement I get
this error:

CREATE AGGREGATE failed because type 'Concatenate' does not conform to UDAGG
specification due to method 'Accumulate'.

Every search result I find refers to VB.Net and suggests removing the
ComClass attribute. However I am using C# which does not have the ComClass
attribute and this attribute is definately not on my class (or any other com
attribute). Is there any solution to this? I've tried all the obvious stuff
such as giving the assembly a strong name, putting ComVisible(false) on the
class and functions etc, ticking/unticking ComVisible at the project level.

Thanks in advance,
Michael

Here's the link to the sample:
http://msdn.microsoft.com/en-us/library/ms131056.aspx

Here's the C# code I'm using

using System;
using System.Data;
using Microsoft.SqlServer.Server;
using System.Data.SqlTypes;
using System.IO;
using System.Text;

[Serializable]
[SqlUserDefinedAggregate(
Format.UserDefined, //use clr serialization to serialize the
intermediate result
IsInvariantToNulls = true, //optimizer property
IsInvariantToDuplicates = false, //optimizer property
IsInvariantToOrder = false, //optimizer property
MaxByteSize = 8000) //maximum size in bytes of persisted value
]
public class Concatenate : IBinarySerialize
{
/// <summary>
/// The variable that holds the intermediate result of the concatenation
/// </summary>
private StringBuilder intermediateResult;

/// <summary>
/// Initialize the internal data structures
/// </summary>
public void Init()
{
this.intermediateResult = new StringBuilder();
}

/// <summary>
/// Accumulate the next value, not if the value is null
/// </summary>
/// <param name="value"></param>
public void Accumulate(SqlString value)
{
if (value.IsNull)
{
return;
}

this.intermediateResult.Append(value.Value).Append(',');
}

/// <summary>
/// Merge the partially computed aggregate with this aggregate.
/// </summary>
/// <param name="other"></param>
public void Merge(Concatenate other)
{
this.intermediateResult.Append(other.intermediateResult);
}

/// <summary>
/// Called at the end of aggregation, to return the results of the
aggregation.
/// </summary>
/// <returns></returns>
public SqlString Terminate()
{
string output = string.Empty;
//delete the trailing comma, if any
if (this.intermediateResult != null
&& this.intermediateResult.Length > 0)
{
output = this.intermediateResult.ToString(0,
this.intermediateResult.Length - 1);
}

return new SqlString(output);
}

public void Read(BinaryReader r)
{
intermediateResult = new StringBuilder(r.ReadString());
}

public void Write(BinaryWriter w)
{
w.Write(this.intermediateResult.ToString());
}
}

On Wednesday, January 28, 2009 2:11 AM
Bob Beauchemin wrote:

Hi Michael,I compiled the sample code you provided, and it cataloged and ran
Hi Michael,

I compiled the sample code you provided, and it cataloged and ran correctly.
What DDL are using to catelog it? Here's the DDL I have (in fact in works
with Visual Studio autodeploy project.
CREATE AGGREGATE [Concatenate]
(
@value nvarchar(4000)
)
RETURNS nvarchar(4000)
EXTERNAL NAME [UDAggSample].[Concatenate]

Hope this helps,
Bob Beauchemin
SQLskills

"Michael C" <mikec(a)nospam.com> wrote in message
news:OLi$zeOgJHA.4864(a)TK2MSFTNGP04.phx.gbl...

On Wednesday, January 28, 2009 5:50 AM
Michael C wrote:

Re: User defined aggregate
"Bob Beauchemin" <no_bobb_spam(a)sqlskills.com> wrote in message
news:u4rcqeRgJHA.3456(a)TK2MSFTNGP03.phx.gbl...

Thanks for taking the time to try this. I'm at home at the moment so will
have to have a look at the sql I used tomorrow. Are these the steps you
used?

1) Create a default class library project in vs2008 using framework 2.0
2) Copy paste in the sample code
3) Compile it in release mode
4) Use enterprise manager to add the assembly
5) Use the above code to add the aggregate function.

There's also 3.5) Enable CLR integration which I assume you've done
previously.

Thanks again,
Michael

On Wednesday, January 28, 2009 10:56 PM
Michael C wrote:

Re: User defined aggregate
"--CELKO--" <jcelko212(a)earthlink.net> wrote in message
news:06b19bea-11e0-49ca-84ec-17f77dc12c5f(a)w24g2000prd.googlegroups.com...

When I saw that you'd replied jo I thought you might have something
constructive to say, silly me.


Just because a feature can be misused does not mean it should be avoided. I
have been on projects that used sqlserver with dot net, vb6, MS Access, C++
and asp. It was a nightmare but it was badly managed and used too many
languages with little reason for using them besided that what the developer
was familiar with. However in this case we're already using dot net so are
well and truly tied to MS.


I don't think there is anything wrong with wanting to do this sort of
aggregate. Why is it ok to do other sort of formatting in a database (eg
join First and LastName) but not ok to do something as trivial as comma
seperating a few strings? I wouldn't have to do it in dot net if sqlserver
wasn't so limited. It seems every second day I come up against something
trivial that it can't do or some absolutely crazy limitation that I thought
we left behind in the 90s. We still have no inheritance or oop and code
reuse is unusually limited because of performance issues with functions. It
sort of fits that you're so into sql server being the dinosaur you are. I
can understand MS needs to keep something like sqlserver as compatible as
possible with previous versions but it's about time they came out with a
proper oop database using linq as a replacement for sql.

Sorry for the rant people. :-)

Michael

On Wednesday, January 28, 2009 11:29 PM
Michael C wrote:

Re: User defined aggregate
I got it fixed, I was using varchar instead of nvarchar. The MS error was not
overly helpful indicating that the error was in the dll instead of the sql.
Thanks for your help. :-)

Michael

On Thursday, January 29, 2009 3:12 AM
--CELKO-- wrote:

I strongly recommend avoiding CLR.
I strongly recommend avoiding CLR. You are tying your system to
Microsoft only, so it will never port or scale. Performance is poor.
Maintaining multiple, often proprietary languages in the schema is a
nightmare. Ever work on procedural code that drops into assembly
language? then into C and then calls a FORTRAN library? It sucks.

More often than not, the CLR is code that should be done in the front
end and not in the database at all. In this particular case, it looks
like you are formatting for display and not producing a scalar value
at all.

On Thursday, January 29, 2009 5:51 PM
Michael C wrote:

Re: User defined aggregate
"--CELKO--" <jcelko212(a)earthlink.net> wrote in message
news:1ef21216-429e-4436-a551-0bd6a643b4d0(a)p20g2000yqi.googlegroups.com...

That's odd jo, I wasn't expecting you to reply. Usually when given a hard
time you show your usual spinelessness and run off wimpering.


You gave out bad advice and don't know it. Nothing unusual there, you quite
often (not always but most of the time) hand out bad advice. The whole
industry has moved away from natural keys 10 years ago but you're still
beating that drum as load as ever.


So what? Just because someone at some time in history said the same thing as
me does not mean the statement is invalid in all situations. I repeat again,
just because a feature can be misused does not mean it should always be
avoided. Any feature can be misused, should we abandon all features because
someone at some time in history misused it? Just because someone said this
about goto means nothing jo.

situation. Now, think about it. Which will change most often,
applications or the data base? Clearly, the applications. If I replace
an application program with a new one, does it affect other
applications? Not if you followed good Software Engineering prinicples
and have low module coupling.

Actually I was reinforcing my point, you are just too stupid to understand
it. I have been on projects that have way over abused mutliple languages but
I've also been on projects that have used multiple languages to good effect.
I think any business database project should use 3 languages, a high level
language, a low level language and some form of sql. This is good
management. Again, just because this can be abused does not mean it should
be avoided altogether. It would be a poor decision to avoid C++ to plug the
gaps that a high level language leaves open.

with VB6, MS Access, C++, etc. inside the schema, every application is
screwed up.

Wrong. If you design the database as you should then there is no need for it
to get screwed up for each language. The database should be designed to
mirror the situation you need to replicate, not the programming language you
are using.

**all** of the CLR languages: Booleans are not part of SQL, but what
does TRUE look like (-1 or +1 or any integer with a 1 bit?), how the
MOD() function works with negative numbers, the direction of rounding,
the use of unary signs in expressions, string comparison rules, etc.
Not tricky, fancy language features, just basic math, logic and string
stuff.
You might not, but Dr. Codd and all the Relational people do :) Do
you remember First Normal Form (1NF)? Closure in set operations?
etc?

If I'm designing a table or a highly reusable stored proc or view then I'm
all for relational and following all the rules. If I'm designing 1 single
stored proc that will always be married to 1 report then I'm quite happy to
do what is required. The right tool for the right job jo. If I can join
FirstName and LastName columns for a report then what is wrong with comma
seperating a few strings? Does sql server reports even have a feature to do
this? As far as I know it doesn't so your only choice is to do it in the
database. Again, if sqlserver wasn't so limited I wouldn't need to do these
things.

period. This is like bitching that it is really hard to drive nails
with a saw. After 30+ years with databases, I am quite happy with
having a good tool for that job instead of a "Swiss Aarmy Knife" that
does a dozen unrelated things, all poorly.

I can understand your point but unfortunately sqlserver is limited is
stupid, not sensible ways. Why can't I define my own aggregates using sql?


OOP database is another topic which we should probably leave for another
time. It's funny to see your negativity towards the idea, I think most of
the world are just waiting for a good one to come out.

Michael

On Friday, January 30, 2009 5:48 PM
Michael C wrote:

Re: User defined aggregate
"--CELKO--" <jcelko212(a)earthlink.net> wrote in message
news:0fd111bb-4503-4c42-b307-2e4d3076f5a0(a)g38g2000yqd.googlegroups.com...
screaming "I can't hear you!!" or "Who the hell is Dr. Codd and why is
he important??!! You actually posted content and that is worth a
detailed reply (probably ought to be in .theory newsgroup, but I will
take a good discussion where I can find it)

Good discussions don't have children like you in them.

Globalization. Being a "T-SQL on one server" shop dependent on
IDENTITY columns for keys is a plan for commercial death.

That's odd, there's a lot of commercial sucesses using identity columns and
a lot of failures using natural keys.

condemned to repeat it." --George Santayana. There is also a quote
from Dijkstra about how IT re-invents the old, failed methods in each
new technology.

Um, no, it is you who don't get it. I'm not sure how many times I can say
this, but just because a feature can be misused does not mean we should
avoid it. It's like talking to a brick wall. We'd better abandon pointers,
and inheritance and interfaces, in fact we'd better abandon databases and
all sql because I've seen them all well and truly abused.


Yes, of course but using an extensive, widely used library to enhance the
limited features of sql server is not necessarily one of them. I can
understand in some situations it might be but in some situations it might
not be. You have no idea of my situation and the battles I'm having with sql
server to get it to do something it should be able to do out of the box.

is higher than the top 1% on a Cattell scale -- look it up; even i was
impressed). I have written a few books. I have multiple Masters
degrees. Stupid is not my problem. I also have 35+ years in IT. I have
might other faults (my wife has a list), of course.

Everyone has abilities in certain areas yet can be stupid in others. For
example, I don't think there is any doubt you're stupid with regards to
people skills. Some of the advice you give out here shows a high degree of
stupidity. 99% of the time you lack the ability to even think through the
situation the poster is in and the possible reasons they might want to make
the choices they are making. You're too stupid to think why I might want to
use the CLR. Ok jo, let's see how smart you really are, tell me the decision
process I went through before deciding to use it. Hint, there were several
*good* reasons and it wasn't just a case of f*** it, let's use clr.

when the languages were mixed instead of tiered and clearly
separated.

Wow jo, you are my hero.

need bits. SQL for the data; a single application language for the
routine work; an analysis language for high level decisions (stats,
DW, etc).

Again, that is your opinion. I think a low level language makes a good
compliment for any high level language. For example one business app I did
required taking photographs of people for their database. The direct show
stuff was done in C which was a lot easier than doing it in C#. In other
cases I've used C++ to write extended stored procs to enhance sqlservers
many limitations.

reflex REPEAT : the pro writes good code as a reflex. "There ain't
nothing more permanent than a temporary patch!" -- programmer
proverb.

I've been programming for close to 30 years now, in general I think the
decisions I make are quite good. I make the odd mistake of course but I've
never worked with a programmer who was as strict as me as with regards to
database structure, integrity etc. You might actually appreciate some of my
ability if you switched out of your head in the sand "I'm smart and everyone
else is inferior" thinking.

(do you know what a JOIN is? Apparently not!) A **concatenation** done
for display is done in the front end, not the DB.

This is the very reason I have so much disrespect for you jo. You know
perfectly well that I didn't mean the sql keyword join, you knew perfectly
well what I did mean, yet you had to go off attempting to make me look
stupid and you smart in an attempt to pad your fragile ego. The keyword used
in dot net to concatenate an array of strings is Join. Oddly enough the word
in english to put 2 things together is, you guessed it jo, JOIN!!! I don't
concatenate my trailer onto my car.

BTW, you didn't answer the question, a sure sign it's a good point.

stuff in the front end. You do not seem to know that display and
storrage are totally different levels of data abstraction.

A good programmer knows not everything is black and white. In some case you
need to do presentation stuff in the DB and not in the GUI (not that we've
established this should be done in the GUI). Sometimes it's just simpler to
do it in the DB. A good programmer knows when to use this and when not to.
For example, I would never ever do this in a table and never do it for a
highly reused stored proc etc, but for a report that has one stored proc and
that stored proc is always tied to to the report my experience tells me it's
ok to relax things a bit.

And yet again, you didn't answer the question. If my presentation layer is
sqlserver reports and sql server reports does not have a feature to join
strings then where else am I going to do it?

products that integrate data and applications. Or go back to COBOL
file systems.

No thanks, I'm reasonably happy using sqlserver (although I am a little
frustrated with it). I just want a little extra functionality that would be
dead simple in something like c#.

Multi-core parallel hardware is going to run with F#, Erlang,
Haskell; and other "Hip, Kool New!" functional languages in the next
decade. Functional programming is declarative -- just SQL!!

Sure thing jo.

Michael

On Friday, January 30, 2009 5:50 PM
Michael C wrote:

Re: User defined aggregate
"Alex Kuznetsov" <alkuzo(a)gmail.com> wrote in message
news:c74ac565-f060-4e77-92da-

I don't see why it has to be limited myself. Certainly the designers of
sqlserver think it's more than a database given that it can send emails etc.
I think if it more as a black box that exists on the server that can do
stuff.

On Sunday, February 01, 2009 1:30 AM
--CELKO-- wrote:

tructive to say, silly me. <<You got good advice but don't know it.. <<LOL!
tructive to say, silly me. <<

You got good advice but don't know it.

.. <<

LOL! You lack the expereience of going thru the "GOTO Wars" that lead
to modern programming. This was exactly the same defense made by the
GOTO programmers against Structured Programming and Analysis.

s, C++ and asp. It was a nightmare but it was badly managed and used too ma=
ny languages with little reason for using them besided that what the develo=
per was familiar with. However in this case we're already using dot net so =
are well and truly tied to MS. <<

Thank you for making my point. It was bad management to allow this
situation. Now, think about it. Which will change most often,
applications or the data base? Clearly, the applications. If I replace
an application program with a new one, does it affect other
applications? Not if you followed good Software Engineering prinicples
and have low module coupling.

Now, look at the database. If you screwed up the DDL by having to deal
with VB6, MS Access, C++, etc. inside the schema, every application is
screwed up. I like to ask people how teh most basic funcitons work
**all** of the CLR languages: Booleans are not part of SQL, but what
does TRUE look like (-1 or +1 or any integer with a 1 bit?), how the
MOD() function works with negative numbers, the direction of rounding,
the use of unary signs in expressions, string comparison rules, etc.
Not tricky, fancy language features, just basic math, logic and string
stuff.

gregate. Why is it ok to do other sort of formatting in a database (eg join=
First and LastName) but not ok to do something as trivial as comma seperat=
ing a few strings? <<

You might not, but Dr. Codd and all the Relational people do :) Do
you remember First Normal Form (1NF)? Closure in set operations?
etc?

seems every second day I come up against something trivial that it can't do=
or some absolutely crazy limitation that I thought we left behind in the 9=
0s. <<

SQL is supposed to be limited. It is a data retrieval language,
period. This is like bitching that it is really hard to drive nails
with a saw. After 30+ years with databases, I am quite happy with
having a good tool for that job instead of a "Swiss Aarmy Knife" that
does a dozen unrelated things, all poorly.

because of performance issues with functions. <<

Can you see how you have a proceudral mindset? This is a declarative
language and we neither need nor want inheritance or OOP; we have
really good code reuse if you know how to write VIEWs, however. Again
this is a set-oriented data retrieval language and not an applicaiton
development language.

e. I can understand MS needs to keep something like SQL Server as compatibl=
e as possible with previous versions but it's about time they came out with=
a proper OOP database using linq as a replacement for SQL. <<

Have you ever worked with an OO database? You might want to research
the history of those products; they failed in the market. Their best
market was in telecom, where they were used to simulate phone
networks. But it was awful for commerical, data warehouses, etc.

Many years ago, the INCITS H2 Database Standards Committee(nee ANSI
X3H2 Database Standards Committee) had a meeting in Rapid City, South
Dakota. We had Mount Rushmore and Bjarne Stroustrup as special
attractions. Mr. Stroustrup did his slide show (on overhead projector
slides!) about Bell Labs inventing C++ and OO programming for us and
we got to ask questions.

One of the questions was how we should put OO stuff into SQL. His
answer was that Bells Labs, with all their talent, had tried four
different approaches to this problem and come the conclusion that you
should not do it. OO was great for programming but deadly for data.
I assume you know what Bells Labes was like in those days; yeah, that
kind of Smarts.

I have watched people try to force OO models into SQL and it falls
apart in about a year. Every typo becomes a new attribute or class,
queries that would have been so easy in a relational model are now
multi-table monster outer joins, redundancy grows at an exponential
rates, constraints are virtually impossible to write so you can kiss
data integrity goodbye, etc.

On Sunday, February 01, 2009 1:30 AM
--CELKO-- wrote:

rd time you show your usual spinelessness and run off wimpering.
rd time you show your usual spinelessness and run off wimpering. <<

Most of the time I get a spoiled kid sticking his fingers in his ears
screaming "I can't hear you!!" or "Who the hell is Dr. Codd and why is
he important??!! You actually posted content and that is worth a
detailed reply (probably ought to be in .theory newsgroup, but I will
take a good discussion where I can find it)

're still beating that drum as load as ever. <<

Sorry, but I am sure that I consult with more international and
national companies than you do (have you had to get a second passport
become all the back pages were full? How many Fortune 100 companies
hired you in the last 10 years? etc?). When were you invited as a
speaker to a conference to tell DB people that industry has moved away
from natural keys?

Sorry, there is a strong trend toward industry standards for
Globalization. Being a "T-SQL on one server" shop dependent on
IDENTITY columns for keys is a plan for commercial death.

some time in history said the same thing asme does not mean the statement i=
s invalid in all situations. <<

LOL! You really don't get it! "Those who cannot remember the past are
condemned to repeat it." --George Santayana. There is also a quote
from Dijkstra about how IT re-invents the old, failed methods in each
new technology.

hould always be avoided. Any feature can be misused, should we abandon all =
features because someone at some time in history misused it? Just because s=
omeone said this about GOTO means nothing Joe. <<

Did you ever consider that some ideas are just plain bad? Mercury will
cure acne by raising the white blood cell count thru the roof, but I
would rather use Oxy-clear. After 30+ years of experiences and
statistics, we found that low coupling and high cohesion makes for
better, maintainable code. Monolithic systems with the data tightly
coupled to the application code may run faster at first, but the real
cost (80%+ total lifetime cost by DoD and every bit of University
research; I did this full time for the US Army for years NEVER saw
less) of a system of its lifetime is in maintaining it

nd it. <<

I was the president of the Mensa chapter in Atlanta many years ago (IQ
is higher than the top 1% on a Cattell scale -- look it up; even i was
impressed). I have written a few books. I have multiple Masters
degrees. Stupid is not my problem. I also have 35+ years in IT. I have
might other faults (my wife has a list), of course.

I've also been on projects that have used multiple languages to good effec=
t. +<<

I have been paid 4-digits a day to clean those things. The problem is
when the languages were mixed instead of tiered and clearly
separated.

el language, a low level language and some form of SQL. <<

I would not put in a low-level language at all; business apps do not
need bits. SQL for the data; a single application language for the
routine work; an analysis language for high level decisions (stats,
DW, etc).

r it to get screwed up for each language. The database should be designed t=
o mirror the situation you need to replicate, not the programming language =
you are using. <<

I agree with the idea of an abstract data model; I get pucnched out by
Newbies for insisting on it. But after moving a model to 20+ different
application languages, you learn to look and to keep things as simple
as possible. Can you read COBOL, the absolutely most important
business language on Earth? All of the commercial rounding rules that
are built into it ? etc?

hen I'm all for relational and following all the rules. If I'm designing a =
single stored procedure that will always be married to a report then I'm qu=
ite happy to do what is required. <<

The amateur versus the professional! The pro writes good code as a
reflex REPEAT : the pro writes good code as a reflex. "There ain't
nothing more permanent than a temporary patch!" -- programmer
proverb.

_name columns for a report then what is wrong with comma seperating a few s=
trings? <<

You do not **join** first_name and last_name columns on the same row
(do you know what a JOIN is? Apparently not!) A **concatenation** done
for display is done in the front end, not the DB.

it doesn't so your only choice is to do it in the database. <<

Again, SQL is not an applications development language. You to do this
stuff in the front end. You do not seem to know that display and
storrage are totally different levels of data abstraction.

s. <<

Then use Progress, INFORMIX and other proprietary app development
products that integrate data and applications. Or go back to COBOL
file systems.


You can do it for some of them, if you can write SQL. Google my
postings on the PRD() function. But SQL has not inherit FP rounding
correction (neither do VB, C#, CF++, etc), so the fancy stuff is best
for SAS, MathLab, SPSS, etc --, the right tool for the job.


time. It's funny to see your negativity towards the idea, I think most of =
the world are just waiting for a good one to come out. <<

My negativity came from a decade on ANSI X3H2 and the guys at Bell
Labs followed by CA and other products. You like it because it is all
you know. I helped write failed standards for OO-DB.

The bad news for you kids is that OO is about to go down the drain.
Multi-core parallel hardware is going to run with F#, Erlang,
Haskell; and other "Hip, Kool New!" functional languages in the next
decade. Functional programming is declarative -- just SQL!!

On Sunday, February 01, 2009 1:30 AM
Alex Kuznetsov wrote:

Re: User defined aggregate
On Jan 29, 1:13=A0pm, --CELKO-- <jcelko...(a)earthlink.net> wrote:
nstructive to say, silly me. <<
aggregate. Why is it ok to do other sort of formatting in a database (eg jo=
in First and LastName) but not ok to do something as trivial as comma seper=
ating a few strings? <<

If you retrieve after joining parent and child table, your result set
violates 2NF, So what?

t seems every second day I come up against something trivial that it can't =
do or some absolutely crazy limitation that I thought we left behind in the=
90s. <<

Really? I thought INSERT UPDATE DELTE are also in ANSI SQL .

EggHeadCafe - Software Developer Portal of Choice
..NET Constructor Applied
http://www.eggheadcafe.com/tutorials/aspnet/be09e92f-5773-4cbf-92bd-2efad5224a3f/net-constructor-applied.aspx