THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Adam Machanic

Adam Machanic, Boston-based SQL Server developer, shares his experiences with programming, monitoring, and performance tuning SQL Server. And the occasional battle with the query optimizer.

Code Camps and Revisiting a Common Theme

Today I gave two talks at New England Code Camp 8. A fun experience as always, and for those of you who were in my talks and are looking for decks/code, please see this post and this post from when I did slightly different versions of the same talks earlier this year as MSDN Webcsts. I am not quite ready to publish the decks I used today.

But the topic of this post is not so much the code camp as an observation about what I saw there. Recent posts by both of our resident Andys (Kelly and Leonard) share the theme of organizations treating their database staff as next-to-worthless.  And developers, in general, seem much more interested in other facets of development than all of that "database stuff."

Today's code camp proved this once again; my two talks were both quite lightly attended, even though I was talking about important issues around data security and exception handling--things that any developer working with data should get. Perhaps it's just me, but the evidence says otherwise: after my talks I peeked into a few others and found a standing room only session on Silverlight and a session on LINQ to SQL that had a comparable number of attendees to what I'd had.

Why is it that data, while the foundation of any business application, is not a draw to the developer masses? How can we ignore the data and instead focus on creating spiffy new UIs (to display flawed data, no doubt)? Perhaps data seems easy--if you know how to write a query and set up an ADO.NET connection, that's all you need, right?  Or perhaps data is just someone else's job--just let the DBA or database developer handle it and display anything that comes back, flawed or not. It's not your problem, you're a UI developer. But everyone can't be a UI developer, can they?  Someone has to take control of the data.

Bad data can and does lead to project failure. If you're a UI developer you're going to get canned just as quickly as the DBA if you're project is no longer being funded--so if your UI displays bad data, you are just as guilty as whomever designed the database that returned it! If you're a business tier developer, you are just as responsible for data validation as the database developer! 

Alas, if you're reading this post you're already one of the converted. This is, so you obviously care enough about your data to read up on it a bit more. But as developers who know the value and importance of data, it is our job to spread the data gospel. Data issues around security, validation, and performance are every developer's responsibility.


Published Saturday, September 29, 2007 4:33 PM by Adam Machanic

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Tom Cooley said:

Hi Adam,

I was one of the relative few who attended your session today on Errors & Exception handling. Nicely done, btw. I consider myself more of a business tier developer than anything, but I've never developed a business application of any substance that did not rely upon a database. I agree with your observation. Interacting with a database is easy. Interacting with a database well is not as easy. I believe many developers take the subtleties of working properly with things like transactions and defensive coding in the database for granted. I wish I had an answer for how to change that, but all I can suggest is that we continue to try to put the word out. Thanks for doing your part.

September 29, 2007 6:22 PM

James Trela said:


     I attended your presentations at Code Camp 8. I was impressed with the complexity and design of the "sa" password you showed. To further this topic, here are links to :

Stored procedures (or functions) to find the sa password via brute-force or dictionary methods (note that the links to the code fail; perhaps the author can supply the stored procedures):

2002 paper on format of passwords in Microsoft SQL Server 2000, which are hashed and salted. The hash of the capitalized version of the password is stored, which simplifies a brute-force attack:

Wikipedia page on salting password hashes:

Wikipedia page on precomputed rainbow tables for reverse lookup of hash to yield input password:

RC4, Rijndael encryption in a Stored Procedure via call to ActiveX:

October 1, 2007 9:20 AM

Adam Machanic said:

Hi James,

Thanks for the comment and the links, but I wonder if you're thinking of something else?  Neither of my talks at the code camp dealt with passwords or hashing.

October 1, 2007 2:36 PM

James Trela said:


      You're absolutely correct, your talks at the code camp didn't deal with passwords or hashing. I was just impressed by the length and complexity of the password in your example - punctuation characters, 0 (zero) for letter o (if I recall correctly). Although you used mixed casing, this paper says it doesn't make a difference in at least SQL Server 2000:

   One way to improve password security is to use Unicode characters beyond the lower 256 (if SQL Server allows that). This complicates the search space for a brute force attack. This tip was given to me by Phil Motta of Chronos.

October 1, 2007 3:32 PM

Leave a Comment


About Adam Machanic

Adam Machanic is a Boston-based SQL Server developer, writer, and speaker. He focuses on large-scale data warehouse performance and development, and is author of the award-winning SQL Server monitoring stored procedure, sp_WhoIsActive. Adam has written for numerous web sites and magazines, including SQLblog, Simple Talk, Search SQL Server, SQL Server Professional, CoDe, and VSJ. He has also contributed to several books on SQL Server, including "SQL Server 2008 Internals" (Microsoft Press, 2009) and "Expert SQL Server 2005 Development" (Apress, 2007). Adam regularly speaks at conferences and training events on a variety of SQL Server topics. He is a Microsoft Most Valuable Professional (MVP) for SQL Server, a Microsoft Certified IT Professional (MCITP), and an alumnus of the INETA North American Speakers Bureau.

This Blog


Privacy Statement