SQL Server has a special extended stored procedure called xp_cmdshell. This procedure has a lot of power: it allows to execute any command line code on the machine hosting the SQL Server.

Imagine you want to list all the files on C: on the SQL Server Windows host: you could write a T-SQL statement like this one:

EXECUTE master..xp_cmdshell 'dir c:'

This stored procedure, however, is a very dangerous one, as it would allow to execute harmful code. This is the reason why it's disabled by default. Even when enabled, only users on the sysadmin role can use it.

If you ever need some users the ability to run only some specific commands with xp_cmdshell, you can use the method I'll explain below, making use of the EXECUTE AS modifier of the stored procedure definitions in T-SQL.

This morning I was working on a project at work. It's a Web Application using the ASP .NET 2.0 framework and C# as a code behind language. My friend Ioannis came over to see what was I doing and when he saw I was appending some strings together he asked me this question: "are you using a StringBuilder to use those strings?". And I replied with this answer: "no, I am not". This kind of stupid dialog came over because last week we were discussing about using StringBuilders instead of the default String class operators to append strings each other in Java. It seemed using the StringBuilder class resulted in an overall performance gain. It was then when I asked: "don't tell me this happens with C#, too?". And he answered: "yes, it does!".

So, what's the matter with StringBuilders in C#?

This week we had a bug report of one of our products regarding some strange deadlocks in our database access. For those of you who don't know what a deadlock is, I'll try to summarize here what a transaction is in a relational database environment and why those transactions might lead to those nasty errors, and try to explain what was causing this deadlock in our SQL Server 2005 engine.

Well, this is my first post after holidays and it won't be very long.

Imagine you are developing a rails application. Usually you have:

• a terminal with the server to see what petitions are received.
• a terminal with a tail of development.log to see what happens with the database.
• a terminal with a tail of test.log if you are testing something.

This are a lot of windows... And the other day one friends was very happy and after asking for a while I discovered that the reason was the simple line showed above... With only one Ctrl+C you can kill all this processes :-)

script/server & tail -f log/development.log & tail -f log/test.log & tail -f ; jobs -p | awk '{print "kill -2 " $0}' | sh

One of the deficiencies of actual programming languages, specially those ones still widely used that are old, such as C or C++, is that they were designed having in mind the sequential programming paradigm. This usually means that those languages don't have standard ways to work with multithreading features, and you usually have to rely on third party libraries to develop thread safe software.

Today I'll be discussing a design pattern called Double Check, which can be widely used to manage the resource access, elimination and initialization in a safe thread way.