Dude where’s my byte?


I’ve encountered a very interesting problem today, the mystery of the missing byte. It all began when one of tests starting failing on my development machine after I got latest from repository. The problem revolves around saving a checksum (byte array) to a varbinary column on SQL Server 2005. The checksum that was generated in code (which is unique for each machine) has a trailing byte of zero in the byte array, and after being saved to SQL Server, the zero byte is missing!!!!!

It was doing my head in, I went through the code and database creation scripts, and finally managed to find the problem. Apparently in the database scripts, there was a line ‘SET ANSI_PADDING OFF‘. This tells SQL Server to truncate off trailing zeros for varbinary and trailing spaces for varchar types. This setting takes into effect during table creation, so whatever you specified stays in effect after. In order to change “setting” for that table, you have to drop the table and re-create it with new setting, like so..

DROP TABLE T1;

SET ANSI_PADDING ON;
GO

CREATE TABLE Table1
-- and so on

SET ANSI_PADDING OFF;
GO

MSDN has recommended that you leave the setting to ON, and for very good reason. I doubt you would want things to auto-magically disappear or be modified without your knowledge, but should be should be made explicit and known. It would have saved me hours of troubleshooting, and I hope it will save hours for you too! Please see the ANSI_PADDING MSDN page for more info.

Share this post :
Advertisements

Strategy and Decorator Pattern


It’s been a long time since I posted anything, been very busy with work. Many things have changed and I am currently working as an independent contractor.  My latest gig at the moment is working on a WPF product! 🙂 woo hoo!

Today I’m going to talk about using the Strategy and Decorator Pattern together, as it turns out they work pretty well together. Strategy pattern is a good way to encapsulate your algorithms, or in my case I want to use it to encapsulate reusable code, following the principle to keep it DRY. With the introduction of Action and Func classes in .NET framework, I have found that writing callbacks to be so much more accessible. For instance, you may sometimes need to repeat lots of Try…Catch statements in your code, and find that hard to keep DRY. This is where using callbacks are useful, like so…

Read the rest of this entry »