Prev: Quicked way to create a copy of a table with all default value
Next: generate summary row question
From: Peso on 13 Nov 2009 17:11
You don't need a CLR for this

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=81254

//Peso


"Minu Nair Khurana" wrote in message
news:2009111355850khurana.minu(a)gmail.com...
> 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

 | 
Pages: 1
Prev: Quicked way to create a copy of a table with all default value
Next: generate summary row question