Software Voices - Database development

Book Review: Joe Celko's Trees and Hierarchies

nospam@example.com (Glenn Crowe) — Thu, 25 May 2006 22:22:00 -0500

This is a book review of Joe Celko's book titled "Joe Celko's Trees and Hierarchies in SQL for Smarties" ISBN: 1558609202

Should you read this book? This, it seems to me, is the point a book review must inevitably resolve. Ill go ahead and kill the suspense by saying "yes." If you are involved with the development of SQL systems at any level and wish to read some productive material you can safely turn to this book. This isnt a perfect book by any means. It disappoints in some key ways. However, I am hard pressed to find fault enough to justify not recommending the book.

The Good News

Continue reading "Book Review: Joe Celko's Trees and Hierarchies"

Counting nodes in a tree: A bottom-up approach

nospam@example.com (Glenn Crowe) — Tue, 25 Apr 2006 23:43:00 -0500

A popular interview question for SQL Developers goes something like the following: Given an employee table where ManagerID is an attribute of the Employee record, write a stored procedure which counts the total number of employees which report to the passed employee.

For clarity I will point out that the organization is a tree where each employee represents a node.

There is a simple answer which you should probably stick to in the context of an interview. A top down approach (without the sproc wrapper) would look like this:



Create table #tEmployeeTree 

( EmployeeID int, ManagerID int, PassNumber int )



Declare @Pass int, @RowCount int, @EmpIDParam int

Select  @Pass = 1, @RowCount = 0, @EmpIDParam = 12

Insert #tEmployeeTree ( EmployeeID, ManagerID, PassNumber )

Select EmployeeID, ManagerID, @Pass 

  from HumanResources.Employee a

 where  ManagerID = @EmpIDParam



Select @RowCount = @@RowCount, @Pass = @Pass + 1



While ( @RowCount != 0 )

begin



    Insert #tEmployeeTree 

    ( EmployeeID, ManagerID, PassNumber )

    Select

          b.EmployeeID

         ,b.ManagerID

         ,@Pass

      from  #tEmployeeTree a

       join HumanResources.Employee b on a.EmployeeID = b.ManagerID

     where a.PassNumber = @Pass -1



    Select @RowCount = @@RowCount, @Pass = @Pass + 1

end

At this point you can be confident that the number of records in the #tEmployeeTree table represents the correct answer.

Now, there is an embellishment to this question which can lead to some interesting discussion. An executive would like to know which of his or her direct subordinates has the most number of employees in their organization.

Continue reading "Counting nodes in a tree: A bottom-up approach"

Passing n parameters to a Stored Procedure in a single call

nospam@example.com (Glenn Crowe) — Wed, 01 Mar 2006 00:03:00 -0600

Application developers have long lamented the seemingly delinquent support for passing an unbounded number of parameters to a SQL Server stored procedure. Such support has always existed, but the mechanism has never been entirely intuitive.

Observe a stored procedure defined thusly:

Create proc sp_AsManyAsYouLike as

set nocount on Select myInt * 1000 from #tempParam

go

Now I bring all of my Perl programming skills to bear:

$cmd->{ActiveConnection} = $conn;

$cmd->{CommandType} = 1;

$cmd->{CommandText} = "set nocount on Create table #tempParam (MyInt int)\n";

$cmd->{CommandText} = $cmd->{CommandText} . "Insert #tempParam Select 1\n";

$cmd->{CommandText} = $cmd->{CommandText} . "Insert #tempParam Select 2\n";

$cmd->{CommandText} = $cmd->{CommandText} . "Exec sp_AsManyAsYouLike";



$WScript->Echo($cmd->CommandText . "\n");

    

$RS = $cmd->Execute();



while(!$RS->EOF){

$WScript->Echo($RS->Fields(0)->value);

$RS->MoveNext;}

Which yeilds the following:

set nocount on Create table #tempParam (MyInt int)

Insert #tempParam Select 1

Insert #tempParam Select 2

Exec sp_AsManyAsYouLike



1000

2000

My example above is simplistic, but you can extend this model to pass all sorts of complex structures to a stored procedure. I don't offer this solution as a brilliant design. It is merely more palatable, and more flexible, than parsing strings with Transact SQL.

Code Review: OUTPUT parameters and transactions

nospam@example.com (Glenn Crowe) — Thu, 16 Feb 2006 23:47:03 -0600

File this one away for the next time you code review a SQL Server stored procedure. Those OUTPUT parameters arent bound to your transactions in any way.

Observe:



Create proc sp_OutputMyIdent (@myOutputIdent int output)

as

set nocount on

Begin transaction 

    Insert myIdentTable Select 'foo'

    Select @myOutputIdent = @@Identity

rollback transaction

go

Now a little ADO from JScript:



myCommand.CommandText = "sp_OutputMyIdent";

myCommand.CommandType = adCmdStoredProc;

myCommand.ActiveConnection = myConnection;        

myCommand.Parameters("@myOutputIdent") = 0;        

WScript.Echo("Before:  " + myCommand.Parameters("@myOutputIdent"));

myCommand.Execute();        

WScript.Echo("After:  " + myCommand.Parameters("@myOutputIdent"));

Which yields the following:



Before:  0

After:  1

Errors dont alter this behavior at all. Any reasonably competent scripting programmer can trap and then disregard your error.

Observe:



Create proc sp_OutputMyIdent (@myOutputIdent int output)

as

set nocount on

Begin transaction 

    Insert myIdentTable Select 'foo'

    Select @myLocalVar = @@Identity

    RaisError ( N'Uh Oh!', 16, 1 )

rollback transaction 

go



try

{

myCommand.CommandText = "sp_OutputMyIdent";

myCommand.CommandType = adCmdStoredProc;

myCommand.ActiveConnection = myConnection;        

myCommand.Parameters("@myOutputIdent") = 0;        

WScript.Echo("Before:  " + myCommand.Parameters("@myOutputIdent"));

myCommand.Execute();

}

catch(e){ WScript.Echo(e.description) }

WScript.Echo("After: " + myCommand.Parameters("@myOutputIdent"));

Which yields the following:



Before:  0

Uh Oh!

After:  2

The best thing to do is to keep your progress private until you know you are done:



Create proc sp_OutputMyIdent (@myOutputIdent int output)

as

set nocount on

Declare @myLocalVar int

Begin transaction 

    Insert myIdentTable Select 'foo'

    Select @myLocalVar = @@Identity

    RaisError ( N'Uh Oh!', 16, 1 )

commit transaction 

Select @myOutputIdent = @myLocalVar

go

Set XACT_Abort ON: Not quite the Panacea we thought it would be

nospam@example.com (Glenn Crowe) — Tue, 07 Feb 2006 01:40:00 -0600

So, you have stumbled across this SET option? Lemme guess. You've had some problems with locking or poor performance. Perhaps you just discovered some conditional logic in your stored procedures whereby BEGIN TRANSACTION, some error and COMMIT TRANSACTION don't flow quite the way you thought they would. What are your options? If you think XACT_ABORT is your salvation, read on.

At first glance, XACT_ABORT ON (it defaults to OFF) seems like the right answer:

It seems plausible. As soon as an error is encountered, roll back that transaction! Release those locks! Abort! Who better to implement this than the DBMS itself?

It's surgical. One call to sp_configure and all users will pick it up when they next create a connection. But wait, you only have a few users and they are all currently caching hundreds of connections on who knows how many web servers. Time for Plan B: alter all the sproc definitions to SET XACT_ABORT ON right at the top of the procedure definition. It's easy to script, and takes effect instantly.

Here is where I am going to go ahead and let you know that the XACT_ABORT setting is a little, well, misunderstood.

It doesn't always abort the transaction.

Observe:



Set XACT_ABORT On

Begin Transaction

RaisError ( N'Uh Oh!', 16, 1 )

If @@Error <> 0 

begin print 'My rollback' rollback transaction end

This yields the following:



Msg 50000, Level 16, State 1, Line 3

Uh Oh!

My rollback

As you can see, the transaction wasn't aborted at all. SQL Server seems to deem this scenario unworthy of the XACT_ABORT ON treatment. This is somewhat forgivable. After all, we hadn't changed any state or locked any resources. But it's only somewhat forgivable. If we didn't know the behavior and this was a business logic test that we were safely handling, we might not think it necessary to properly code the commit or rollback. But that's not the whole story. Let's actually do something transactional and see what we get.

Observe:



Set XACT_ABORT On

Begin Transaction

update dbo.TestXACT1 set mySmallInt = 0 where myInt = 1

print @@TranCount

RaisError ( N'Uh Oh!', 16, 1 )

If @@Error <> 0 

begin print @@TranCount print 'My rollback' rollback transaction end

This yields the following:



(1 row(s) affected)

1

Msg 50000, Level 16, State 1, Line 5

Uh Oh!

1

My rollback

Oh dear. What does this mean? We were transacting. There was an @@Error. But no transaction rollback occurred.

It does so much more than just rollback the transaction.

Lets go ahead and invoke a case where we can rest assured SQL Server will actually roll something back.

Observe:



Set XACT_ABORT On

Begin Transaction

update dbo.TestXACT1 set mySmallInt = 32768 -- clearly not small

 where myInt = 1

print @@TranCount

If @@Error <> 0 

begin 

    Print 'Couldn''t update that myInt 1' 

    RaisError ( N'Oh this is bad!  Alert the troops!', 16, 1 ) with log 

    rollback transaction

end

This yields the following:



Msg 220, Level 16, State 1, Line 3

Arithmetic overflow error for data type smallint, value = 32768.

I can assure you that the transaction is indeed gone. Terminated. Aborted. But then so is your code. It isn't just the transaction that this setting aborts. It's the entire batch. Wait, batch? As in???

Observe:



Create procedure sp_TestXACT1 as 

update dbo.TestXACT1 set mySmallInt = 32768 -- clearly not small

where myInt = 1

return -1

go



Set XACT_ABORT On

Begin Transaction

Declare @RetCode int

update dbo.TestXACT1 set mySmallInt = 0 

 where myInt = 1

print @@TranCount

Exec @RetCode = sp_TestXACT1

print @RetCode

If @RetCode <> 0 

begin 

    RaisError ( N'Badness happened when I called sp_TestXACT1!!', 16, 1 ) with log 

    rollback transaction

end

This yields the following:



(1 row(s) affected)

1

Msg 220, Level 16, State 1, Procedure sp_TestXACT1, Line 3

Arithmetic overflow error for data type smallint, value = 32768.

So yeah, the whole batch. From somewhere deep within the stack of sprocs which called other sprocs which called even more sprocs came the one line of code which ended consideration of all other lines of code. The XACT was ABORTed and a whole lot more.

So where does this leave us? In my mind XACT_ABORT has limited applications. Certainly spend some time looking over your code before you decide what is best for your situation. Robust error handling has always been hard, no matter what language you code. These are your transactions and you are far better equipped to deal with them than your vendor.

I tested the code above on SQL 2005. There is new TRY,CATCH functionality available which could change the arguments, but I haven't had time to review.

SQL Server sps without XACT_ABORT on considered harmful

nospam@example.com (Craig Ogg) — Fri, 07 Oct 2005 09:30:00 -0500

UPDATE: 1/31/2006 - This is not an issue if you are using the connection pooling built into MDAC v2.6 or later (see Glenn's comments on this post for details - Thanks Glenn!). This is still something you should be aware of if you are using your own connection pooling.

When you have a multi-step transaction in your stored procedures you are alway careful to check @@error and rollback if there is a problem. You think you're safe, and then one day disaster strikes: somehow random transactions were rolled back after they appeared to be commited (and after your application server returned the success results to client). The only clue you have is some database timeouts in your application server logs. What happened?

Continue reading "SQL Server sps without XACT_ABORT on considered harmful"