Category Archives: Misc

The simplicity of nullable types

I just discovered nullable types. Wow! They are really simple and such a powerful feature. Just see for yourself….

If you have an int or a DateTime or any other value type you’ll already know that you cannot assign null to them. But in C#2.0 you can.

You can define a nullable int by adding a question mark to the end of the type like this:

int? a = null;

However, you’ll want the new code to operate with old code which hasn’t yet been upgraded to use nullable types, so there is a new binary operator to help. The ?? (I’ve no idea how your meant to pronounce that. I just say “Double question mark”)

So, if you want to assign a (above) to a regular int you can do the following:

int b = a ?? -1;

If a is non-null then b is assigned the same value as a. If a is null then b is assigned the value on the right side of the ??. So, just like the old days where you’d make up a value to represent null for an integer (I normally used int.MinValue)

NOTE: This was rescued from the google cache. The original date was Friday, 9th June, 2006.

Tags:

SQL Injection Attacks and executing dynamically created SQL

There is a very important difference between EXEC[UTE] and sp_executesql that anyone who executes dynamically generated SQL statements ought to know.

Typically dynamic SQL is generated when a particular construct is not possible by using parameters alone or when certain parts are added to the statement depending on other conditions. In the latter case, sp_executesql trumps EXEC[UTE] by allowing the developer the ability to pass in parameters to the dynamic SQL statement.

For example, consider this code:

SELECT *
FROM MyTable
WHERE a = @wantedA
AND b = @wantedB

If you were dynamically building this and were using EXEC then the code to dynamically build and execute it might look like this:

DECLARE @sql NVARCHAR(4000);
SET @sql = N'SELECT * FROM MyTable '+
           N'WHERE a = '''+@wantedA+N''' AND b = '''+@wantedB+N'''';
EXEC(@sql)

As you can probably guess, without extreme care as to the values of @wantedA and @wantedB an SQL Injection Attack is possible. However, it is possible to dynamically create the SQL statement and still use parameters within it like this:

SET @sql = N'SELECT * FROM MyTable '+
           N'WHERE a = @dynWantedA AND b = @dynWantedB';
sp_executesql @sql, N'@dynWantedA varchar(100), @dynWantedB varchar(100)',
              @dynWantedA = @wantedA, @dynWantedB = @wantedB;

As you can see in the second example, instead of injecting the value of the parameters we can just write parameters directly into the dynamic SQL statement and then pass them in.

There is, of course, caution to be exercised. Certain things cannot take parameters. For example, in SQL Server 2000 the TOP keyword must be followed by a literal value. It isn’t possible to write TOP @numRows* so if that must be dynamic then the value would have to be injected into the SQL statement like this:

SET @sql = 'SELECT TOP '+CAST(@numRows AS varchar(10))+' * FROM MyTable';

So, using sp_executesql is not a panacea that will make all issues with SQL injection go away when building dynamic SQL, but it does help in certain cases.

* This is possible in SQL Server 2005, but not SQL Server 2000

NOTE: This was rescued from the Google Cache: The original date was Thursday, 26th January, 2006.

The Google Cache is now failing on me

The google cache is slowly being replaced by the contents of a parking page that has replaced the original site. So, this archive of my old posts is going to get a little sporadic.

The wayback machine does have some record of pages from 2004 to January 2006 so hopefully it will only be a few months of missing information.

 

Why make fields in a class private, why not just make them public?

A recent question came up on forum about encapsulation. I guess it is something that I don’t really think about any more as it comes naturally but it reminded me of how some of these concepts took a while to take hold when I was first taught them in university.

Encapsulation is sometimes also known as information hiding. The idea is that an object hides the details of how it works from the outside world. However, some definitions of encapsulation suggest that it is just putting the data and the methods that operate on that data together in one class (the capsule).

The question asked was why make fields in a class private, why not just make them public?

I now find very idea of making a field public incredulous. However, if I stretch my mind back about 10+ years or so I can vaguely remember asking similar questions and thinking how crazy it was making member variables private and having to access them through special functions. It isn’t crazy at all.

So, what do you get from hiding fields behind the private or protected accessor?

The primary advantage is that it hides the internals of the class and shifts the dependency onto a well defined interface. By interface I mean a public method or property on the class rather than having the class inherit from an interface. Code that accesses the class will call on the public methods and properties and need know nothing about what is happening inside the class. This leaves great scope for future implementations of the class to vary what happens internally while maintaining the same external interface. Code that uses the class will then continue to operate without being modified. Put simply – It is a form of protection from future unknowns.

For example, say that a class represents an alarm clock which allows two separate alarms to be set. Internally, those alarms are represented as two separate fields. When the client code accesses the alarm clock class it uses a set of public methods and properties. This allows at at some point in the future the internal storage of the alarm times to be changed to use an array rather than two separate field instances. If the fields were public a lot of code outside the class may have to be updated also to accommodate the new structure of the class.

Even if there is not going to be any internal change to the class, the use of methods and properties to access the fields can provide other advantages.

For example, you might decide later that it would be better to leave the field uninitialised and then have your property initialise it when it is first used. This is called a lazy-lookup. If the field value can be constructed from the information the class already holds, but it is an expensive operation to do so, and the usage patterns show that the value is not often needed then why create it needlessly? So, the property checks the field, if the field is null it creates the value and stores it in the field and returns the new value. If the field already contains a value then it is the cached value that is returned.

Alternatively, you discover some time in the future that when you set the property that you need to carry out some other action (an analogy would be like a trigger in the database). So, since you have a property already, you can now put the extra functionality in without having to completely break your application.

Another example being that validation could be taken before the field is updated with the new value. This keeps the object in a consistent state. If you just exposed the field you would never know if some other object set the field to an invalid value and this is a potential source of bugs, especially the nasty sort that rear their head further on past the point that the bug was actually introduced. These are a real pain to track down and anyone having to maintain your code will not thank you for allowing that into the system.

An interesting advantage to using public properties backing private fields is that the developer can set breakpoints on the properties but not on the fields. That is very useful for debugging the application. Debugging trace statements can also be placed there

Finally, if a property is a simple field backer it can also be used to provide a read- or write- only access to the fields. This is particularly useful if the object is to be immutable, that is, it doesn’t change once created.

NOTE: This post was rescued from the Google Cache. The original date was Monday, 28th November 2005.

Tags:

Some of the original comments:

I had this very debate at my place of work several times myself – obviously, as a hopefully good developer, I always argued *for* encapsulation of fields (I’ve taken to making that a key point on any code reviews I do now) – in particular things like access to ViewState and Session objects in ASP.NET.

OK, so I’ve done it myself occasionally too, but nobody is perfect 😀

The nice thing about using C# is you can make use of properties to retro-fit in such an interface later on if you really have to without *too* much pain.

(Yeah, I’ll just go into the cowboy developer corner now….)

11/29/2005 12:45 AM | Ian D

Another important reason is DataBinding. DataBinding relies on events name xxxChanged, where xxx is the property name. If you access the field directly, you won’t be able to take advantage of events firing on value changes, and this in turn means DataBinding will break.

11/29/2005 1:22 PM | Marc

To clarify Marc’s point, data binding will not actually break without xxxChanged events, it will just be one way (control–>object).

I have a lot of OO experience, and I can say without doubt that encapsulation is a good thing, but I can still argue against using simple wrapping properties, in theory at least….

The fact that public fields are not absolutely identical to public properties from the interface perspective is a flaw in the implementation of the programming language. I should be able to change a public field to a property (or vice-versa) whenever I feel like it, without it affecting the interface of my class. That is what encapsulation means.

As far as I can tell, the fact that I cannot is because of the implementation of the compiler/clr/language.

11/29/2005 7:40 PM | Steve Campbell

>>As far as I can tell, the fact that I cannot is because of the implementation of the compiler/clr/languag

yes , properties is just syntactic sugar, they are implemented as methods : get_Property set_Property in the ilcode

and methods and fields are not interchangable for obvious reasons.

12/2/2005 9:04 AM | Roger Johansson

The public fields debate again

Back in November last year I wrote about why you should make fields in a class private and not make them public. A recent post in Code Project shows that some people still make fields public. I did concede on one argument though – If you have a struct with nothing but public fields then there was no need to make them private and create public properties to back them. But, I added….

As soon as you put any form of functionality in there (or even if you think that at some point in the future there will be some form of functionality in there) then make them private and create properties.

While accessing public fields and properties may look the same to a C# developer, a property is just syntactic sugar over the get_ and set_ methods. So if you make the transition to properties later on (for to add additional functionality – e.g. implementing a lazy look up on a getter, or setting a dirty flag on a setter) any assemblies that relied on public fields will fail because, to them, the public interface of the class is now different.

Therefore if you get in to the habit of creating properties backing your private fields always you’ll never have to worry about how you are going to add in additional functionality later on when you realise the public interface changes.

NOTE: This was rescued from the Google Cache. The original date was Saturday 17th June 2006.

Tags:

Original Comments:

There is nothing wrong with using public fields in an non-public accessable class.

6/17/2006 5:52 PM | leppie

I dont think its wrong to have public fields in a lib as long as you dont plan on beeing binary compatible, since binary compatabillity breaks the day you change one of those fields to a property..

6/18/2006 6:36 AM | Roger Johansson

leppie – I’ll accept that is also another place where it might be okay to use public fields.

6/23/2006 9:53 PM | Colin Angus Mackay

Keep the heid!

Okay – so my blog got hit 30,000 times in the last two days. Specifically this post got hit 30,000 times. It seems to have generated a lot of noise out there. Many people thanking me for the tip (how to stop that annoying dialog asking if you want to reboot when security updates are installed) and some annoyed that I published it. (Can’t win ’em all I suppose).

The original post was published without comment, so I guess it is time to do that. I thought it was a good tip to delay the repetition of the dialog for a couple of hours until I got some work done. The idea being that I’d reboot when I went for lunch or at the end of the day, but right this very minute I want to work.

It seems that many people are using it to stop windows update totally. In my opinion this is a bad idea. Windows Update exists for a reason – that is to help deliver security updates in a reasonably non-intrusive way. Well, that is until the dialog box pops up asking you to reboot.

I offered the tip as a short delaying tactic only – and I have now added a big bold header on the top of the post to remind people of that and that security updates really are a good idea, regardless of which operating system you use.

NOTE: This was rescued from the Google Cache. The original was dated Thursday 29th June 2006.

Delete the row, or set a deleted flag?

For auditing purposes some database system run without deleting rows from the database – they just flag the row as being deleted and ensure that queries that run on the table add a line to the WHERE clause to filter out the “deleted” rows.

However, as Daniel Turini points out on Code Project, this can hurt the database performance.

Specifically he says:

Bear in mind that having a flag leads to bad index performance. In my (rather old) SQL Server DO’s and DONT’s[^], I suggest you not to index on the “sex” or “gender” field:

First, let’s understand how indexes speed up table access. You can see indexes as a way of quickly partitioning a table based on a criteria. If you create an index with a column like “Sex”, you’ll have only two partitions: Male and Female. What optimization will you have on a table with 1,000,000 rows? Remember, mantaining an index is slow. Always design your indexes with the most sparse columns first and the least sparse columns last, e.g, Name + Province + Sex.

Creating a “deleted” flag will lead to bad performance, on several common cases. What I’d suggest is to move those rows to a “Deleted” table, and have a view using UNION ALL so you can easily access all the data for auditing purposes.

Not to mention that it’s easy to forget an “AND NOT IsDeleted” in some of your queries.

However, others recon the performance hit is negligable. Or that moving the data to a new table could damage the data. It is an interesting debate and you can read it here, from the start.

NOTE: This was rescued from the Google Cache. The original date was Thursday, 29th June 2006.

Tags:

Mental Block

Today, I seem to be having a mental block while writing some unit tests. I keep writing Assert.AreSame() instead of Assert.AreEqual() and then wondering why tests are failing with bizarre message like “Expected 2, Actual 2”

Just in case anyone else has a day like this I’m going to explain the difference (although mainly as a bit of therapy for myself)

The AreSame() method checks that the expected and the actual reference the exact same “physical” object.

The AreEqual() method checks that the expected and the actual are equal to one another, even if they are not “physically” the same object.

NOTE: This was rescued from the Google Cache. The original was dated Friday, 21st July, 2006.

Tags:

Moving Databases

If you ever move a database from one SQL Server to another you may come across the situation where the logins no longer map to the users in your database (and that’s assuming that the SQL Server you’ve moved the database to has the same logins).

If the new SQL Server does have the same logins then you can fix the mapping by using sp_change_users_login. The neat thing is that if the user and login names already match then there is an “Auto Fix” setting. And if you just don’t know what is mismatched there is a “Report” option too.

NOTE: This was rescued from the Google Cache. The original was dated Saturday 1st July, 2006.

Tags:

TV Licensing are a bunch of…

I don’t really think I can say what I think of the TV Licencing people at the moment. I’ve just moved into my new flat. I got my TV Licence transferred over the day before I moved in. And now, three weeks later, they are sending me threatening letters. I knew people that had been harrassed by TV Licencing but it doesn’t really hit you how much a bunch of complete &^*!$%@ they are until they threaten you. Anyway, I’ve got the evidence that I am, and always have been, in possesion of a valid TV Licence and the emails of the hassels that it took to transfer it over so if they do go nuts and report me to the Procurator Fiscal (and I hope I can convince them otherwise – but from what I hear that is very difficult) I can just turn up with all the documentation and say “Here is the evidence. I do have, and always have had, a valid TV Licence.”

In fact, I’m posting this from my parents house – I don’t have broadband yet, and I only just got a phone line put in today. The reason I am here is so that I can access my email and print out the relevant emails. So, not only have TV Licencing caused me stress (my stress reaction is to panic for 5 minutes then over-eat), but I’ve had to complete a 100 mile round trip to get the evidence in case they decide to send the “Enforcement Officers” round to search my flat! And, according to the letter I received today, they now have the authority to do that.

NOTE: This was rescued from the Google Cache. The original date was Tuesday, 26th September, 2006.

Tags:

Original comments:

The world is full of stupid &^*!$%@ like these. I had a similar incident some while ago when I decided TV was so crap we could do without it. So I did not renew the licence and told the licencing authority the reasons why. Despite this, they hounded me for months.

9/27/2006 6:23 AM | vigilante

 

You should allow them to do their worst then sue them for emotional distress and the recovery of the costs involved in proving them don’t have a case. Bring a small claims court action against them!

9/27/2006 11:45 PM | John A Thomson

 

I’ve already sent them a letter telling them of my anxiety of receiving their threatening letter and asking for compensation for gathering the evidence quickly in case they break down my door looking for my TV. I also reminded them that, unless things have changed since I was at school, that I was taught that in this country one was innocent until proven guilty.

Hopefully that will be the end of the matter, but having spoken to other people about TV Licensing, it seems unlikely. As a result, I am expecting that by the time a judge gets to see this I’ll have a folder as thick as a set of Harry Potter books of threats and evidence proving the threat to be unfounded.

9/28/2006 10:58 PM | Colin Angus Mackay

 

I had a similar experience in the halls at Uni. I didn’t have a TV, but every week or so I’d have a letter from them saying I owed them money, and every 2 weeks or so I’d have a letter saying that they’d called round for an inspection to make sure I didn’t have a TV, though I was at lectures. It was the janitor who did all this, apparently, and I doubt he’d have spotted a TV card in a computer if I had one. It annoyed me until I emailed them and told them to sod off, which they did. I’ve never had to prove that I did have a licence though.

9/29/2006 2:18 PM | Michael Maclean

 

I had a problem with TV Licensing recently, after I bought a new TV but used a slightly different address to have it sent to than on my TV licence (which was wrong, as the website wouldn’t accept the correct address). See http://mikedimmick.blogspot.com/2006/08/tv-licensing-has-serious-issues.html for the details.

I didn’t post the end result; eventually one of my emails got through, and I now have a letter from them accepting the new address on the TV licence.

10/1/2006 5:31 PM | Mike Dimmick