Debugging Windows service while developing in Visual Studio 2010

1. Set your windows service project as the start up project.

2. Go to Project --> Properties --> Debug section --> set Configuration as "Debug"

3. Go to Project --> Properties --> Debug section --> Check "Enable unmanaged code debugging" checkbox.

4. Go to Project --> Properties --> Debug section --> set required paramenters (to be used in service OnStart())

5. Go to Project --> Properties --> Build section --> set required platform targets (in case of oracle database (oracle.dataaccess.dll), we need to set the platform target as similar to the oracle client version installed in the machine. You can install 32bit oracle client in 64 machine.)

Log Parser Lizard

Log Parser Lizard

Log Parser is a very powerful and versatile query software tool that provides universal query access to text-based data, such as log files, XML files, and CSV files, as well as key data sources on the Microsoft Windows operating system, such as the event log, IIS log, the registry, the file system, and the Active Directory services. Because the command-line interface is not very intuitive, we have created Log Parser Lizard, a free GUI tool for managing queries and exporting results to Excel and charts. 

  

 

http://www.lizard-labs.net/log_parser_lizard.aspx

Understanding char, nchar, varchar and nvarchar

What they store?

• nchar and nvarchar can store Unicode characters.
• char and varchar cannot store Unicode characters.
• char and nchar are fixed-length which will reserve storage space for number of characters you specify even if you don't use up all that space.
• varchar and nvarchar are variable-length which will only use up spaces for the characters you store. It will not reserve storage like char or nchar.
• nchar and nvarchar will take up twice as much storage space, so it may be wise to use them only if you need Unicode support.

Sizes they need

• char    =  fixed-length character data with a maximum length of 8000 characters.
• nchar  =  fixed-length unicode data with a maximum length of 4000 characters.
• Char   =  8 bit length
• NChar =  16 bit length

Summary

First, char and nchar will always use a fixed amount of storage space, even when the string to be stored is smaller than the available space, whereas varchar and nvarchar will use only as much storage space as is needed to store that string (plus two bytes of overhead, presumably to store the string length). So remember, "var" means "variable", as in variable space.

The second major point to understand is that, nchar and nvarchar store strings using exactly two bytes per character, whereas char and varchar use an encoding determined by the collation code page, which will usually be exactly one byte per character (though there are exceptions, see below). By using two bytes per character, a very wide range of characters can be stored, so the basic thing to remember here is that nchar and nvarchar tend to be a much better choice when you want internationalization support, which you probably do.

Now for some some finer points.

First, nchar and nvarchar columns always store data using UCS-2. This means that exactly two bytes per character will be used, and any Unicode character in the Basic Multilingual Plane (BMP) can be stored by an nchar or nvarchar field. However, it is not the case that any Unicode character can be stored. For example, according to Wikipedia, the code points for Egyptian hieroglyphs fall outside of the BMP. There are, therefore, Unicode strings that can be represented in UTF-8 and other true Unicode encodings that cannot be stored in a SQL Server nchar or nvarchar field, and strings written in Egyptian hieroglyphs would be among them. Fortunately your users probably don't write in that script, but it's something to keep in mind!

Another confusing but interesting point that other posters have highlighted is that char and varchar fields may use two bytes per character for certain characters if the collation code page requires it. (Martin Smith gives an excellent example in which he shows how Chinese_Traditional_Stroke_Order_100_CS_AS_KS_WS exhibits this behavior. Check it out.)

UPDATE: As of SQL Server 2012, there are finally code pages for UTF-16, for example Latin1_General_100_CI_AS_SC, which can truly cover the entire Unicode range.

Dependency Injection

Basically, instead of having your objects creating a dependency or asking a factory object to make one for them, you pass the needed dependencies in to the constructor, and you make it somebody else's problem (an object further up the dependency graph, or a dependency injector that builds the dependency graph). A dependency as I'm using it here is any other object the current object needs to hold a reference to.

One of the major advantages of dependency injection is that it can make testing lots easier. Suppose you have an object which in its constructor does something like:

public SomeClass() {
    myObject = Factory.getObject();
}

This can be troublesome when all you want to do is run some unit tests on SomeClass, especially if myObject is something that does complex disk or network access. So now you're looking at mocking myObject but also somehow intercepting the factory call. Hard. Instead, pass the object in as an argument to the constructor. Now you've moved the problem elsewhere, but testing can become lots easier. Just make a dummy myObject and pass that in. The constructor would now look a bit like:

public SomeClass (MyClass myObject) {
    this.myObject = myObject;
}

Most people can probably work out the other problems that might arise when not using dependency injection while testing (like classes that do too much work in their constructors etc.) Most of this is stuff I picked up on the Google Testing Blog, to be perfectly honest...

http://stackoverflow.com/questions/130794/what-is-dependency-injection