It’s always amazing to go back and look at code that you wrote just over a year ago. As I’m sure it common with most people, I was surprised, and a little embarassed, at how bad some of my code was back then. It’s amazing how much you learn and grow in a year, especially when your as relatively new to the industry as I am. So let me show you what I found that made me reflect on the last year.

I knew a DBA once that had “The Routine” and they stuck to it every single morning. (I laugh a bit every time I say, “The Routine” while thinking of this DBA). The DBA actually named the steps that were to be done every morning as, The Routine. Each step from the laptop plugging into the docking station, to opening QA before opening EM was in a specific order and never deviated from.

So I’ve been working on cleaning up the security for my SQL Servers the last few months. The brunt of the work has been documenting what’s currently in place, what needs to go away immediately, and the long term overall plan. In this whole mess I’ve learned a few things, and I’ve set some new standards at work (where there weren’t any before). These standards, however, are always open for improvement, which is very nice because once I learn something useful I can start using it.

This version of SQLCop contains several bug fixes as well as some new features. Many of the items changed in this version were based on feedback received by you, our users. We encourage people to post comments so that we can improve the application. If you previously downloaded the original version of SQLCop, you should manually download and install this new version: http://sqlcop.lessthandot.com/ Fixes: This version of SQL Cop works with databases that have a binary collation.

There are hundreds if not thousands of T-SQL Scripts, Powershell Cmdlets, .NET programs and even old vbscript scripts out there to monitor SQL Server and Operating System level performance. I’ve written hundreds of them myself over the years. Without a doubt, all of that time and work absolutely paid off. It helped me learn even more about monitoring the right things and going after the right information when something specific is wrong.

So this is my 300th post on lessthandot, I decided to make this a post about why I am blogging and why you should too. There are a couple of things that are beneficial for developers who blog, these are You will write better code and research more You will discover new blogs and interact with your peers You will have a code library online Your blog will be part of your business card Let’s take a look at these 4 items listed above.

SQL Trace (and use of profiler as a front end to SQL Trace procedures) is far from a secret. Performance tuning in the days of 2005⁄2008 has become much easier with the advent of DMVs but SQL Trace still has its place in the realm of, “Why is this happening”. Performance tuning becomes almost easy while watching exactly what is going on with the batches hitting our database servers. The only downfall is the impact SQL Trace plays on an active database server.

So far, we showed how to manipulate connections so we can freely move packages from server to server without the need to open them in BIDS and change connections. This allows us to manage packages easily, not only from a development stand point, but allows for teams to pass along our packages and then move them without being required to either open them or have BIDS to change these critical connections.

Every task that is out there to enable SSIS to be more, ‘dynamic’, ensures that we can develop reusable and more manageable solutions. Variables and configuration files along with package configurations are all part in allowing packages to become dynamic in this way. You may be thinking right now that it would be cool to have something like a date variable so you could use it in an Execute SQL Statement or such.

The last time I did a post on NHibernate (or any post for that matter – I guess I’ve been a bit busy) Ben asked a question about what I ended up using for session management in the application I’ve been working on. I guess I could come out and answer it, but I’d hardly get a new post out of that. Instead I will break out the tried and true answer for all things IT, “It depends”.