I'm currently having to get 'into' SQL server at work. I come from an Oracle background, but hey, how different can they be, right? Well... you'd be surprised.<br /><br />One of the nice things about Oracle is PL/SQL. In my last job I wrote a lot of PL/SQL... it's easy, quick to do, well documented, and allows good software engineering. SQL Server uses something called 't-SQL' and compared to PL/SQL, it's appalling. The best way of demonstrating this is with an example. In stored procedures I can do this in PL/SQL:<br /><br /><pre><br />PROCEDURE MyProcedure<br />    errorCode        OUT NUMBER,<br />    errorText        OUT VARCHAR2,<br />    someItemID    IN     ITEM.ITEMID%TYPE,<br />    someNumber    IN     ITEM.ITEMNUMBER%TYPE,<br />    somethingElse IN OUT NUMBER,<br />    result           OUT RESULTTABLE.RESULT%TYPE) IS<br /></pre><br /><br />This can be part of a package defined as two files - a spec and a body. All good software engineering.<br /><br />With MS SQL Server I simply can't so this. As far as I know, there are no packages with specs and bodies, for one thing. There are weird, implicit returns for selects, variables defined within the procedure, and other strange and wacky stuff that really works against every good software engineering principle. Also, a roughly equivalent header might look like this:<br /><br /><pre><br />CREATE PROCEDURE [dbo].[MyProcedure]<br />    @errorCode     INT OUT,<br />    @errorText     VARCHAR(1024) OUT,<br />    @someItemID    INT,<br />    @someNumber    INT,<br />    @somethingElse INT OUT,<br />    @result        INT OUT AS<br /></pre><br /><br />The biggest problem is that you can't get the type from the columns of a table, so if the table changed you have to change all of your code. This is insane! Large applications may have thousands of stored procedures, all of which would have to be changed. The lack of packages (although as I say, I might be wrong there) mean that you can't logically group procedures either, and you lose some context that you get in Oracle just from the package name.<br /><br />As I mentioned, the way stored procedures seem to work in SQL Server is by implicit returns. For example, say we have this line:<br /><br /><pre><br />  declare @intReturnCode int<br /></pre><br /><br />We can then add a 'return @intReturnCode' later and return a value not even defined in the header. Worse, you can do something like this:<br /><br /><pre><br />  set @someValue = (select fieldValue from someTable where name = 'this')<br /></pre><br /><br />So looking at the parameters you'd have no idea that you were going to get 'someValue' back, or what type it is. Madness, absolute madness.<br /><br />I must admit I was wary of SQL Server, but the more I look at it the more I'm amazed that anyone actually uses it. I mean, they only added exception handling in 2005! It's like some sort of toy database, but with a fairly hefty price tag.<br /><br />Anyway, feel free to correct me. In the meantime I will continue to think poorly of it..