Solve problems where they exist, don't forward them...

I was fixing a bug in a web form that takes input from user in form of drop down lists that were put inside a table in the same row, each in a table cell.
The form required to work in both directions (RTL , LTR), according to some configurations. So if the user chooses to display the form in RTL, the alignment of the input controls must to change to "right" and so the direction should change to RTL, quite simple..

For some reason, the developer that added this functionality did adjust the alignment but did not adjust the direction of the table. This can make the user get confused because he expects the input sequence to be from right to left in case the form is right-aligned.

He solved this problem by changing the logic of reading and saving user input to reverse data in case of RTL. And problems started.

Being a relatively complex module, this change in logic caused other errors that were hard to trace. I solved this bug simply by removing any special handling to RTL case in application logic and changed the direction of the table that contains the drop down list to RTL. This solved the problem and made the code clearer.

I'm fond of thinking about and studying the real causes of bugs and issues. One of them is what the fellow developer did...
The RTL behavior is clearly a UI function. Supporting this functionality should not go to other layers or places in the code.

A new lesson I must remember:

Solve problems where they exist, don't forward them...

Should I say whenever possible?

Tips for your next major deployment

Deployment is one of the most annoying steps in the software production process especially for developers. I hate it. A small missing configuration or permission can cause severe problems. worse can happen when applying a fix or an update.
I believe that software developers should not make the actual deployment. Software Implementors or system engineers are better at configuring things ;)

Here, I share some good points that can help making a peaceful deployment experience . Most of them apply mainly to web applications.

1. Write a good deployment guide and test it before you deploy on production
   
2. Create a brief yet complete check list.
3. Peer check your deployment: another implementor or developer should review the steps you made.
   
4. Automate the process of deployment as much as you can.
5. If you deploy on a production environment, backup live data and configurations. You should also take the application offline.
   
6. Use staging environments with the same configurations as the production servers.
7. Test your deployment.

sp_MS_marksystemobject - When an undocumented stored procedure helped me

During a maintenance of a system that used merge replication, I dropped and recreated the MSmerge_tombstone table which is used by replication.

After a period, the client sent me an email asking me if he can safely drop this table as he did not find it relevant to his data.
this was because the he used to hide system objects shown in SQL Server 2000 Enterprise manager. And when I recreated the table it was not marked as system.

I tried to discover where does SQL Server save the "system" property in system tables, but I've got no clear results.

After a search I found an undocumented stored procedure "sp_MS_marksystemobject" that did the work.
It uses some bit manipulation to the status field in sysobjects table to mark an object as "system"... Something you can't discover by luck.

The syntax for using it is :
sp_MS_marksystemobject 'object_name'

You can use sp_helptext sp_MS_marksystemobject to check the code.

MDC 2007 Prize!!

The closing session in MDC2007 was all about fun, there were many prizes and I've got one for being an MDC fan (I had 3 MDC registration cards)
The prize was a Microsoft wireless mouse and keyboard with finger print recognition.
I did not try it yet and I'll need to stick Arabic letters on the keyboard.
Another winner won a good mobile device (iMate I think) for having 4 cards.
I ask myself, why did I get rid of the 2005 card while I kept 2004 and 2006 cards?
Anyway, It's good to get something for free :)

SQL Server cursors are not always evil !!

In her blog post, Robyn Page reopened a discussion that took place many times. She provided a problem (calculating a running total) as a proof that in some cases using cursors can give better performance than using other T-SQL techniques, as (sub queries-joins etc.)
The claim that T-SQL cursors are bad and to be avoided by any means is well advocated for, and many developers assume that whatever a solution they come to using set-based statements is necessarily better than using cursors.
In this SQLTeam article the writer intended to use the same problem (calculating a running total) as a proof, but surprisingly he found that the results of using cursors were better.

So what is the bottom line? When are cursors good and when are they bad?

We can generalize the result of the above mentioned tests and say that, in general, operations that needs sequential processing are cases where we should consider using cursors.

I also faced a situation about 2 years ago when I needed to provide paging to query results, which required jumping to a specific recored in a result set. I applied a technique using dynamic cursors and it worked great even with thousands of records and . Later I found a codeproject article that proves this method to be recommended to a great extent, another case that cursors proved to be useful.

I'm not trying to count the cases when cursors are good. I just don't like taking assumptions for granted. But I tried to give some cases where it's a good idea to use try different techniques including cursors and judge by yourself.