SQLServerCentral / Editorials / SQLServerCentral.com / The Full Potential of SQL 2000 / Latest Posts

RE: The Full Potential of SQL 2000

Steve Jones - SSC Editor — Thu, 18 Dec 2008 09:20:58 GMT

I do agree with Jeff that you need to write good code, but you also want to not get too caught up in it. There's a point when you're wasting time, expensive developer time fixing things that could be handled with a little more hardware.It's hard to judge when that is, but it's definitely there. The problem is most people give up too soon on writing good code, or they don't know how, and then they run out of hardware before the load is handled.

RE: The Full Potential of SQL 2000

Phil Factor — Thu, 18 Dec 2008 01:01:53 GMT

I have continual grief from developers over the makeup of the Development Database Server. The development server should be a slow stolid reliable old workhorse. Developers always want the very latest hardware and software. I'm for the oldest version one can get away with. That's usually 2005 nowadays since everyone needs Varchar(MAX). (although large systems are still being developed in SQL Server 2000!). I like to get old production servers when they are slung out. Big Compaqs with banks of lovely rustling SCSIs. They're perfect for developmentThen you go into test and production with the latest stable version of everything.If you develop on a slooooowwwww computer, with looooaaaads of data then you get to see the painful performance areas. and both test and production are a glorious and pleasant surprise. It sounds unkind to developers to make them see the hourglass as a penance for their coding sins, but sure as hell it speeds up development.

RE: The Full Potential of SQL 2000

Jeff Moden — Wed, 17 Dec 2008 23:54:20 GMT

[quote][b]sausage.dog (12/17/2008)[/b][hr]People scoff at the idea of buying bigger hardware but as you point out it's cheap. Oftentimes it's far cheaper than paying a team to optimise (read: rewrite) large chunks of an application.[/quote]That's why I believe in writing the code with performance in mind the first time... people make the mistake of thinking faster hardware is going to make the code faster. It frequently doesn't or, if it does, it's only for a short time until the scale of the requirements catches back up to the IO bottleneck or the memory limitation. I've see it happen over and over. There's also the hidden cost of migrating the data, etc, over to the new server. Doesn't matter how good the machine is, something like a triangular join on large data sets is going to eat it for lunch.

RE: The Full Potential of SQL 2000

RBarryYoung — Wed, 17 Dec 2008 15:44:50 GMT

[quote][b]rog pike (12/17/2008)[/b][hr]The great silicon dividend has been wasted. How can anyone gloat over all the bloat:)[/quote]Actually, that is not what this paper says. In fact it give a very balanced presentation of that very issue and includes a strong case that Moore's dividend has been spent on the benefits of better "programming languages, models, architectures, and development practices, up through the user-visible behavior and functionality of software".Edit: removed Steve Jones name, accidentally included in the quote.

RE: The Full Potential of SQL 2000

sausage.dog — Wed, 17 Dec 2008 15:22:39 GMT

[quote][b]Jeff Moden (12/17/2008)[/b][hr][quote][b]rog pike (12/17/2008)[/b][hr]The great silicon dividend has been wasted. How can anyone gloat over all the bloat[/quote]Heh... man, do I agree with that! How many times have we heard "upgrade the hardware" as the fix for slow code? The only good part about the bloat is that incredibly large and fast harddisks and gobs of memory have become relatively inexpensive.[/quote]People scoff at the idea of buying bigger hardware but as you point out it's cheap. Oftentimes it's far cheaper than paying a team to optimise (read: rewrite) large chunks of an application. And as cloud computing becomes more prevalent with on-demand resources, low level optimisation makes even less sense. Naturally the system must run cost-effectively, but business will always balk at paying extra to reduce wait time for staff. Anything that actually requires someone to wait for more than 5 minutes is likely to be batch anyhow so the slow performance can often cost very little in real world terms.Highly interactive systems need to be reponsive. That's a no brainer. But it's also something you're likely to catch in development if not UAT. If you have a serious userbase load testing should always be on the agenda.

RE: The Full Potential of SQL 2000

Lynn Pettis — Wed, 17 Dec 2008 09:34:30 GMT

Well, it is still alive and kicking. My co-worker was taking a C class in college, wrote his programs using Power Basic first and got it working, then ported the code to C.

RE: The Full Potential of SQL 2000

Jeff Moden — Wed, 17 Dec 2008 09:24:34 GMT

[quote][b]Lynn Pettis (12/17/2008)[/b][hr]Co-worker at my previous employer really like Power Basic. Creates extremely fast and tight code. They recently added a /bloat switch that makes the executable bigger, but still runs as fast.[/quote]Man, I LOVED Power Basic... I actually started using it way back when it was called "Turbo Basic". Bob Zale and his crew did a really nice job.

RE: The Full Potential of SQL 2000

Lynn Pettis — Wed, 17 Dec 2008 08:50:47 GMT

Co-worker at my previous employer really like Power Basic. Creates extremely fast and tight code. They recently added a /bloat switch that makes the executable bigger, but still runs as fast.

RE: The Full Potential of SQL 2000

Jeff Moden — Wed, 17 Dec 2008 08:41:16 GMT

[quote][b]rog pike (12/17/2008)[/b][hr]The great silicon dividend has been wasted. How can anyone gloat over all the bloat[/quote]Heh... man, do I agree with that! How many times have we heard "upgrade the hardware" as the fix for slow code? The only good part about the bloat is that incredibly large and fast harddisks and gobs of memory have become relatively inexpensive.

RE: The Full Potential of SQL 2000

steve dassin — Wed, 17 Dec 2008 02:33:27 GMT

[quote][b]Steve Jones - Editor (12/16/2008)[/b][hr]Derek,Interesting and a nice argument.However I'd argue that we need lots of checks in there. It can be the tools adding them, but we are more interconnected, there are more people looking for issues and vulnerabilities in applications in ways that didn't occur when we wrote in assembler.If code is slower, we need more horsepower, and more optimized tools that can make safe, secure applications run well.[/quote]Here's an interesting paper out of MS Research that puts the last 30 years of software development into perspective:Spending Moore’s Dividendby James Larus 5/2/2008[url=ftp://ftp.research.microsoft.com/pub/tr/TR-2008-69.pdf][b]ftp://ftp.research.microsoft.com/pub/tr/TR-2008-69.pdf[/b][/url]The opening quotation says it all, "Grove giveth and Gates taketh away." The great silicon dividend has been wasted. How can anyone gloat over all the bloat:) As for sql does anyone know where the inside of sql server ends and the outside begins? But the author contends we have a second chance to do it right:) In any event James didn't make many friends at MS with this paper:)[url=http://www.beyondsql.blogspot.com][b]www.beyondsql.blogspot.com[/b][/url]

RE: The Full Potential of SQL 2000

Derek Dongray — Wed, 17 Dec 2008 02:23:37 GMT

Hi SteveI agree that in a 'proper' application, you'd need various checks and error handling. And when the developer, after using all the optimizing tools, really can't get any more speed or reduce the size or whatever, then the only option is to upgrade the hardware.However, optimizing tools are just pieces of software, so they also suffer from the 'it works' syndrome, hence may be programmed to always include the checks because it's too hard to do further analysis and see if they are actually needed. In any event, the tool often can't do a proper cost-benefit anaylsis to determine how much resource to spend optimizing, because it won't have a usage profile.The bottom line is that the developer needs to have an idea how what they are writing will be used and should then focus on those areas where an improvement will pay off and not just assume that the tool will always produce the [i]best[/i] code.

RE: The Full Potential of SQL 2000

Steve Jones - SSC Editor — Tue, 16 Dec 2008 22:55:34 GMT

Derek,Interesting and a nice argument.However I'd argue that we need lots of checks in there. It can be the tools adding them, but we are more interconnected, there are more people looking for issues and vulnerabilities in applications in ways that didn't occur when we wrote in assembler.If code is slower, we need more horsepower, and more optimized tools that can make safe, secure applications run well.

RE: The Full Potential of SQL 2000

Jeff Moden — Tue, 16 Dec 2008 19:26:47 GMT

Heh... Well said, Derek... I forget which year Bill Gates said it would happen, but he once said something to the effect that sometime in the very near future, there will be no true programmers... just users.

RE: The Full Potential of SQL 2000

Derek Dongray — Tue, 16 Dec 2008 03:29:05 GMT

[quote][b]sausage.dog (12/15/2008)[/b][hr][quote][b]Derek Dongray (12/15/2008)[/b][hr]This sounded like FUD so I thought I'd try it out. C# console app, 5k executable. And with code that's orders of magnitude easier to maintain. There's nothing even remotely simpler or faster about what you wrote. I built the example in under a minute and had output of a real world, distributable application. All you have is DOS script. What's the point you're trying to make here? 27 bytes of source that's good for nothing?Most people posting here sound completely detatched from reality and are completely ignoring the benefits modern tools give the developer. ASP.Net let's you build a scalable, thread-safe web app in a day. You can go back to C and write procedurally, or to C++ and have to manually manage memory again, but there's a reason people don't and why you'll never get a business case off the ground to do so. Hey, chuck out web services and go back to writing proprietary APIs coded directly to the TCP/IP stack while you're at it. [i]That'll[/i] make your app faster to write and resuable for partners, I'm sure.The reason apps take longer to write nowadays is they're bigger, talk to more systems, manage more data, and have more bureaucracy as a result. Crappier tools won't change any of that. If you don't want to design an enterprise data model to aggregate your systems you don't have to. If you don't want to go to the effort of building using SOA principles you can still do one off "enhancements" on two systems to move data with flat files. But you get what you pay for and there's a reason these are considered bad practices in the real world.[/quote]OK. I been developing software for about 30 years, so have this vague idea that I understand it. The list of languages I've worked with include assembly code for many platforms (IBM 360, DEC PDP-7, -8, -10, -11 & -15, Intel x86 series...)as well as assorted high-level compiled and scripted languages such as PL/1, Fortran, Basic (many flavours), Pascal, C, C++, VB, Perl, PHP, SQL, etc. Applications I've worked on range from simple single-use apps to large applications used by thousands of users. I also worked on compilers, which is why I am certain that applications have got slower.My example was written using the DOS debug command because I no longer have an assempler installed. The point was to show that current compilers are terribly inefficient and that the user interface actually prevents the developer from writing efficient code. I would say it's impossible to tell whether a 27byte program is faster than a 5k one because the execution time of either would be milliseconds and most of this would be in overhead external to the actual code.I agree that writing a "Hello, World!" program (or any program) in assembler these days is probably overkill (as well as the fact that the program is pointless). But my point is that the tools do not give enough control to reach the optimal solution. I [b]know[/b] that to do the job I want done (output "Hello, World!") the minimum needed is 27 bytes, but, as you pointed out yourself, there's no way to get close because the tools insist on including checks which may or may not be needed. "Hello, World!" only uses constants, so there is no need for memory management, but you can bet that all the check routines for stack overflow and so forth are getting dragged in even if there is no chance of them being triggered.I also agree that, for maintainability and speed of development, it's much better to work in as abstract a language as possible and let the tools take care of the details. But the problem is that the overheads resulting from this abstraction invariably results in slower code and, very often, you can't provide the necessary hints to reduce the overhead or, if you can, people don't bother.In SQL terms, this means that although SQL is [i]supposed to be[/i] declarative (tell the server what you need not how to get it), since the tool (in this this case the optimiser) is just another application with limitations, the developer very often ought to be guiding it how to get the best result.But the trouble is that a lot of modern developers tend not to do this (they just argue that you need a faster server) so applications run slower than they need to.Apologies for the length of this, but it is something I feel strongly about. I beleive developers should not just write code that works and let the tool optimise it, but should think about all the steps (even in SQL) and see if they can improve on the speed of the result. As I mentioned above, far too many people stop at "it works".

RE: The Full Potential of SQL 2000

sausage.dog — Mon, 15 Dec 2008 15:30:42 GMT

[quote][b]Derek Dongray (12/15/2008)[/b][hr]I've often felt that application development was faster when the tools were simpler.In addition, there was much tighter control over the result. For example, a "hello world" can still be written using the DOS debug command...[code]C:\> debug-n helloworld.com-a 1001552:0100 mov dx,010b1552:0103 mov ah,91552:0105 int 211552:0107 mov ah,4c1552:0109 int 211552:010B db 'Hello, World!',0d,0a,'$'1552:011B-r cxCX 0000:1b-wWriting 0001B bytes-q[/code]The result is all of 27 [b]bytes[/b] long.For a Visual Basic 2005 console application...[code]Module HelloWorld Sub Main() Console.WriteLine("Hello, World!") End SubEnd Module[/code]The compiled executable is 24.5 Mbyte![/quote]This sounded like FUD so I thought I'd try it out. C# console app, 5k executable. And with code that's orders of magnitude easier to maintain. There's nothing even remotely simpler or faster about what you wrote. I built the example in under a minute and had output of a real world, distributable application. All you have is DOS script. What's the point you're trying to make here? 27 bytes of source that's good for nothing?Most people posting here sound completely detatched from reality and are completely ignoring the benefits modern tools give the developer. ASP.Net let's you build a scalable, thread-safe web app in a day. You can go back to C and write procedurally, or to C++ and have to manually manage memory again, but there's a reason people don't and why you'll never get a business case off the ground to do so. Hey, chuck out web services and go back to writing proprietary APIs coded directly to the TCP/IP stack while you're at it. [i]That'll[/i] make your app faster to write and resuable for partners, I'm sure.The reason apps take longer to write nowadays is they're bigger, talk to more systems, manage more data, and have more bureaucracy as a result. Crappier tools won't change any of that. If you don't want to design an enterprise data model to aggregate your systems you don't have to. If you don't want to go to the effort of building using SOA principles you can still do one off "enhancements" on two systems to move data with flat files. But you get what you pay for and there's a reason these are considered bad practices in the real world.

RE: The Full Potential of SQL 2000

Steve Jones - SSC Editor — Mon, 15 Dec 2008 11:14:47 GMT

I see lots of web type apps being built quickly. Backpack (37 Signals) was built fairly quickly. I have seen corporate apps built in much less than a year, when it seems that early in my career everything took 1+ years.I'm not sure we build from scratch anymore, which shortens development time, but without having to build from scratch, I think we end up training programmers that aren't as capable. My vote is that everyone needs to learn C for a semester, then C++, work through pointers, sorts, and much of the fairly low level programming problems to understand how Java, .NET and other high level languages work.Lotus and some of those older apps aren't good templates because I think top-notch programmers are just way, way more efficient. And there are few of them out there, past or present.

RE: The Full Potential of SQL 2000

Steve Jones - SSC Editor — Mon, 15 Dec 2008 11:10:32 GMT

10 print "Hello World"

RE: The Full Potential of SQL 2000

Jeff Moden — Mon, 15 Dec 2008 06:25:05 GMT

Heh...ECHO "Hello World"SELECT 'Hello World'PRINT 'Hello World'

RE: The Full Potential of SQL 2000

Phil Factor — Mon, 15 Dec 2008 06:04:12 GMT

[font="Courier New"]// You can still do it in under 2K// Maybe we'll have to start a software movement for old // codgers like me who like writing compact software in assembler code.assembly extern mscorlib {} //Common Object Runtime Library.assembly HelloWorld{ .ver 1:0:0:1} //we can add a lot more information in this block.module HelloWorld.exe //the module name of our assembly.method static void main() cil managed{ .maxstack 1//max no. of items on the parameter stack .entrypoint ldstr "Hello world!" call void [mscorlib]System.Console::WriteLine (string) ret}[/font]

RE: The Full Potential of SQL 2000

Derek Dongray — Mon, 15 Dec 2008 05:37:28 GMT

[quote][b]Phil Factor (12/15/2008)[/b][hr]This is always going to be subjective, but there certainly seems to be a perception that applications just don't seem to be developed any faster for all the 'Rapid Application Development' going on. Jonathan Sachs developed the whole of Lotus 123 V1 in assembler code in just six months in 1982, and the whole project took only a year.[/quote]I've often felt that application development was faster when the tools were simpler.In addition, there was much tighter control over the result. For example, a "hello world" can still be written using the DOS debug command...[code]C:\> debug-n helloworld.com-a 1001552:0100 mov dx,010b1552:0103 mov ah,91552:0105 int 211552:0107 mov ah,4c1552:0109 int 211552:010B db 'Hello, World!',0d,0a,'$'1552:011B-r cxCX 0000:1b-wWriting 0001B bytes-q[/code]The result is all of 27 [b]bytes[/b] long.For a Visual Basic 2005 console application...[code]Module HelloWorld Sub Main() Console.WriteLine("Hello, World!") End SubEnd Module[/code]The compiled executable is 24.5 Mbyte!

RE: The Full Potential of SQL 2000

Phil Factor — Mon, 15 Dec 2008 01:56:22 GMT

Certainly in the UK, we are beset by a number of failures of high-profile government IT initiatives. I feel sure that the average run-of-the-mill IT application within any organization is taking longer to complete. Even fifteen years ago, had I come up with an IT application to support a business that was going to take a year to implement, I'd have been laughed at.This is always going to be subjective, but there certainly seems to be a perception that applications just don't seem to be developed any faster for all the 'Rapid Application Development' going on. Jonathan Sachs developed the whole of Lotus 123 V1 in assembler code in just six months in 1982, and the whole project took only a year.

RE: The Full Potential of SQL 2000

Jeff Moden — Sun, 14 Dec 2008 20:41:54 GMT

BWHAAA-HAAAA! What life cycle? People can't even spell it anymore.

RE: The Full Potential of SQL 2000

Steve Jones - SSC Editor — Sun, 14 Dec 2008 16:52:40 GMT

Are we sure it takes longer for new applications? I know we're in a mode of enhancing applications in small ways on a regular basis, but it seems that we do often develop new applications in months or even weeks instead of years.Is quality down? Not sure about that, it's not great now, but it wasn't great before. At least not 10-15 years ago.I do agree that more and more we have people that are less and less qualified touching applications and making life hard for us. We upgrade too much, and I think that's a problem. Instead of charging for support and having longer lifecycles, we have shorter lifecycles, and often free or discounted support (and we get what we pay for). I think I'd like to have us go back to 4-5 year time frames for new versions and have support for 8-12 years for each one.

RE: The Full Potential of SQL 2000

Jeff Moden — Sun, 14 Dec 2008 09:53:55 GMT

[quote][b]Phil Factor (12/14/2008)[/b][hr]I'm not sure if I buy the idea that it is becoming simpler and simpler to write applications because the tools we use are getting better and better. It is this belief that keeps driving us on to upgrade to the latest bleeding edge of Microsoft product whatever the inconvenience and cost. It may be a good idea, but we need to make a conscious decision.Over the past twenty years, the lead-time for new applications has been getting longer and longer, they are getting more and more expensive, and the failure rate has remained constant. There have been some huge breakthroughs, certainly, and the expectations, and demands for quality and compliance have increased enormously, but basically, the increase in the complexity of the software tools we use has not been mirrored in more rapid or successful application development. There has always been a huge gap between marketing and reality in the IT industry.[/quote]Very well said. That just about sums up the reasons why I don't care for DTS, SSIS, CLR's, Business Objects, and a host of other flashy computational aberrations that supposedly enable people to be more productive. People have to become familiar in many areas to do what... Import a simple file? Do a simple split? Create a running total? Join a couple of tables? How many times have you seen a DTS or SSIS job where something (supposedly) can't be done and people revert to an writing an ActiveX component or a PERL script or CLR... etc, etc. I'm seeing that in my current job, alot! And, everything they're writing that way is either slow or horribly and unnecessarily complex. For example, they have a very complex file type to import that defies all conventional methods of import. They wrote a DTS job that uses Perl scripts, ActiveX and a couple of other computational flavors. It takes 40 minutes on a file of just 30,000 rows and 215 columns wide just to get the file [i]ready [/i]for import never mind doing the actual import. Using 100% T-SQL in a comparitively short sproc, I get the same thing done [i]PLUS [/i]the actual import in 92 seconds.Microsoft keeps adding/releasing products to "make it easier" to use SQL Server. As a result, people who know nothing of databases are now using and abusing it. It's made SQL Server much more popular, but it sure plays hell on systems when these people touch the data.Some folks say I'm being stubborn about not using tools other than T-SQL. I guess that's pretty much true... when I can take a complex file import from 40+ minutes down to 90 seconds or write T-SQL to change a 24 hour, 62 database dupe-check that would usually fail, to a very lean T-SQL sproc that does 93 databases in 15 minutes and hasn't failed yet, I'm thinking that lots of folks just haven't taken the time to really explore the full potential of SQL Server and, especially, T-SQL. Further, it only took me three days to do it including final acceptance testing. The original dupe check, written in C#, took 2 developers 2 weeks to make something slow, unreliable, and not leave enough time in a day to actually do the full 93 database requirement.As you can tell, I not only agree that all these flashy products HAVEN'T increased productivity, effeciency, accuracy, or performance of applications, I believe that they've generally caused a decrease in all of that and an increase in the cost of getting products to market even if the market is "in house usage". There are exceptions, of course, like Reporting Services, but for the most part, I think most folks have fallen for the Microsoft marketing strategy and the "you're stupid if you don't do this" mentality... I think the flash of all that other stuff get's in their eyes when it comes to making common sense and innovative applications.

RE: The Full Potential of SQL 2000

Phil Factor — Sun, 14 Dec 2008 04:51:31 GMT

I'm not sure if I buy the idea that it is becoming simpler and simpler to write applications because the tools we use are getting better and better. It is this belief that keeps driving us on to upgrade to the latest bleeding edge of Microsoft product whatever the inconvenience and cost. It may be a good idea, but we need to make a conscious decision.Over the past twenty years, the lead-time for new applications has been getting longer and longer, they are getting more and more expensive, and the failure rate has remained constant. There have been some huge breakthroughs, certainly, and the expectations, and demands for quality and compliance have increased enormously, but basically, the increase in the complexity of the software tools we use has not been mirrored in more rapid or successful application development. There has always been a huge gap between marketing and reality in the IT industry.

RE: The Full Potential of SQL 2000

Jeff Moden — Tue, 02 Dec 2008 17:57:27 GMT

I know lot's of good folks that like it, but I don't care for Oracle much, either. Many will disagree with me, but I find it too limiting.

RE: The Full Potential of SQL 2000

Rudy Panigas — Tue, 02 Dec 2008 06:24:42 GMT

Either way, it's still a very good product. I've used Sybase and now forced to learn Oracle, when you see/use them you will appropriate the SQL server even more. Just hope that Microsoft will continue to listen to the SQL communities and find a way to still make money and keep us all happy. Just my 2 cents worth.Rudy

RE: The Full Potential of SQL 2000

Steve Jones - SSC Editor — Mon, 01 Dec 2008 20:48:13 GMT

It's always a balance. We complain and ask for things to be fixed, stabilized, sped up, and there are changes made in those areas, but it's a business and there is a push to implement new features to create sales.I'm with you for the most part. I wish we'd get more stable every 2 years and then every 4 years a new version, but it looks like the other way. A new version every 30 months or so.

RE: The Full Potential of SQL 2000

Jeff Moden — Mon, 01 Dec 2008 20:38:16 GMT

That's exactly what SQL Server 2008 is... the ultimate service pack for 2005 ;)

RE: The Full Potential of SQL 2000

Rudy Panigas — Mon, 01 Dec 2008 07:08:43 GMT

I like your question " Have I even got close to exploiting the full potential of SQL Server 2000?" This could also be asked of SQL 2005. With SQL Server or any other software, you will never see its full potential as long as new version get pumped out every 2-3 years. It's all about business and making money not about making SQL Server better...until the next version. I really enjoy working with SQL Server as most of you, I only wish that instead of making new versions, why not just continues and add to existing foundation? Add features, functions, processes. All these could be additional dollars and you would only pay for the upgrades needed.Just my cents worth.Rudy

RE: The Full Potential of SQL 2000

Steve Jones - SSC Editor — Sun, 30 Nov 2008 22:35:41 GMT

SQL 2000 is a great, stable platform and it's served me well in many situations. I've had all kinds of businesses run well on it, including this one. We upgraded to 2005, but we didn't need to and SQL 2000 would likely run this site for a long time to come.That being said, I'm not sure I'd continue to develop on this platform since support (mainstream) is essentially done and you never know when you'll run into an issue you need help on. People continue to find bugs all the time with new development.SQL 2005 and 2008 are great evolutions of the product and I'd recommend them to anyone. However I'm not sure I'd upgrade existing applications without a good reason. Continuing development might be a reason to do so.And thanks for the editorial, Tony. Nice to have a break.

RE: The Full Potential of SQL 2000

steve dassin — Sun, 30 Nov 2008 15:21:58 GMT

Hello Steve,I agree with you that while excitment sells it doesn't necessary mean progress. And not everyone wants to blow the same whistle and reach for the newest brass ring. But when it comes to things like matrix work benches there seems a need for a reality check too. What you are encouraging is to go where there is absolutely no intent. Yeah, you can play around. You can also try to manage an enterprises data with fortran. So it's not surprising that some spacecadets think nothing of using the server for factor analysis. If this is for 'real' and for 'real' data, then here's the check mate - that's crazy. Professionals know the tools for their trade, or should. You don't play chess with checkers. If you want to deal with matrices or multivariate analysis you go with the software where that's the intent. You check out the IMSL library, SAS, SPSS or BMDP. They've been around a hell of a lot longer than sql server and their stuff is burned in. You don't go cobbling together select and backdoor update statements. MS users should learn more about broads, as in horizons.best,steve dassin[url=http://www.beyondsql.blogspot.com][b]www.beyondsql.blogspot.com[/b][/url]P.S. If you want real arrays in real data management you need look no further than the combination of Dataphor/Sql Server.

RE: The Full Potential of SQL 2000

sausage.dog — Sun, 30 Nov 2008 15:20:29 GMT

Why build using managed languages? Why build using object oriented languages? Why build using high level languages? Let's all go back to assembler.The editorial is inane. Why would you [i]want[/i] to do things the hard way when you've been given a productivity tool to do things simpler, faster. Why would you [i]want[/i] to build [i]anything[/i] on a platform at its end of life?I get that the article is rhetorical, but most people don't jump on new features because they're new. They do it because it provides a simple framework to be more productive, more agile, cheaper to build, and easier to maintain. Just imagine what would happen to your proprietary SQL Server 7.0 framework the moment a body walks out the door.

RE: The Full Potential of SQL 2000

Salvador S. Scardua — Sun, 30 Nov 2008 09:05:01 GMT

Hello for All,About Potencial of the Versions of SQL Server, in my company we migrated SQL Server 2000 for 2005, but all databases run in 8.0 compatibility mode. I study Report Service 2008 and until now, any new feature did not maked a difference, and I´m think in implement the Report Service 2005.Thanks,Brazil

RE: The Full Potential of SQL 2000

Jeff Moden — Thu, 27 Nov 2008 22:15:03 GMT

Heh... you know I'd show up with the idea that it "can all be done in T-SQL". Now, if we can just get Microsoft to stop deprecating stuff! :P

RE: The Full Potential of SQL 2000

RBarryYoung — Thu, 27 Nov 2008 18:30:22 GMT

Tony: I see some UDF's in the Matrix workbench: They're not going to work on SQL Server 7.0. :)

The Full Potential of SQL 2000

Tony Davis — Thu, 27 Nov 2008 17:01:48 GMT

Comments posted to this topic are about the item [B]The Full Potential of SQL 2000[/B]