When you start using the SQL Server Powershell extensions, you will find there are not a whole lot of cmdlets. The expectation is indeed that Powershell support means: cmdlets for every administrative operation you can perform. Did we miss something here? Nope, this is by design. We do intend to ship more cmdlets for common admin tasks, but our first goal was to unlock as many Object Models as we could in the first release.
We did provide some basic cmdlets to start you off with. We know that DBA's willl have tons of T-SQL scripts that they will not abandon immediately in favor of Powershell. These scripts can be integrated with Invoke-Sqlcmd. We also provided a cmdlet to evaluate Policies, something that will come in handy if you have a lot of servers to manage (see one of my previous posts that contains a reference to an excellent blog entry from Lara on this subject).
Right now you will find that you can navigate to four different object models:
- SQL Server Relational Managenent Objects (SMO)
- Policy Based Management Objects (DMF)
- Data Collection (DC)
- Server Registration
An interesting fact is that the SQL Provider that provides access to these models is almost totally agnostic about these models. It does navigation, and serves these objects to the Powershell host, but without any code that is aware of each of these models. It's made pretty generic and the plan is to start covering all other services (Analysis Server's AMO, RS, etc.) in the same fashion.
Now, back to 'where are the cmdlet's'.
We do plan to provider various common cmdlets for common tasks, such as backup, restore, transfer, adding logins and users (pending customer research). But with the provider serving up objects you have almost instant access to any adminstrative commands you need. Let me illustrate this with an example:
PS C:\> cd SQLSERVER:\SQL\W2K3-TEST3\KATMAI\Logins
PS SQLSERVER:\SQL\W2K3-TEST3\KATMAI\Logins> $t=get-item TEST
PS SQLSERVER:\SQL\W2K3-TEST3\KATMAI\Logins> $t.ChangePassword("asdasd182eqwke111AA")
Another thing to point out is that if you take a look at SMO, DMF, DC, RS, AMO, and the other object models you will find there are hundreds of different of objects and literally thousands of operations you can perform. Strictly speaking, if you were to provider full coverage you would end up with hundreds (maybe over a thousand) cmdlets. This makes discoverability quite cumbersome (let alone it is a huge investment to unlock something that is inherently available). And the complexity of some of the cmdlets would make it not practical. Take for example the Transact-SQL statement to create a table. This is a very hard thing to encapsulate in a cmdlet (or new-item). Go try to think up the cmdlet to support all of CREATE TABLE. This is where the provider will be your friend. Issue a Get-Item to grab the parent. Instantiate a new SMO object and modify it to your liking. Then parent it with the reference you received from the Provider and create it. This is how this looks like:
cd SQLSERVER:\SQL\W2K3-MVP\DEFAULT\Databases\tempdb
$t = new-object Microsoft.SqlServer.Management.Smo.Table
$t.Parent = (get-item .)
$t.Name ="test"
$c = new-object Microsoft.SqlServer.Management.Smo.Column
$c.Parent = $t
$c.Name = "c1"
$c.DataType = ([Microsoft.SqlServer.Management.Smo.DataType]::Int)
$t.Columns.Add($c)
$t.Create()
