Monday, June 05, 2006

nullable C# SQL gotcha's

I've been looking forward to redesigning our code to use the new nullable value types in C# 2.0 since we made the switch. The types themselves are not a disappointment, but they don't work as well with SQL Server as one would expect. Hard to believe Microsoft didn't think about the large developer community that would be using this with SQL Server 2000/2005.

Two really subtle "gotcha" things I ran into I thought I’d pass along. (int?)row[“field”] This does not evaluate to null when the field is null. It throws an exception. int? fieldValue = null;params.Add(“@Field”, SqlDbType.Int).Value = fieldValue; This does not call stored process with @Field = null when calling SQL Server, it calls stored procs with @Field = default.
My coworker (Bill Ziss) says "This is a major detraction to nullable types' usefulness. This would've been THE major use of nullable types, imo." I tend to agree.

Almost equally annoying (but far more obvious) is the SqlTypes used a property called IsNull and nullable types use a property called HasValue. This means if I convert my code, I have to change all the !o.IsNull to o.HasValue and o.IsNull to !o.HasValue. This makes it way to easy to forget to change an ! and introduce bugs, especially when changing this in 10,000+ lines of code. With as many people already using the SqlDbTypes (even for nullable value types in non-SQL related code) why would they change this?

Overall, I think I am still going to use the new nullable types, rather than keep using the SqlTypes. Having to use a SqlType for a variable not being passed to Sql Server seems silly, and I really don't like having to mix/match both.

I am very disappointed by the lack of support for nullable types in XML datasets in .NET, but after using them in a real project, I have decided they are still too immature for production anyway. They aren't unusable, but they are so unstable that there is no net gain of time developing software. Take a look at my post about FDBK49338 on Microsoft's Product Feedback page ( The XSD editor is just plain buggy - I cannot believe this could even make it into BETA 1, let alone 3 betas and released software. They should have left it as is (it was almost as useless in 2003, but less buggy).

Friday, June 02, 2006

Enterprise Mismanager

I hate hearing programmers complain about developer tools being hard to use - developers should be required to have more intelligence than average users, and in general should trade simple interfaces and well tested software for more complicated, powerful and cutting edge tools. I am posting this, since it is a screen many developers use every day, and hopefully calling attention to this might stop development of similarly bad software in the future.

However restoring databases in SQL Server 2000 Enterprise Manager features one of the worst GUI designs I have seen in a widely accepted product. You have to enter a name for your database on the first tab, and a filename for the data and log on another tab. This is ok, except which tab you are on and which tabs you have visited before effects which file name SQL Server uses.

I am not entirely sure how this works, but I think by default, SQL Server uses the database name as the file name, but it only updates this when you click the 2nd tab. So if you change the name of your database and never click the 2nd tab, it uses the old name. If you click the 2nd tab (and don't do anything else) it uses the new name. If you go to the 2nd tab first and then change the name on the first tab, it uses the old name.

Switching tabs is an operation that should be exclusively read only - this is ridiculous. Did a professional programmer do this on purpose?

The rest of Enterprise Manager is almost as unergonomical - was this designed for 640x480? Why can't I change the size of the fonts or even size the windows?

I have used 2005, but not enough to know if it is really better, or just has different quirks I haven't found yet. Hopefully by the time I am using 2005 more than I use 2000 this silliness will end.


The problem with coffee is you cannot even pour a cup without spilling until you've had a cup to drink.

Thursday, June 01, 2006

I have a blog

I finally have a blog. Only time will tell if this is a useful journal of programming issues or a tremendous waste of time. More likely, no one will actually read it, and I will stop posting.