System.Threading.Timer

I have a data population task inside a windows service that needs to start on a certain date and repeat periodically at a specified interval. The start date and the repeat interval can be specified through a xml config file.

I decided to use the Timer class in the System.Threading namespace. It has a number of  constructor overloads and the following is the one I used :

public Timer(TimerCallback callback, Object state, TimeSpan dueTime, TimeSpan period);

where:

callback -> The method that performs the task.

It must match the signature of the System.Threading.TimerCallback delegate type that has the following signature:

delegate void TimerCallback(Object state)

state -> data that you can pass to the callback method each time it is invoked.

dueTime - > the amount of time the CLR needs to wait before calling the callback method the first time.

period -> the repeat interval

The advantage of using this Timer class is that the callback method is called by a CLR thread pool thread. The Thread Pool assigns one thread from the pool for all Timer instances. This thread keeps track of all the timers and calls them at their due time.



(reference : CLR via C# - Jeffrey Richter)

Full-Text Search in SQL Server 2005

Full-Text search is a SQL Server feature that provides powerful options for querying text information in the database.Without this feature the querying options are pretty much limited to using the LIKE clause or using functions such as PATINDEX and CHARINDEX.

The Full-Text Search is implemented via a Full-Text Search Windows Service. This Service is NOT a part of  the SQL Server. The SQL Server interacts with this external service in order to facilitate Full-Text Search.

Following are the steps to enable Full-Text Search in a database:

• Make a list of tables that need to be Full-Text search enabled.
• In each of the tables, make a list of all the columns that need to be a part of the Full-Text Search index.
• Create a Catalog, specifying a location for its creation. A Catalog is a container that holds Indexes. You can have as many Catalogs as you like and each Catalog can hold zero or more indexes. Though external to the SQL Server, the Catalogs need to be on same machine as the SQL Server. For performance reasons, Microsoft recommends creating the Catalogs in a drive separate from that of  the SQL Server installation. Microsoft also recommends creating separate Catalogs for tables that have more than one million rows of data.
• Create one Index per table. You can have only one index per table. Also you need to specify the Catalog the index belongs to.An Index can belong to only one Catalog.
• At this point, we only have the structure(catalogs and indexes) but no data. We need to populate(crawl) the indexes. Population is the process of SQL Server passing data from the indexed columns to the Full-Text Service, which maintains a word list letting us know what words can be found in what rows. It is a resource and memory intensive action that must be performed during off-peak hours so as to not slow down the SQL Server.Once the population is complete, the tables are Full-Text Search enabled.
• Next, all the database objects like Stored Procedures, Functions and Views need to be modified to use the Full-Text syntax. The Full-Text syntax contains commands like CONTAINS,CONTAINSTABLE, FREETEXT, FREETEXTTABLE etc that enable us to query for information in different ways.
• Full-Text indexes are not kept up to date like SQL Server indexes.So, if new data is added to the tables, the data will not be searchable until the indexes on those tables are re-populated.

Some useful debugging tools

TCP TRACE

I needed to grab and analyze a HTTP Web Request that was being made programmatically from a Windows application. My friend Chandra suggested that I look at the TCP Trace tool. It is a really cool tool that acts as a tunnel between a Client and Server.

This is how it works.When you start it, it pops a dialog as shown below:

Let us asume,the Windows application was making a HTTP Web Request to an ASP.NET web application on port 80. We need this request to be grabbed by the Tcp Trace. So in the window above, set the listening port of the trace to 80 so that it can catch the request. The request needs to be ultimately passed on to the web application which used to listen on port 80.So we change the application's port to another available port, say 8080. We then point the trace's destination port to 8080 on the same server.

After you make these changes and click ok, the Trace is ready to grab the requests coming on Port 80.Now when the windows application make a web request programmatically using the HTTPWebRequest class, the trace catches it. The trace has a visual interface(like fiddler) that enables you to look at the request in detail.

You can download it here.


DEPENDENCY WALKER

I was once integrating a third-party application into my existing application. My application started blowing up at the point of integration complaining about some missing functionality. I had all the third-party assemeblies necessary and was not able to make sense of the error messages. It then struck me that maybe the third-party assemblies are missing some dependency assemblies. I then came across a tool called Dependency Walker, which visually lists all the dependency assemblies for a specified assembly. When I loaded the third-party assembly using this tool,  it showed that I was missing two dependency assemblies. Once I got those assemblies, the application worked just fine.

You can download or find more information about the Dependency Walker here