InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 18 Jun 2013 15:45:12 GMT20http://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Lynn Pettis (5/27/2009)[/b][hr][quote][b]Jeff Moden (5/27/2009)[/b][hr][quote][b]Damus (5/27/2009)[/b][hr][quote][b]Jeff Moden (5/27/2009)[/b][hr][quote][b]Damus (5/27/2009)[/b][hr]Sending it to you with an explanation.[/quote]Why don't you just attach it to this thread so the rest of us can take a peek, as well?[/quote]The "powers that be" who created are proly on SSC. lol trust me, they will know it at first glance, and I will be in trouble.[/quote]Understood. But we can't help what we can't see. ;-) Good luck.[/quote]Damus, May I send to code you provided so far to Jeff?[/quote]For sure, no problemWed, 27 May 2009 09:32:20 GMTDamushttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Jeff Moden (5/27/2009)[/b][hr][quote][b]Damus (5/27/2009)[/b][hr][quote][b]Jeff Moden (5/27/2009)[/b][hr][quote][b]Damus (5/27/2009)[/b][hr]Sending it to you with an explanation.[/quote]Why don't you just attach it to this thread so the rest of us can take a peek, as well?[/quote]The "powers that be" who created are proly on SSC. lol trust me, they will know it at first glance, and I will be in trouble.[/quote]Understood. But we can't help what we can't see. ;-) Good luck.[/quote]Damus, May I send to code you provided so far to Jeff?Wed, 27 May 2009 08:38:54 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/27/2009)[/b][hr][quote][b]Jeff Moden (5/27/2009)[/b][hr][quote][b]Damus (5/27/2009)[/b][hr]Sending it to you with an explanation.[/quote]Why don't you just attach it to this thread so the rest of us can take a peek, as well?[/quote]The "powers that be" who created are proly on SSC. lol trust me, they will know it at first glance, and I will be in trouble.[/quote]Understood. But we can't help what we can't see. ;-) Good luck.Wed, 27 May 2009 08:36:46 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Jeff Moden (5/27/2009)[/b][hr][quote][b]Damus (5/27/2009)[/b][hr]Sending it to you with an explanation.[/quote]Why don't you just attach it to this thread so the rest of us can take a peek, as well?[/quote]The "powers that be" who created are proly on SSC. lol trust me, they will know it at first glance, and I will be in trouble.Wed, 27 May 2009 08:11:00 GMTDamushttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote]If you are writing stored procedures that are using complex logic with cursors and/or while loops you aren't using the power of SQL and set based processing.It would be interesting to see an example of where you are doing this as I am sure there are many people on SSC that would look at how one of your procedures could be rewriting not use a cursor/while loop.[/quote]One thing that I've never been able to accomplish is to get a recursive CTE that lists all elements in a directed acyclic graph. e.g. you have a table x with a node column and a parent column, you can have multiple rows for each node as each node can have multiple parents. create table x (node int, parent int);insert into x values (1, NULL)insert into x values (2, 1)insert into x values (3, 1)insert into x values (4, NULL)insert into x values (5, NULL)insert into x values (2, 4)insert into x values (2, 5)insert into x values (6, 2)insert into x values (7, 2)Sorry, it's late and I'm tired so I might have made a mistake somewhere in the syntax/structure.Wed, 27 May 2009 08:08:43 GMTta.bu.shi.da.yuhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/27/2009)[/b][hr]Sending it to you with an explanation.[/quote]Why don't you just attach it to this thread so the rest of us can take a peek, as well?Wed, 27 May 2009 07:59:59 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Lynn Pettis (5/27/2009)[/b][hr][quote][b]Damus (5/27/2009)[/b][hr][quote][b]GSquared (5/26/2009)[/b][hr][quote][b]Damus (5/26/2009)[/b][hr]I agree its a management Issue.some other things i would like to see:- real foreach loops through table rows.- object oriented friendly organization of stored procs and triggers coz they are forgotten once you compile them. I can look them up at the moment on the management studio UI or through some SQL function that I will have to memorize. :)- enumerationsthose are just what is on my mind right now. will continue tomorrow :) Thanks again guys[/quote]I guess I'd have to know what "real foreach loops" would mean, as opposed to cursors. Can't agree or disagree with something where I'm not clear on what you mean.On organizing procs and such, that would be nice. Would be good to be able to see all procs/triggers/UDFs, etc., that are related to a table, all in one place. Not sure how I'd want that implemented, but the current tree views in SSMS could certainly be improved. Naming conventions and schemas only go so far. (I consider it a great irony of SQL Server that we're managing a relational database through an interface that relies on a hierarchical database of tree-views.)I don't know what exactly you mean by enumerations in this case. Care to expand on that?[/quote]Sorry for the late reply, I stay in europe :) 1 - foreach loops: Hope I can explain that right :)I for one, would like to limit all calls to the database to (select record/s, update record/s, delete record/s) which are atomic, easy to maintain and read and SQL server is very efficient at.However, in some projects, the architecture is as such that business logic is taken to the SQL server. Not saying that either is wrong or right. However, if we choose the second option, then we will have to start writing complex stored procedures using temp tables and cursors and all that. Its times like this when I wish SQL could provide some sort of more friendly syntax to programming (including the foreach , for loop, c syntax enumerations etc...)[/quote]If you are writing stored procedures that are using complex logic with cursors and/or while loops you aren't using the power of SQL and set based processing.It would be interesting to see an example of where you are doing this as I am sure there are many people on SSC that would look at how one of your procedures could be rewriting not use a cursor/while loop.[/quote]Sending it to you with an explanation.Wed, 27 May 2009 07:01:18 GMTDamushttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/27/2009)[/b][hr][quote][b]GSquared (5/26/2009)[/b][hr][quote][b]Damus (5/26/2009)[/b][hr]I agree its a management Issue.some other things i would like to see:- real foreach loops through table rows.- object oriented friendly organization of stored procs and triggers coz they are forgotten once you compile them. I can look them up at the moment on the management studio UI or through some SQL function that I will have to memorize. :)- enumerationsthose are just what is on my mind right now. will continue tomorrow :) Thanks again guys[/quote]I guess I'd have to know what "real foreach loops" would mean, as opposed to cursors. Can't agree or disagree with something where I'm not clear on what you mean.On organizing procs and such, that would be nice. Would be good to be able to see all procs/triggers/UDFs, etc., that are related to a table, all in one place. Not sure how I'd want that implemented, but the current tree views in SSMS could certainly be improved. Naming conventions and schemas only go so far. (I consider it a great irony of SQL Server that we're managing a relational database through an interface that relies on a hierarchical database of tree-views.)I don't know what exactly you mean by enumerations in this case. Care to expand on that?[/quote]Sorry for the late reply, I stay in europe :) 1 - foreach loops: Hope I can explain that right :)I for one, would like to limit all calls to the database to (select record/s, update record/s, delete record/s) which are atomic, easy to maintain and read and SQL server is very efficient at.However, in some projects, the architecture is as such that business logic is taken to the SQL server. Not saying that either is wrong or right. However, if we choose the second option, then we will have to start writing complex stored procedures using temp tables and cursors and all that. Its times like this when I wish SQL could provide some sort of more friendly syntax to programming (including the foreach , for loop, c syntax enumerations etc...)[/quote]If you are writing stored procedures that are using complex logic with cursors and/or while loops you aren't using the power of SQL and set based processing.It would be interesting to see an example of where you are doing this as I am sure there are many people on SSC that would look at how one of your procedures could be rewriting not use a cursor/while loop.Wed, 27 May 2009 06:33:13 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxI thought that SQL Server had the ability to integrate with the .NET CLR, which would allow this to be done... I'm not that familiar with this aspect of the product though. Someone else might want to chime in?Wed, 27 May 2009 01:53:38 GMTta.bu.shi.da.yuhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]GSquared (5/26/2009)[/b][hr][quote][b]Damus (5/26/2009)[/b][hr]I agree its a management Issue.some other things i would like to see:- real foreach loops through table rows.- object oriented friendly organization of stored procs and triggers coz they are forgotten once you compile them. I can look them up at the moment on the management studio UI or through some SQL function that I will have to memorize. :)- enumerationsthose are just what is on my mind right now. will continue tomorrow :) Thanks again guys[/quote]I guess I'd have to know what "real foreach loops" would mean, as opposed to cursors. Can't agree or disagree with something where I'm not clear on what you mean.On organizing procs and such, that would be nice. Would be good to be able to see all procs/triggers/UDFs, etc., that are related to a table, all in one place. Not sure how I'd want that implemented, but the current tree views in SSMS could certainly be improved. Naming conventions and schemas only go so far. (I consider it a great irony of SQL Server that we're managing a relational database through an interface that relies on a hierarchical database of tree-views.)I don't know what exactly you mean by enumerations in this case. Care to expand on that?[/quote]Sorry for the late reply, I stay in europe :) 1 - foreach loops: Hope I can explain that right :)I for one, would like to limit all calls to the database to (select record/s, update record/s, delete record/s) which are atomic, easy to maintain and read and SQL server is very efficient at.However, in some projects, the architecture is as such that business logic is taken to the SQL server. Not saying that either is wrong or right. However, if we choose the second option, then we will have to start writing complex stored procedures using temp tables and cursors and all that. Its times like this when I wish SQL could provide some sort of more friendly syntax to programming (including the foreach , for loop, c syntax enumerations etc...)Wed, 27 May 2009 01:25:34 GMTDamushttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/26/2009)[/b][hr][quote][b]Lynn Pettis (5/26/2009)[/b][hr][quote][b]Damus (5/25/2009)[/b][hr]I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same :) I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in UniversityI say time for change, even if it is gradual[/quote]SQL is changing slowly, but what is wrong with the language? It does what is supposed to do which is access data.[/quote]/sigh. Seems I hit a taboo subject by saying that it is time to change. NOTHING is wrong with it. Nothing is wrong with Pascal, or Cobol, or punchcards either. They all do what they are/were supposed to do.[/quote]I think that's the point everyone's trying to make. COBOL is no longer (much) used because it's no longer required. Pascal is still being used in Delphi, which is hasn't died yet. Punchcards don't work well any more :-) SQL, however, does exactly what its meant to do, therefore it doesn't need to change!Tue, 26 May 2009 16:11:37 GMTta.bu.shi.da.yuhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/26/2009)[/b][hr][quote][b]Lynn Pettis (5/26/2009)[/b][hr][quote][b]Damus (5/25/2009)[/b][hr]I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same :) I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in UniversityI say time for change, even if it is gradual[/quote]SQL is changing slowly, but what is wrong with the language? It does what is supposed to do which is access data.[/quote]/sigh. Seems I hit a taboo subject by saying that it is time to change. NOTHING is wrong with it. Nothing is wrong with Pascal, or Cobol, or punchcards either. They all do what they are/were supposed to do.[/quote]When did you go through the "University"? SQL Server has changed quite a bit in the last 15 years, especially lately.The other thing is, a tool is only as good as its user. If you think that SQL Server has been "horribly" the same for the last 10 years, perhaps it's not the product that's stagnent. ;-)Tue, 26 May 2009 13:40:59 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/26/2009)[/b][hr]I agree its a management Issue.some other things i would like to see:- real foreach loops through table rows.- object oriented friendly organization of stored procs and triggers coz they are forgotten once you compile them. I can look them up at the moment on the management studio UI or through some SQL function that I will have to memorize. :)- enumerationsthose are just what is on my mind right now. will continue tomorrow :) Thanks again guys[/quote]I guess I'd have to know what "real foreach loops" would mean, as opposed to cursors. Can't agree or disagree with something where I'm not clear on what you mean.On organizing procs and such, that would be nice. Would be good to be able to see all procs/triggers/UDFs, etc., that are related to a table, all in one place. Not sure how I'd want that implemented, but the current tree views in SSMS could certainly be improved. Naming conventions and schemas only go so far. (I consider it a great irony of SQL Server that we're managing a relational database through an interface that relies on a hierarchical database of tree-views.)I don't know what exactly you mean by enumerations in this case. Care to expand on that?Tue, 26 May 2009 09:55:50 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Lynn Pettis (5/26/2009)[/b][hr][quote][b]Damus (5/26/2009)[/b][hr]I withdraw all comments I previously posted on this discussion. I appologize to anyone who was offended. Did not mean anything wrong.Peace (white flag)[/quote]I wasn't offended. I am curious what you think is wrong with the SQL (or in this case T-SQL) language that it needs improvement.[/quote]Actually, amusingly enough, I prefer to keep my scripts in a database. That way, I can apply "tags" to the scripts, like what database they apply to, what version of the database they are dependent on (yes, I keep version numbers of databases, and any DDL command has to apply an update to a CurrentVersions table), what project they are part of, and so on.It's not a full-on source control system, but it allows a lot more lookup flexibility than a hierarchy organization (folders and files).I got the idea from the original plans for WinFS, and from the way that Vista's photo album allows multiple tags on a picture/video file.Tue, 26 May 2009 09:50:56 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/26/2009)[/b][hr]- real foreach loops through table rows.[/quote]Why use RBAR when set based solutions work much better and efficiently?Tue, 26 May 2009 09:46:50 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxI agree its a management Issue.some other things i would like to see:- real foreach loops through table rows.- object oriented friendly organization of stored procs and triggers coz they are forgotten once you compile them. I can look them up at the moment on the management studio UI or through some SQL function that I will have to memorize. :)- enumerationsthose are just what is on my mind right now. will continue tomorrow :) Thanks again guysTue, 26 May 2009 09:40:06 GMTDamushttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxDamus,I don't see anything offensive in your posts, and I, too, would be surprised if anyone was offended. I think they just wanted you to defend your statement with more detail.That being said, the management of files is really a platform thing. The problem with SQL is that you submit your file to be compiled in a server, something you don't do with IIS or other applications, so it appears you've lost control. If we took away the ability of the source code to be on the server, then that would force some VCS to be used, but it might create other DR issues.That's really a management issue though, not a language issue.There are some language things that people would like, for example, native regular expressions built into SQL. I think Spatial data can have many enhancements, for things like CAD/CAM, but those a specialized areas.Encryption definitely needs more work, both in making it smoother, and ensuring that things work well. I'm not sure how to build indexing in there, but perhaps we need encrypted indexes that can be used.The whole permissions structure, IMHO, needs to change to allow databases to exist without the ability of SA to read the data. I could also see the need to have two-login authentication for some tasks.Some of these are infrastructure type enhancements, but they would need language support, and they might change the language.Tue, 26 May 2009 09:30:11 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx/relief Thanks guys :) for a moment there, you sounded like my x-boss ;-)anyways, not sure if i should post here or not. one question first:- How to manage SQL code (all stored procs, triggers, tables, change scripts etc...) in an easy streight forward way like we do with c# code for example. I personally try to organize them in source control as folders/subfolders, logical filenames etc... I would love to have a more efficient way.Tue, 26 May 2009 09:25:05 GMTDamushttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/26/2009)[/b][hr]I withdraw all comments I previously posted on this discussion. I appologize to anyone who was offended. Did not mean anything wrong.Peace (white flag)[/quote]I wasn't offended. I am curious what you think is wrong with the SQL (or in this case T-SQL) language that it needs improvement.Tue, 26 May 2009 09:19:29 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/26/2009)[/b][hr]I withdraw all comments I previously posted on this discussion. I appologize to anyone who was offended. Did not mean anything wrong.Peace (white flag)[/quote]I seriously doubt anyone was offended. Just wanted to know what specific improvements you want.Tue, 26 May 2009 09:14:29 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxI withdraw all comments I previously posted on this discussion. I appologize to anyone who was offended. Did not mean anything wrong.Peace (white flag)Tue, 26 May 2009 09:07:37 GMTDamushttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxDon,I think you are correct. Most people don't need the new features, and few use them. I'm not sure if it's 5% or 25%, but I bet it's low.That being said, I think there have been good improvements. CTEs have become a staple of mine, and I didn't think they were great when I first saw them. I think that PBM will become something much handier over time.Powershell? Not sure. It does look easier to use (to me) than VBScript. And miles easier than Perl.Tue, 26 May 2009 09:05:05 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/26/2009)[/b][hr][quote][b]Lynn Pettis (5/26/2009)[/b][hr][quote][b]Damus (5/25/2009)[/b][hr]I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same :) I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in UniversityI say time for change, even if it is gradual[/quote]SQL is changing slowly, but what is wrong with the language? It does what is supposed to do which is access data.[/quote]/sigh. Seems I hit a taboo subject by saying that it is time to change. NOTHING is wrong with it. Nothing is wrong with Pascal, or Cobol, or punchcards either. They all do what they are/were supposed to do.[/quote]It's not a question of taboos. It's a question of, do you have specific, finite improvements, or are you asking for change for the sake of change?The statement about it being old and therefore needing to change is "change for the sake of change", at face value. If you have specifics, that's another thing entirely.Edit: Actually, COBOL doesn't do what it was supposed to do. A major part of its original purpose was to eliminate the need for programmers, since businesspeople would be able to build their own computer solutions with it. It most definitely does not achieve that goal.Punchcards may do what they're supposed to, but keyboards and mice involve definite, finite improvements over them as input devices, and hard drives have definite, finite improvements over them as a means of storing compiled/uncompiled code/files.SQL in general and T-SQL in particular, and SQL Server, have gone through a number of evolutionary improvements since I started using them in 2000/2001, and a few revolutionary improvements have appeared in SQL Server, like CLR procs and functions. There have been quite a few of them that have very little if any actual practical use, but there have also been quite a few that have a tremendous usefulness.If you want to contribute to that continued evolution, or if you have something revolutionary that will be a huge improvement, say so and give specifics. Just lamenting how old SQL is and how tired that makes it, doesn't actually accomplish anything. (Sorry, I'm specifics and results oriented. Just the way I am.)Tue, 26 May 2009 08:30:53 GMTGSquaredhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxMany Sour Grapes to all who claim expertise in face of daily reality. The fact is most T-SQL programming is mundane and nearly all of the changes made by the Powers-That-Be are marketing messages instead of improvements. That is why folks disconnect from marketing meetings at marketing events.Do I need power shell? No. Do I need partioning in 2005 when I cannot defrag a clustered index? No. Most of the time if not all of the time, I read a new form of T-SQL coding and think, "Jeez, that's neat. I wonder if I will ever have a chance to use it?" and almost never find a reason to use it. I nearly always find a faster, more efficient way to do the same thing that doesn't lock up the network pipe, disk bind the data transfer or prevent users from retreiving data.The fact is there is a universal disconnection between the Powers-That-Be at the Microsoft SQL Server Universe and the people that use SQL Server. 95% of all DBAs and T-SQL programmers over-think the problems and write hundreds if not thousands of useless lines of code making things run slower and slower. And Microsoft encourages this bad coding because it thinks that people want to write thousands of lines of code that run really slow so they can buy really big machines with lots and lots of memory. This cycle feeds the machine that churns the purchase of operating systems and hardware. It's part of the "churn" that marketing people like to create in markets. But it doesn't help our users in any way or form.Nope it doesn't make our users' lives better. Sour Grapes. The folks disconnect from the meetings because the content is irrelevant to what they do. The content doesn't help them isolate bad code, make stuff run faster, eliminate blocking, etc... No improvements in T-SQL will ever do that. Only good code and design will do that and the Powers-That-Be don't teach good code and design. Only code coders do. And MS doesn't have any. They've all been replaced by marketing people.Tue, 26 May 2009 08:28:15 GMTdon_goodmanhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Lynn Pettis (5/26/2009)[/b][hr][quote][b]Damus (5/25/2009)[/b][hr]I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same :) I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in UniversityI say time for change, even if it is gradual[/quote]SQL is changing slowly, but what is wrong with the language? It does what is supposed to do which is access data.[/quote]/sigh. Seems I hit a taboo subject by saying that it is time to change. NOTHING is wrong with it. Nothing is wrong with Pascal, or Cobol, or punchcards either. They all do what they are/were supposed to do.Tue, 26 May 2009 08:25:31 GMTDamushttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/25/2009)[/b][hr]I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same :) I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in UniversityI say time for change, even if it is gradual[/quote]SQL is changing slowly, but what is wrong with the language? It does what is supposed to do which is access data.Tue, 26 May 2009 08:16:12 GMTLynn Pettishttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxInteresting. A few experts that haved dived in heavily to Powershell and they seem to like it. It follows what I'd consider is a very simple format and structure.Whether it's good or not, I think it will take off in the MS world since it will be built into every server in the next 3-5 years. At that point, you'll start using it as a default. Just like VBScript, which is relatively simple to start with, and then gets horribly convoluted, established itself since it was built into Windows.Tue, 26 May 2009 08:09:03 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote]ChrisNI questioned the choice of PowerShell as the core scripting language coming from my decades of scripting and development experience on another redgate forum and was told basically to shut up and enjoy the ride.[/quote] I hope it wasn't a Simple-Talk forum! Simple-Talk ran a number of PowerShell articles and we were surprised at the lack of keenness for the scripting shell. After quite a bit of debate, we came to the conclusion that it was just too arcane. Although it would be quixotic to believe we can change the general flight to Powershell, we can see IronPython and IronRuby being far easier to use for administrative scripting for a lot of folks. We're hedging our bets!Here again, the 'softies' are a bit out-of-touch with the work in ordinary IT departments. When the subject of Powershell came up in the recent DB Teched sessions, the DBAs in the audience showed little enthusiasm, as Tony noted in his editorial when they were confronted with complex XQuery etc.. (I seem to have been as interested in the audience reaction to what was said from the rostrum, as in the talks themselves, but these were recorded anyway for posterity.)Tue, 26 May 2009 04:05:59 GMTPhil Factorhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]ta.bu.shi.da.yu (5/25/2009)[/b][hr][quote][b]Damus (5/25/2009)[/b][hr]I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same :) I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in UniversityI say time for change, even if it is gradual[/quote]Why? Just because it's the same old thing doesn't mean it's not worthwhile. I'm curious as to your reasoning.[/quote]Dont get me wrong :) it all still works, I am not attacking it. Just not [b]evolving [/b]like other technologies. Maybe coz its very basic, or maybe coz they are pulled back with backward compatibility like someone posted earlier.Mon, 25 May 2009 06:56:46 GMTDamushttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Damus (5/25/2009)[/b][hr]I am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same :) I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in UniversityI say time for change, even if it is gradual[/quote]Why? Just because it's the same old thing doesn't mean it's not worthwhile. I'm curious as to your reasoning.Mon, 25 May 2009 06:46:58 GMTta.bu.shi.da.yuhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Jeff Moden (5/24/2009)[/b][hr][quote][b]ta.bu.shi.da.yu (5/24/2009)[/b][hr]Absolutely! I'm just saying that I think that open source projects are more influencable or are quicker to implement changes than closed source companies. My $0.02.[/quote]You and I both agree on that. The thing we may not agree upon is that I don't believe the ability to make very quick changes is always an advantage. Having the ability to quickly change something is great especially when it comes to quickly repairing a mistake. I'll also suggest that having the ability to chickly change something will likely make you more prone to mistakes unless you have a stong regimen to prevent mistakes. That creates a bit of a paradox in my mind. That paradox is embodied by the old saw of "Why is there never enough time to do it right the first time but there's always time to do it over?" :-)[/quote]Actually, I do agree with you. I work for a commercial, closed source software house that was recently purchased by EMC. I see a great deal of pluses and minuses to both approaches to development, and I certainly never believe that quick and ill-thought out changes are a good thing! Believe me, I've seen what happens when changes aren't thought through and implemented quickly. It ain't pretty...:-)Mon, 25 May 2009 06:45:30 GMTta.bu.shi.da.yuhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxI am just a programmer. Been in the business for over 10 years now, I have changed the way I code so many times, but when it comes to SQL code, its still the same, horribly the same :) I Might create/use stuff to make things simpler, wrappers, helpers, flashy SQL text editors etc... But, it still is the same old SQL I learned in UniversityI say time for change, even if it is gradualMon, 25 May 2009 02:02:51 GMTDamushttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote]saw of "Why is there never enough time to do it right the first time but there's always time to do it over?"[/quote]and over, and over, and over - until we no longer remember what it was supposed to do in the first place.Sun, 24 May 2009 11:09:40 GMTJeffrey Williams 3188http://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]ta.bu.shi.da.yu (5/24/2009)[/b][hr]Absolutely! I'm just saying that I think that open source projects are more influencable or are quicker to implement changes than closed source companies. My $0.02.[/quote]You and I both agree on that. The thing we may not agree upon is that I don't believe the ability to make very quick changes is always an advantage. Having the ability to quickly change something is great especially when it comes to quickly repairing a mistake. I'll also suggest that having the ability to chickly change something will likely make you more prone to mistakes unless you have a stong regimen to prevent mistakes. That creates a bit of a paradox in my mind. That paradox is embodied by the old saw of "Why is there never enough time to do it right the first time but there's always time to do it over?" :-)Sun, 24 May 2009 10:57:33 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote]The people best qualified to pass verdict on T-SQL, or any other tool, are the people for whose use it was designed. The right to debate and argue with developers at Microsoft about how they've built products is not the sole the preserve of academics, trainers, MVPs, and other assorted members of Microsoft's "inner circle".[/quote]Make sure you don't run afoul of the "Redmond does no wrong fun club" even if you make valid criticism. I questioned the choice of PowerShell as the core scripting language coming from my decades of scripting and development experience on another redgate forum and was told basically to shut up and enjoy the ride. So I'm struggling to jump through hoops writing in a Yet Another Syntax. (Already working in VB, VFP, C#, Python, JScript and TSQL, not to mention other tools on other platforms....):crazy:Sun, 24 May 2009 10:16:43 GMTchrisn-585491http://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxI would agree that Open Source tools can respond quicker, and changes can be made. However it's a double edged sword, as Jeff pointed out. Often there are people that changes things they shouldn't.And forks cause other issues with support and understanding. If you've forked the tool, if it breaks or when someone else expects it to work another way, it can cause other issues.Open Source solves some problems, but creates others. Microsoft has to make decisions and we won't always like them. I would like to see more add-ons and additions to things like SSMS rather than having it closed off.Sun, 24 May 2009 10:13:00 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]Jeff Moden (5/23/2009)[/b][hr][quote][b]ta.bu.shi.da.yu (5/23/2009)[/b][hr]Well, bare in mind I'm talking about organized projects, not little snippets of code. Look at the Samba project - they're about to get to the point where you can replace a DC in a Windows domain. Then look at the Postgres project, they're doing amazing work also.[/quote]Well, bare in mind that you made no such stipulation to begin with. ;-) [/quote]A fair point - sorry about that. [quote] I agree that well thought out projects can usually be a real benefit in open source environments. The problem is that many people add code that just shouldn't be called "code" even in such well organized projects.Look at MySQL... I don't remember what the function is called but they have a function to create a numbered "table" on the fly. Last time I tested it (years ago now), it took a really, really long time just to generate a lousy million numbers. It was part of such an organized project and the code is terrible.[/quote]I'm not a huge fan of MySQL, ever since I read the [url=http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html]following blog [/url]post by its founder. However, I think it probably does scale, given that Wikipedia use it for their backend database. [quote]As with anything else, there are pros and cons to things like open sourced code.[/quote]Absolutely! I'm just saying that I think that open source projects are more influencable or are quicker to implement changes than closed source companies. My $0.02.Sun, 24 May 2009 02:08:31 GMTta.bu.shi.da.yuhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspx[quote][b]ta.bu.shi.da.yu (5/23/2009)[/b][hr]Well, bare in mind I'm talking about organized projects, not little snippets of code. Look at the Samba project - they're about to get to the point where you can replace a DC in a Windows domain. Then look at the Postgres project, they're doing amazing work also.[/quote]Well, bare in mind that you made no such stipulation to begin with. ;-) I agree that well thought out projects can usually be a real benefit in open source environments. The problem is that many people add code that just shouldn't be called "code" even in such well organized projects.Look at MySQL... I don't remember what the function is called but they have a function to create a numbered "table" on the fly. Last time I tested it (years ago now), it took a really, really long time just to generate a lousy million numbers. It was part of such an organized project and the code is terrible.As with anything else, there are pros and cons to things like open sourced code.Sat, 23 May 2009 22:01:04 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxWell, bare in mind I'm talking about organized projects, not little snippets of code. Look at the Samba project - they're about to get to the point where you can replace a DC in a Windows domain. Then look at the Postgres project, they're doing amazing work also.Sat, 23 May 2009 21:41:26 GMTta.bu.shi.da.yuhttp://www.sqlservercentral.com/Forums/Topic722599-263-1.aspxHeh... Open Source... Yep, I've seen what happens there. Just look at what some people write CLR's for. Some of it is good. Most of it is terrible.Sat, 23 May 2009 21:34:36 GMTJeff Moden