This editorial was originally published on Sept 12, 2006.

How'd you like to be the DBA for a system that mistakenly gives out $318 million? It probably wasn't the database, but more likely the code for some application that caused this to occur in the IRS system, but it's something that becomes more likely in SQL Server all the time.

SQL Server 2005 is the first time that SQL Server can be easily used as a complete application development platform. With the addition of the CLR, the Service Broker, Database Mail, web services, and more, SQL Server 2005 could be your database server, application server, and only server, with no other software running.

While application developers will likely write most of the code, including lots of the CLR functions, procedures, and other constructs, who do you think will be responsible for the system? That's right, the DBA. You'll be the first and last line of defense and the one that will likely shoulder a lot of the blame for issues. Fair or not, I expect that DBAs will become more likely the scapegoats for issues.

This means that as a DBA, you really want to beef up your skills as well as clearly delineate lines of responsibility. You should be able to read the code behind assemblies you add to your server, as well as understand how the SQL Server subsystems fit into an application. But you also need to be sure that you let management know when you are overloaded, when you can't review code, or when you are concerned about possible issues with code.

I've felt for years that it was a matter of time before some computer professionals will need to become bonded because of their responsibilities. I'm not sure when or where this will start happening, but I wouldn't be surprised if it starts with DBAs.