Tony, the great thing about PowerShell (as opposed to VBA, for example) is that it's consistent in how it uses objects.  Microsoft has finally realized that professional administrators need a consistent tool to manage the services running under Windows operating systems.  The verb-noun standard helps newbies come up to speed quickly in PowerShell, and aliases allow those with well-embedded habits to continue to use the commands they're familiar with.  (Get-ChildItem can be dir to a Windows admin or ls to a Unix admin.)

SQL Server 2008 introduces sqlps.exe, which is a wrapper for PowerShell with the SQL Server plug-ins which make it easier to write scripts to automate administrative tasks.  It's not hard to do these things now (come to my chalk-talk on this at Tech Ed IT Pro week) but the wrapper makes it easier.

BTW, PowerSMO is Dan Sullivan's function set for using SMO in PowerShell, and is described in his articles on this web site, it's not the PowerShell wrapper coming out with SQL Server 2008.  PowerSMO works with SQL Server 2005.

Cheers,

Allen

I don't disagree but consider that SMO's audience may not have been the DBA.  I suspect that it was developed first as a platform for their own tools (SSMS, etc.) and it was documented and released primarily for the 3rd party tools vendors.

Powershell is simply a response to the xNIX customers who have powerful shell scripting languages and want the same capabilities on Windows.  It's really a mystery why it has been so thinly adopted.  I don't know a single DBA on an xNIX platform that isn't a pretty good shell scripter.

I think this, "to impose the C# object-oriented orthodoxy on everyone", is the crux of the problem and not just in SQL Server.  

It is easy to do DMO scripting, and it isn't that much harder to use VB.NET and SMO. I'm really disappointed that SMO is no longer an OLE Automation tool. Microsoft tried, but abandoned the attempt. The reasons for this were lost in a cloud of spin.
I suspect that the main reason for the poor take-up of SMO is the paucity of example code on BOL/MSDN. The object model is a laborious thing to navigate too on BOL and the documentation seems to have been written by a Dalek.  The sample code often doesn't have any exception handling at all and is usually no more than a rough sketch. Thank goodness we have Allen White around to show us how to do it properly.

When I discovered DMO / SMO I was delighted with the promise of automating the functionality of SSMS. But despite the best attempts of Phil Factor and others to illuminate their use via T-SQL, was never able to master it. When Powershell arrived with the reflection afforded by Get-Member, I was freed from the BOL/MSDN puzzle palace and could discover the properties of the SMO objects on my own. As a DBA without a programming background, Powershell has proved for me to be an invaluable learning tool. This site has the sub title 'sql server and .net put simply'. Powershell has allowed me to bring sql server and .net into closer focus. And while I am not able to write C#, my experience with Powershell has at least allowed my to follow along. I welcome the addition of Powershell to SQL Server 2008 and would urge other DBAs to take a look at Powershell and SMO.

All the DMO dependent code we are using is being reworked into ADO and T-SQL
I am reluctant to build anything more on DMO or SMO given the deprecation of one and the lack of backwards compatibility of the other.
Unfortunately nether of these is the lowest common API (for SQL Server instances we support at the moment) so its hard to justify the investment to leverage off either technology.  

Tony -

I think your comments are dead on with respect to this - developers should live in the world of their intended market, THEN decide what the holy grail should look like.

Having worked for software development firms, I can characterize what I mean with this short anecdote.  Once during a program funding review, several hours were wasted whilst an engineer tried in vain to evangelize his audience of executives and convince them to provide his small team the hefty sum of $1.2 million for their project.  Finally in frustration, the general manager asked, "what do you see the ROI being for this product?".  To which the engineer gave a meek, "well, we're not sure we would sell even one copy, but it would be a really neat project and would keep the staff current with breaking technology."  This was a senior engineer with many years of "management" experience!

SQL & RDBMSs exists for specific purposes.  They are for use in managing vast amounts of data.  I have yet to run into much that requires me to reach outside of SQL to accomplish the tasks I get paid to do.

You want me to use VB, C#, .Net?  Fine, give me a business reason for it.  Show me how I'll reduce operating costs, bring product to market faster, etc.  Don't try to convince me that it will do something I'm capable of doing now "faster, cheaper, better".  I rarely see "faster, cheaper, better" actually materialize in the adoption of a new approach to doing something I'm already capable of doing.  When I do I move.  When I don't, I resent being prodded to it by having the horse I'm riding shot out from under me to force me to my a new horse.

That said, I wonder if this technology is aimed squarely at the DBA and database developer types, or could it be that it is aimed at the application developer types who live, eat, and breathe VB, C#, .Net?  I find that having been taught to think procedurally and code procedurally, these folks usually cannot quite grasp how to write efficiently in SQL because they don't understand relational theory.  My gut tells me this might be the case.  If so, then MSFT is perhaps preaching to the wrong choir and needs to re-think the SMO marketing message.

Although I'm not a DBA, even if I wasn't I'd hesitate before using SMO, and here's why I would.  Part of it has to do with what randyvol said about ROI, and I definitely agree with that, but an even bigger reason for me is "don't shoot at moving targets."  We've all been around long enough to see all vendors (not just Microsoft, although at times they seem like an especially skilled practioner) start something new, go in that direction for one or two versions, and then completely abandon it.  Why should I rework all of my tools (that still work) only to have the vendor dump support for "the new way" in the next version?  I'm better off to wait for one of two things to happen:  the vendor drops support for "the old way" forcing my change, or "the new way" has been around long enough (at least 3 versions) for the following conditions to be met: it works on all installations at my organization (we don't rush out and upgrade everything just because a new version comes out, we replace/upgrade when we have a business case to do so, just like everyone else) and the vendor seems to have decided it really is better and will continue to support it for a while, rather than it being "a flavor of the month".  Anyone want to take bets on wether SMO will be in SQL Server 2011?  

I was paid to write c++, but soon gave it up for a proper job.  Having said that, it did allow me to get my head round DMO and write some nifty (if I do say so myself) VB Scripts utilising the object model.  I never used SMO as I have never ran a SQL 2005 server in production.

I looked at Powershell when if came out, and I agree that it is a powerful language, aimed at stopping the *nix boys (and gals) from winging about how Windows has not got a ‘proper’ scripting language.  This is the first time I have read that SQL 2008 includes specific extensions, so along with the other features I’ve read about, I’ll be taking a closer look.

Jacko

A relational model for SQL Server management would be brilliant!  Not sure what it would look like, but I could see it being popular, especially if it was adapted to work with each new release.  I know I prefer using where clauses to if statements and try to avoid using loops in my stored procedures.  Database development forces you to do a different type of development.  Just like your average web developer will write ugly T-SQL, your average DBA would likely write ugly SMO code.