Why is -fill in the feature- Enterprise-Only?

Steve Jones (Blog/@Way0utWest) recently wrote a great blog post proposing that Microsoft should go from having edition-only features (most of them are "Enterprise-Only") to unlocking all features in all editions and instead licensing based on the scale of your actual server (CPU/RAM/etc.)

https://voiceofthedba.wordpress.com/2011/10/18/give-us-all-the-features/

Today, Steve opened a Connect item asking Microsoft to make these changes, titled "Include All Features in All Editions and License by Scale":

https://connect.microsoft.com/SQLServer/feedback/details/696092/include-all-features-in-all-editions-and-license-by-scale

To vote, you need to register on Microsoft's Connect site if you haven't already done so, but since Connect is the location for all of us to request feature changes (and rate others' requests) it doesn't hurt to be registered.

I voted YES - and I think you should too.  I know there have been multiple times when I have needed some feature (compression, transparent data encryption, etc.) and we didn't use it because we didn't want to pay $20K+ per CPU for an Enterprise license on a little implementation in a firewalled DMZ.

Paying based on scale rather than functionality makes sense to me - read Steve's blog post and see if you agree!

Moving to House of Brick

Starting Halloween Monday I will be a Technical Consultant for House of Brick Technologies.

To everyone out there saying "Didn't you just get a new job?" I say yes, but this is a unique opportunity with a company that is the leader in our field in this area if not the country.

As many of you know, I recently (about two months ago) left the internal First National Bank of Omaha IT department to go to work for First National's technology hosting company First National Technology Solutions (FNTS). This happened due to a combination of factors related to personnel and types of work, but was functionally a lateral move inside the First National infrastructure from one business unit to another.  FNTS is starting to ramp up their database services offering and I was the first DBA (other than my FNTS boss who was formerly my FNBO boss) brought on board.

Then the phone rang.

A high school friend (that I hadn't seen in 20+ years but whom I had recently offered career advice to when he sought me out 6-7 months ago) was calling; after not taking another job on my advice he had gone to work for House of Brick, and HoB was looking to expand. 

"What made you call me?" I asked.

Apparently the HoB management had gone online on LinkedIn and generated a list of potential candidates, and then had passed it through their current employees to see if anyone knew anyone on the list, and my friend had spoken up.  Was I interested in talking to several of them over lunch to hear what HoB does and consider whether I might be interested?

I had heard of this type of Social Networking situation before - where your social media contacts (Twitter/LinkedIn/Facebook/etc.) expose you to career opportunities that would never have existed otherwise - but this is the first time I had ever seen it happen to me (or anyone else I have worked with) - it was pretty amazing.

A lunch and a formal interview later and both sides were sold; House of Brick is a star in the SQL Server, Oracle, and VMWare consulting world with a team of DBA's already in place doing the work FNTS is just starting to get in to, with clients all over the country, and the work (SQL upgrades, migrations to VMWare, etc.) sounded amazing.

Several people have asked me - aren't you concerned about burning bridges with First National, and aren't you concerned about the effect on your resume of only being somewhere for a couple of months?  My response is that I wasn't looking for a job - I was set to work at FNTS and help them build their database area - but there are times in your career (and in life in general) when the phone rings and you have to answer - because the caller won't call back.

There are a few of my technical peers that get it without lengthy explanation, and one of them put it very clearly: If you didn't take this you would wonder about it and regret it for the rest of your career - this is the big leagues (or as close as it gets in Omaha, NE).  {-:  As I have told my boss at FNTS, this isn't anything against FNTS and I wasn't searching this out, but it definitely feels right to move onto an existing team rather than being the initial employee in the area.

The only flaw in the design is the 20-25% travel with HoB (compared to 0-0.000001% travel now) but I know we will make that work - this is the right thing for my career and since my career supports our family it is therefore the right thing for our family as well.

Do I think I will be the next Brent Ozar (B/T) or Thomas LaRock (B/T)?  Not really - but you never know!

Presenting for the First Time Ever!

At the prodding of one of the leaders of our local SQL user Group @sqlrus I submitted a session blurb to SQL Saturday 101 in Kansas City, even though I have never presented to a conference or user group before.

...and they accepted - now I *am* screwed.  {-:

Show up for "Free Tools to Expand Your SQL Knowledge" where I will discuss and demonstrate the usefulness of blogs/Twitter/etc. for both beginning and advanced DBA's - no one ever knows everything and these tools are available to help.

Hope to see you there!

I've Taken the SQL Server Resolution!

As part of the current T-SQL Tuesday I was browsing some of the blogs who had posts and on one of those blogs (Thomas Rushton, the Lone DBA - B/T) I saw the following icon:

Intrigued, I right-clicked on the icon (Safety First!), and saw that the icon came from Matt Velic (B/T) a SQL professional whose name I recognized, so I went ahead and clicked on the link.

Here is the text of the resolution, from Matt's January 2011 T-SQL Tuesday blog post - and it makes a lot of sense to me:

"I hereby resolve to work towards becoming a more proficient SQL Server professional. I will make opportunities to acquire knowledge, develop my skills, and grow in my profession. In working towards greater proficiency, I also resolve to enrich my relationships with family, friends and the SQL Server community. These people are my support system and are most deserving of my time and attention."

I hereby resolve to follow these statements, especially by becoming more involved in my local user group and in the SQL blogosphere.

Can you make the SQL Server Resolution?

T-SQL Tuesday #23 - Respect your JOIN's

It's that time again....         

Time for the SQL Server blogosphere's...recurring, revolving blog party - T-SQL Tuesday!  This month is hosted by Stuart Ainsworth (B/T) and his chosen topic is JOIN's.

When I think about JOIN's the first thing that comes to mind is always our internal classic example of how our vendor's T-SQL all-to-often arrives:

SELECT * from * JOIN * WHERE * = *

(At least it sure seems that way...)

Of course the statement isn't anything approaching valid code but it demonstrates the underlying point - without appropriate field lists, table lists, and filters (WHERE/ON clauses) your database can not be held responsible for what it returns to you...

What you ASK the database for is what you will get - even if it *isn't* what you really WANT.

For example:

SELECT Sales.CustID, Customers.CustomerName, SUM(Sales.Amount) as Total_Sales

FROM Customers

JOIN Sales

ON Customers.CustomerNumber = Sales.CustID

WHERE Sales.SalesDate BETWEEN '01/01/2011' and '01/02/2011'

GROUP BY Sales.CustID, Customers.CustomerName

Seems innocuous enough right?

What if CustomerNumber in the Customers table is a natural key (001-34F) and the CustID column in Sales is an identity integer?  Even if T-SQL is insidious enough to do the implicit conversion for you (which depending on the version it may or may not do), you aren't comparing apples to apples and if you do get any rows back they will almost certainly be faulty.  For recent versions of SQL you will usually get an error like:

Msg 245, Level 16, State 1, Line 1
Conversion failed when converting the nvarchar value '001-34F' to data type int.

Then there's the more extreme and dangerous example:

SELECT Sales.CustID, Customers.CustomerName, SUM(Sales.Amount) as Total_Sales

FROM Customers

JOIN Sales

ON Customers.CustID = Sales.SalesID

WHERE Sales.SalesDate BETWEEN '01/01/2011' and '01/02/2011'

GROUP BY Sales.CustID, Customers.CustomerName

Now what do you get?

CustID                     CustomerName            Total_Sales
1                               MoreStuff                     10.66
1                               StuffCo                         23.90
2                               StuffIt                           23.00

Cut to the CIO reviewing his morning reports: "Sales are a little down yesterday...hmm, I wonder why MoreStuff and StuffCo have the same Customer ID...wait a minute..."

Just because a query returns results does not mean they are valid, and JOIN's (and their minions WHERE and ON) have more potential to screw up your results than anything else if you don't treat them with respect and know your data - always use the appropriate JOIN (inner/left/right/etc.) for the data you are looking for and always make sure to filter with the appropriate join criteria - compare apples to apples.

I know this really seems like T-SQL 101 stuff, but it never ceases to amaze me how many stored procedures/views/SSRS reports I open up and find the underlying problem to be related to a bad join or faulty join criteria - so apparently it is worth mentioning!  {-: