PASS, the Professional Association of SQL Server, is currently holding a contest, looking for people to blog or email them about the best thing they learned at a PASS Summit they've attended.

Networking: it's not just for sleezy marketing types.  Hmmm.  Perhaps.... Networking: it's not just for people looking for a new job.  Let's just say that before attending PASS I had some preconceptions about what 'networking' was based on the ugliest parts of it that I'd seen.  I don't wish to sound like I'm diminishing the value of the sessions that I attended, because I learned a ton that I could take back to my job, but I think the biggest value for my company from PASS was that the network of SQL Server professionals I met at the conference pays off every day.

Combined with technologies like email, RSS feeds, and Twitter, I have instant access to hundreds of smart SQL Server professionals who can answer a question I have.  Or, they may be talking about some topic I don't know I need to know about yet, and I find myself curiously prepared when the crisis comes.  And those professionals are of every type, from the luminaries of SQL Server to the folks just like me, solving the same problems I’m facing.

There’s nothing stopping you from connecting to those people outside of a conference via the internet, but, if I may be so bold, your primate DNA means your connection to that community is going to be ever so much stronger if you've had face time instead of just connecting through some glowing rectangle.  I hope I can help them as much as they help me daily.

Honestly, I was all set to blog more frequently, and then disaster struck.  My home desktop, the one on which I do most of my hobbies and tech stuff after work, had died a hard death thanks to the failure of my video card.  I had no on-board video to save me, and, to make matters worse, I couldn't even make a remote desktop connection into the machine.  The failure had been so bad that the abrupt power shutoff of the entire machine had corrupted my Windows install.  The only course of action left to me was to live without access to my machine, survive on the laptop that my wife had bought me one Christmas, even though my ownership of that machine is more akin to Marge's Bowling Ball.

 Fortunately, a couple months earlier I had been talking on twitter with a person or two about home backup strategies, and I had bravely professed that I didn't really back up files at home because, well, I didn't have anything that important to back up.  And then I remembered the bazillion digital photos that my wife has taken of our daughter and stored on my desktop, and I imagined the long, sleepless nights on a couch should anything happen to them.  That evening I quickly ordered an external backup drive, sought some advice on twitter about free backup utilities, and implemented my own daily backup strategy thanks to SyncToy 2.0 and Western Digital.

So, here we are, months later.  The desktop failed, and while I remain confident that I'll be able to retrieve all of my files from the original hard drive, I still have access to all of the important files thanks to my external hard drive.  And, I got to be the hero when I told my wife she had not lost an entire batch of photos that she'd just uploaded to the computer a couple days prior to the failure.  Don't get me wrong.  Hardware failures still suck, and I'm still pulling together pieces to fix my desktop and considering a new box, but a personal backup strategy can take away some of the sting.

When I wrote my previous blog post about blogging, I remembered how much of a sucker for the concept of recursion I'd become, even though it still bewilders me,  after I'd read Godel, Escher, Bach: An Eternal Golden Braid by Douglas R. Hofstadter.  I'd refer to it familiarly as GEB if I had a pointier head.  Alas, my head is too round, and full of mush, and so I'm left to contemplate whether irony isn't a form of recursion in itself.  I like irony.

Anyway, the other day I was searching the webz for a way to explore all of the WMI namespaces that are available on my machine, and I came across this PowerShell script that creates a GUI for exploring WMI namespaces.  It's an awesome script, but I'm still wickedly amused by the idea of using PowerShell, something that at least partially was made accessible to get away from GUI administration, to create a GUI interface.  Yes, yes, I know there's much more to PowerShell than that, but let me have my cheap thrills.

Anyway, if you, like the Incredible Hulk, think that 'GUI BAD!!!', then you can find out what WMI namespaces are available by getting the root namespace, and then looking at the __Namespace class, something like this:

gwmi -namespace "root" -class "__Namespace" | Select Name

Of course, as with most things PowerShell, there's more than 1 way to complete a task.  If you've had a long day in PowerShell and find yourself pining for T-SQL, why not use a little WQL, or SQL for WMI, to find out the same information?

Get-WMIObject -namespace "root" -query "SELECT * FROM __Namespace" | Select Name

So, armed with the namespaces, what can you find out?  Well, only what classes are in that namespace to explore, as the Powershell.com folks helped me figure out.

gwmi -namespace "root\WMI" -list

Got a favorite WMI class?  I'm kind of partial to Win32_PingStatus and Win32_Service from the default namespace CIMV2 at the moment.  I'm sure I'll have a different favorite tomorrow.

It's no small secret that I'm a big fan of using PowerShell to manage SQL Servers.  I've gone through all the trouble of loading the SQL Server assemblies and/or configured PowerShell to use the SQL Server provider, and I've jumped into SMO, sometimes to much joy, and sometimes to much sorrow.  But, the other day I started to wonder, 'Where's the object model for Reporting Services?  And, being a big fan of the Script method from SMO, can I script out an rdl of a report?'

 I started digging deeper, and sadly I could find no assembly or aspect of the SQL Server provider that would grant me easy(?) access to the Reporting Services objects.  So, I hit the documentation to find out why.

As Books Online was eager to point out, Reporting Services is fundamentally a web service that is accessed via the Simple Object Access Protocol (SOAP) over HTTP.  Huh?  Well, our friend BOL tries to explain further, stating that the web service has endpoints that you can connect to in order to either kick off reports or manage your report server.  So, great, how do I connect to a web service?

The internet abounds with suggestions, most of which revolve around using the Visual Studio and the .NET Framework's SDK in order to create a WSDL in order to create a proxy of the web service, thereby gaining access to the objects and the methods therein.  And, as I read those suggestions, I began to empathize, ever so briefly, with developers who must likewise look at relational databases as if there were some sort of horrible, horrible spawn of darkness.  Mainly, though, I was wondering how I was going to get around this problem without having to hit up my boss for a license to Visual Studio, and then spending hours to learn the ins and outs of web services, proxies, and using the great and glorious WSDL.exe to create a WSDL file.

 But, thankfully, the PowerShell community generally rules, and I was able to find a nifty little PowerShell script by Oisen Grehan which allows me to create a proxy to my Reporting Services without all the aforementioned yuckiness.  So, having downloaded the script, scanned it for a basic understanding of what's going on, and then placed it in my trusty C:\PowerShell directory, I fired up PowerShell and ran the following:

$url = "http://<myserver>/ReportServer/ReportService2005.asmx"
$proxy = C:\PowerShell\New-WebServiceProxy.ps1 -Url $url -SoapProtocol Soap

I provide my credentials at the prompt the script generates, and now, suddenly, I have access to information regarding the properties and methods I'm looking for on my Reporting Services installation with the simple yet powerful:

$proxy | gm

OK, great, so now we can access our Reporting Services objects, but what about generating that rdl for a report?  If I know the report name, including it's full deployed path of folders, I can use the GetReportDefinition method to get a byte array of the report:

$report = $proxy.GetReportDefinition("/<path>/ReportName")

And, then it's just a matter of converting that byte array to text, and writing it out to a file:

 [System.Text.Encoding]::ASCII.GetString($report) >> ReportName.rdl

Still, I think it would be much nice if the SQL Server PowerShell provider made it possible to accessing Reporting Services as part of the SQLServer: PSDrive.

I was tagged in a blog post making the rounds based on the question, 'Who has been a great leader in your career and what made them a great leader?'

I think I'll join the bandwagon on this way and politely decline on talking about great leaders in my career, except perhaps obtusely, and instead focus on what makes a great leader.  What makes a great leader?  In my mind, it's the following things:

 Advocacy

 A leader knows how to advocate for those he is leading, as well as advocating for the things that his followers truly believe are the right direction to go.

 A Good Listener

 No, this isn't a cheesy personal ad.  I think good leaders know how to listen to their subordinates and know when to rely on their technical expertise to help fill in holes in their own understanding of a situation.  Using this information, they are able to make good decisions on direction and set challenging, yet attainable goals.

A Keen, Analytical Mind

To me, a leader also has the ability to quickly identify a problem, either because they understand the inner workings of the technology, or the political situation, or because they've listened to their technical experts and know how to synthesize that information in order to make the best decisions.  Using this information, they figure out what needs to be done, they know how to direct the resources they have at their disposal, and, because they know their subordinates, they know what they need to do in order to inspire and motivate their employees.

Trust

 This one is huge.  Leaders have to be trustworthy or everything else is pointless.  Don't do anything to lose trust.  It's really hard to get back.

 Connect on a Personal Level

 A good leader knows you.  They know what motivates you, they know your weaknesses, and they know how to get the best from you.  They know how to challenge you without overwhelming you.

And, though I'm not tagging anyone further on this one, I PROMISE to tag at least one person next time one of these blog memes hits me.

One of the applications we have from a vendor has a SQL Server 2005 database with over 50,000 tables.  I was using the PowerShell provider for SQL Server to search through the tables to find any that had the word 'ROLE' in it using the following command:

get-childitem *ROLE*

But, in the results, only two tables where returned, and I was expecting plenty more.  In T-SQL I ran the following query:

SELECT count(*) FROM sys.tables
WHERE [name] LIKE '%ROLE%';

 This time I see that there are 133 tables in the database that have the string 'ROLE' in the name.

I recalled reading a blog somewhere about folks hitting an object limit when returning objects from Active Directory in PowerShell, so I begin to wonder if there isn't some sort of configuration inside the PowerShell provider for SQL Server that lets you set a limit for get-childitem.  And, sure enough, there is a global variable called $SqlServerMaximumChildItems.  However, mine is set to 0, which means I should be returning an unlimited number of objects.

I head back into PowerShell in the SQLServer:\Sql\<database>\<instance>\databases\<dbname>\tables\, and run the following statement:

(get-childitem *).count

 1000?  What if I change the SqlServerMaximumChildItems global variable to 20 and try the count again?

set-variable -name SqlServerMaximumChildItems -scope global -value 20

Nope, the directory count still shows 1000.  What if I bump up the variable to 2000?  Directory count still shows 1000.

 I try writing out the list of table names to a text file, and only 1000 table names are written.  Does PowerShell have a 1000 object limit?  That doesn't seem right, and my internet searches can't find anything to even suggest that.  In fact, I use invoke-SQLCMD to select the table names from sys.tables again and I get all 50,000 objects.  What about SMO 10.0?  That doesn't seem right either.  Something about the way I setup PowerShell to work with the SQL Server Provider?  Is there a bug in the SqlServerMaximumChildItems global variable?

Anyway, I tested it on another machine, and was able to reproduce the issue.

 I'm stumped.

Cloud computing is all the rage right now.  Many of the people I follow on Twitter, whose opinions I respect, are talking about it as the wave of the future.  Paul Nielsen made a bold prediction on his blog last month.  Brent Ozar blogs about it frequently and appears pretty excited about it.  And, without a doubt, the news today about SDS is adding momentum to cloud computing.

So, anyway, here I sit.  I'm in danger of slipping behind on my goals for 2009 to blog once a week.  I need a topic.  Why not cloud computing?

I'm a DBA.  I'm in the IT trenches every day, and my job boils down to making sure that people have access to their data, and that their data is protected; from theft, from disaster, from accidents, from their own mistakes.  I work hard during the day, and I have enough interest in my craft to dedicate some of my personal time to it.  Here's cloud computing through my lenses.  You’ll need your own grains of salt.

 When You're A Hammer...

Despite my best efforts, I’m not the creature of logic I strive to be.  And this is another one of those times when it’s very possible that my emotions are getting the better of me.  So, let me get the emotional part of my critique of cloud computing out of the way.  My instincts say it is not even going to come close to approaching the bold pronouncements of its major proponents, be they vendors or technology experts.  Why?  I’d counter that question with some questions for you.  How’s SOA working out for you?  How about offshoring?  Virtualization?

These are just a few examples of recent IT ideas that, while they looked great on paper, have in no way been universal successes.  I’m not suggesting that because they are not universal successes that they must be failures, but what I mean to say is that they have their time and place.  Clearly, your perspective has alot of influence on whether you consider them successes, and some of them have been more successful than others.  But, they are another tool in your toolbox for solving problems.

I see cloud computing as just another tool in the toolbox.  It will have some impact on the IT topography of companies, but it will not dominate the landscape for probably a couple decades.

So, where’s my proof?  I don’t have any.  It’s just my gut talking.  It’s my brain interpreting what I perceive as the loud volume of vendors advocating for the cloud, and the silence of customers, or potential customers, praising it as a success.  It’s my experience dealing with vendors and imagining that I will have the same sorts of problems dealing with cloud computing vendors that I do with hardware and software vendors today.  It’s my natural defense against hype.  It's all of those things, and probably more.

I Can See The Future?

It’s not fair for me to just play armchair critic and not risk a little something, so here are my predictions.

Over the next 18 months there will be a major push towards cloud computing in the IT press.  (C’mon, that’s a gimme.)

In 5 years, large companies will start pulling back from their initial, heavy investments in cloud computing for numerous reasons.  There will have been a high profile security breach.  A major cloud computing vendor will have gone belly up, likely due to some scandal, putting its customers at risk.

In 20-30 years my post will seem foolish, as cloud computing will be a common, natural, but still not exclusive, part of the IT landscape.  Why 20-30 years?  Because I think it’s going to take a cultural shift of kids growing up in a time of ubiquitous internet and the concept of non-tangible goods, like digital music files, to take leadership positions and express their unique view of IT in their companies’ decisions.

That’s Just A Start

I think I’ve got a lot more to say about cloud computing, but I’ve used up my blogging minutes for today.

When I start to learn a new technology, I find I learn best if I jump right in, get my hands dirty, and play around with it for a while.  After a couple initial ah-HA moments and early successes, I inevitably hit a wall where I can't seem to solve a particular problem.  By that time, I've built up quite a list of questions, and I'm ready for a deeper understanding of what's really going on.

At that point it's time for me to pick up a tech book and read.  And that's when I get a couple more ah-HA moments almost right away.  Case in point:  I've been working with PowerShell and SQL Server on a regular basis now for a couple months, and I've written a couple of scripts based on some tutorials I've found online and some excellent articles and blog posts people have written.  I'd hit that wall, and so based on the recommendations I'd read on a couple blogs, I picked up Bruce Payette's Windows PowerShell In Action. It's turning out to be an excellent read.

In a previous blog post I had written some code that had this little gem in it:

Get-Content $tblfile | ForEach {$trdir=$fulldir+"\dbo."+$_+"\triggers\"; cd $trdir; dir | ForEach{$_.Script()>> $outfile}}

Experienced PowerShell users can probably spot my code silliness right away.  As Bruce Payette's book explains, variables are expanded when placed within double quotes.  So, in the case above, assigning the string to $trdir is an extra, unnecessary step.  Knowing this, I could have saved my precious fingers for my accordion playing by dropping the $trdir assignment:

 Get-Content $tblfile | ForEach {cd "$fulldir\dbo.$_\triggers\"; dir | ForEach{$_.Script()>> $outfile}}

Were you to know that I was a DBA who primarily worked with T-SQL, this mistake would make sense.  T-SQL doesn't have something as nifty as expandable variables within quotes...but that doesn't make me love it any less.  But, you're a persistent reader, you went back and read my previous blog post, and you're quick to point out 'Tim!  You used double quotes to expand variables earlier in that same script!!!'  Would you believe that sometimes computers speak to me and I just KNOW what I should be doing without understanding it?  No?  You, reader, are much to clever and should be writing your own blog.  I promise to read it.