Sep 252012

More often than not, I’ll expand the “Tables” folder in SQL Server Management Studio and browse the list to find whatever table or index I’m looking for. This works well in many situations, but when your database has over 20,000 tables, the results can be overwhelming! As your databases get larger and more complex, you may find yourself making use of features you previously didn’t need. For me, one of said features is filtering in SSMS object explorer.

Filters to the rescue
SSMS lets you create filters on certain parts of the object tree so you can see only what you’re interested in. In the case of tables, you can right-click on the “Tables” folder, choose Filter > Filter Settings, and then filter tables by Name, Schema, Owner, or Creation Date. In the images below you’ll see I’m filtering to only display tables whose schema name contains “Production”. To remove a filter, right-click on “Tables” again and go to Filter > Remove Filter.

Filters, filters, …everywhere??
Filtering can be helpful when you’re interested in looking at only a subset of tables or other objects, and they’re especially helpful when you’re working on systems with a huge number of objects and don’t want to scroll through an extremely long list. But unfortunately you can’t use them everywhere in the Object Explorer tree. I’ve never understood why – filtering is something simple enough for the client to handle. In the case of the example above, you can use SQL Server Profiler to see that filtering is done on the server, but I see little reason why it couldn’t take place on the client as well.

I went through the whole tree in SSMS 2008 and found that the following objects that can be filtered:

Database Level

– Database Diagrams

– Tables (and system tables)

– Views (and system views)

– Stored Procedures (and system stored procedures)

– Functions (Table-valued, Scalar-valued, Aggregate)

– Security (Users, Database Audit Specifications)

Server Level

– Security (Logins, Audits, Server Audit Specifications)

– Management (Policies, System Policies, Conditions, System Conditions)

– SQL Server Agent (Jobs)

It’s great that you can filter on all these things, but I think there’s a few more that should be filterable and aren’t, such as roles, schemas and types. I have a database with over 150 roles and 200 schemas – browsing those lists is a pain! I also got a chuckle when I found that database diagrams can be filtered. To me, that’s a seldom-used feature that totally doesn’t belong at the top of the tree (where I always click on it by accident) and then MS made it filterable for extra irony.

No filtering by role…

What about SSMS 2012? I didn’t go quite as in-depth as 2008, but it looks like everything is the same with respect to what can and cannot be filtered.

Like this idea?
If you think this makes sense, consider voting for this suggestion I just posted on MS Connect.

Sep 132012

In my previous post I mentioned that we currently have a few positions open on my team. I got some emails inquiring about them so I thought I’d explain a little more.

Where do you work?
I work for the Northwestern Medical Enterprise Data Warehouse. We’re a part of Northwestern University, and we’re charged with storing and making available for research purposes all the medical data generated by Northwestern Memorial Hospital, the Northwestern Medical Faculty Foundation, and the Northwestern University Feinberg School of Medicine. We’re an all-Microsoft shop currently storing over 20TB of data in SQL Server and growing.

What positions are open?
We have 2 positions open at the moment: Data Architect and Database Administrator.

Data Architects are responsible for designing our schema structure. They also design and maintain the SSIS processes that are responsible for loading data from source systems into the EDW.

The Database Administrator will be working with me, and will be focusing on the DBA needs of one of our campus partners, the Northwestern Medical Faculty Foundation.

For full details, check out the official postings for Data Architect and Database Administrator.

Where are these positions located?
We’re located at Northwestern University’s Chicago Campus.

Can I work remotely from somewhere else?
Sorry, not at this time.

What’s the team like?
Our team is awesome! We have a great group of people with some diverse backgrounds, but we’re all really passionate about data. We take our work very seriously, but have a great time while doing it.

How do I apply?
If you have questions or are interested in either position, email us at

Sep 102012

In our formative years we’re taught again and again that one should never judge a book by it’s cover, but when seeking employment that all goes out the window when you create a sheet of paper so that potential employers can judge you by it. Ironic, eh? That’s life, so  make sure your résumé represents you in the best possible light. That way you can maximize your chance of avoiding the trash can when HR spends a paltry 6 seconds deciding if you’re worth a phone screen.

My team has a bunch of open positions, which means we’ve been looking at lots of résumés. A few are great, some are good, and sadly, most fall under the category of “meh”. As we go through more and more of them I’ve come up with a list of things that I really don’t want to see on a résumé. Here they are in no particular order:

Ok, this is the easy one. The purpose of a résumé is to give a very quick impression of your skills and background to potential employers –  any type of error, grammatical, innocent, or otherwise, will make you look sloppy at best. You should be proofreading your résumé regularly, and when you’re tired of proofreading, do it again. Let others have a look at it as well because a fresh set of eyes can do a document wonders. No matter how good your qualifications look, saying that you’re proficient on a “Macingosh” computer or have experience with “Windows 2007” will tell a very different story.

Unprofessional Email Addresses
An otherwise spotless résumé might not look quite as good if you tell an employer you can be reached at There’s lots of ways to get free email addresses, so take 5 minutes and create one that’s based on your name.

Calling Yourself An Expert
I’ve seen 2 résumés now where “expert” was the first word on the page after the name. In phone interviews, both of these people couldn’t answer simple questions like naming the system databases. I feel very fortunate to know several legitimate SQL Server experts, but I don’t think any of them would use that word when describing themselves.

This one is huge. I’ll take it one step farther and say don’t put anything on your résumé that could be remotely considered as misrepresenting yourself. The second that a potential employer starts to think you’re saying something that isn’t completely true, your chances of getting the job go out the window. Why take a chance on someone who might be lying when there’s a whole stack of résumés of people who probably aren’t? Even if you somehow get the job, it could come back to haunt you later.

Irrelevant Information
I’m not sure it’s necessary to write a completely custom résumé for every job you apply for, but it’s a good idea to remove things that aren’t really relevant to the position. For example, if you’re applying for a DBA role, the fact that you were a cheerleader in high school probably isn’t going to help you. Remember that HR or whoever is reading your résumé will want to want to find potential hires very quickly. The more noise they have to read through, the less appealing you’ll be.

Being Too Verbose
A résumé should only be long enough to prove you’re qualified for the position you’re interested in. For most people, this is probably 1 to 2 pages.  I can see it being longer if there’s good reason, perhaps if you’re a consultant with a wide variety of relevant experience, otherwise keep it short. I’ve seen quite a few that are much longer than they should be, such as 10 or more pages. I actually got one that was 16 pages not too long ago. Listing your entire employment history and every project you were a part of isn’t necessary. If you’re applying to be a .Net Developer, the fact that you did assembly programming on a mainframe in the early 1980’s might be a good anecdote to bring up during the interview, but doesn’t warrant real estate on your résumé.

Using Crazy File Formats
I keep my résumé in 2 formats: a plain text file, and Microsoft Word. Whenever possible I try to submit PDF files made from the Word document. I think PDFs are the best way to ensure your résumé looks the way you intended it to, no matter who’s reading it. Even if you don’t want to fork over the cash for Adobe Acrobat Pro, there’s a bunch of free PDF generation tools out there that can also do a great job. As for the text file, I keep that around for times when HR websites won’t allow uploads and instead require that I cut and paste my résumé into a web form. Having everything ready to go in a text document makes this much easier.

Bonus Tip: If possible, try to embed your fonts in the PDF file. (Acrobat calls this “Press Quality”). This way, whatever fonts you use are in the file so it’s sure to look exactly the same on whatever computer is reading it. Otherwise if the font you’ve chosen isn’t installed on the computer that’s reading it, the PDF reader application will will substitute whatever it can. No matter what, try to stick with a common and professional-looking font. Comic Sans won’t do you any favors!

Using Paragraph Form
I had never heard of this before and there’s a good reason for that – it’s terrible! There wasn’t a single bullet point on the entire résumé. It read like a book and was 3 pages of solid text. Again, HR or whoever is reviewing résumés is going to want to find things quickly – they aren’t going to waste their time reading this.