Monday, July 13, 2009

Breaking backward compatibility - oh, please!

Most of our SQL Server applications are developed in a way so that they work with any version of the SQL Sever. However users are encouraged to use SQL Sever 2005 just because this particular version has been thoroughly tested.

As one can expect, few users install and use SQL Sever 2008 and usually they do not observe any major issues.

At least not until yesterday.

It turns out that one of our scripts, intended to allow users to select a SQL Server account and assign it to a employee row in a employee table, is based on sp_helpuser stored procedure.

And guess what? Someone from Microsoft has decided to change the names of columns returned by sp_helpuser!

The change is described here

http://msdn.microsoft.com/en-us/library/ms143179.aspx

among few other much more subtle changes.

Does the rename clears up any confusion or introduces a new value to the procedure results?

No!

It's just "GroupName" has been renamed to "RoleName" and three other columns named with "group..." have been renamed to "role...".

Does such change breaks your scripts?

YES!

It's just beautiful BOOM and the application does not work as expected!

I've been talking to few developers from Microsoft and what they always emphasise very firmly is that the backward compatibility for the client-code written by us, developers, is very, very important for them. They are not allowed to just rename "CreateWindow" to "CreateNewWindow" or "sp_helpuser" to "sp_userdata" just because thousands of people probably use previously released artifacts in their own code.

Apparently, this time someone has decided that there are really some lifetime reasons which would consider RoleName more correct that GroupName so that breaking the backward compatibility is somehow justified.

I really, really wonder what these reasons would be....

2 comments:

Biegam i tyle said...

This is nothing comparing to some changes where MS adds some new columns and you perform some INSERT INTO ... EXEC ... statements in your T-SQL code. That hurts even more cause you're getting errors from SQL Server, not from your application :-)

Anonymous said...

conceptual changes... doesn't actually change anything, but bloody hurts... ;)