JazSolutions

Exceptions (unexpected errors) are a part of every application lifecycle. No matter how reliable your code is there will be instances when the app will run into unexpected runtime issues and rightfully so the CLR will raise an exception. A general rule of thumb while handling exceptions is to only handle them if you can do something about it otherwise let it bubble up the call stack. This also minimizes on the number of try/catch blocks in your code.

A standard practice is to log all the errors to a destination of choice e.g. text files, emails or DB. There are exception handling/logging frameworks e.g.  the Exception Handling Application Block and ELMAH out there that offer this functionality. Once exceptions get logged then anyone is able to review them and take actions appropriately. However, if you have a large user base or provide SaaS (software as a service) then it maybe worthwhile to have them end up in a DB where you maybe able to do a little more than simply viewing them e.g. searching & reporting.

Exceptions can be like health indicators for your apps. Once you have access to your exception data in a format that can be queried then you maybe able to see patterns overtime which can provide insight into different aspects of your code e.g. does a certain error occur frequently due to a certain environment aspect that may have been overlooked in code?

An important thing to keep in mind is that throwing exceptions is an expensive process. For every exception that the CLR encounters it needs to walk the stack in search of an exception handler. So while it may not be easy sometimes to resolve certain exceptions in a simple manner but that maybe a cost you are willing to pay for a healthier app and better user experience.

A while back I got the opportunity to use LINQ to SQL (L2S) for an internal web application. What is L2S? It's an O/RM framework by MS that makes it easier to create entity classes that map to the physical DB. Unfortunately, as of this writing there are quite a few concerns out there that L2S *maybe* dead which would really be sad.

My main source of information for L2S were the 9 tutorials from ScottGu's blog. I would recommend anyone trying to get up to speed to go over them. The L2S functionality comes with a designer that makes the entire data access functionality development a snap. In comparison to the previous DAC development technologies by MS, I found L2S much more cleaner. There is still a lot of code being generated behind the scenes, but extending this functionality is easier. Connection management has been abstracted away from the developer. And the biggest feature, of course, is the ability to query these generated entities using LINQ. All these features combined make the (commonly needed) DAC development process easier & faster so developers can focus on the more interesting aspects of the application. Updates to the underlying DB schema are easy to replicate as well - depending on the size of the changes, of course.

While L2S gets the job done quickly, there are some issues that I ran into and thought I should blog about.

DataContext Connection String settings

The L2S designer enables you to customize the connection string settings as desired. By default the DataContext properties will look something like this:

An important setting here is the Settings Property Name. Although it is set to "NORTHWNDConnectionString" in this case, it can be a little misleading if you want the DataContext to read the connection string value from the app config file (which is what most of us want eventually). In order to make this work, the name should be specified with the proper qualifiers i.e. <ProjectName>.Properties.Settings.<ConnectionStringPropertyName> (similar to how it would have been accessed in code). For example, here is the connection string name in the config file:

I would have saved myself a little bit of frustration had I used the proper name. It turns out that if you don't have the correct name in the config file, it will fall back on the default connection specified during design time.

DataContext Lifetime Management

It's quite easy to use the (generated) DateContext class anywhere from code e.g.

However, due to the way the DataContext works, it can become an important issue as to when and where should it be initialized. For example, in scenarios where change tracking is required or if the DataContext has to be passed to business components. There is an interesting and detailed post on this issue on Rick Strahl's blog which provides more insight and proposed solutions.

LinqDataSource does not retrieve sub-property values in Select only mode

If you followed the L2S tutorial Part 5 - Binding UI using the ASP:LinqDataSource Control from ScottGu's blog you will have seen how easy it is to display sub-properties in a GridView column e.g. if you were displaying Product details and the Product entity had a Supplier property on it then you can easily data bind to the Supplier's CompanyName property as follows:

But in the tutorial, updates were enabled on the LinqDataSource. What if you wanted to use the data source control for display only purpose? If you disabled any kind of update on the LinqDataSource control, well then it seems like the sub-property values are not retrieved and the bound column is blank while other columns do have values in them.

I am unsure if this is intended behavior or a bug but either way just make sure to check one of the boxes in the Advanced Options dialog box of the control shown above in order to retrieve the sub-property values correctly.

One thing that I do from time to time is work with 2 different instances of the same DB on different servers e.g. when comparing data on 2 different versions of the application in development and QA. While I could easily query the tables I'm interested in 2 different SQL query editor windows sometimes its convenient if I could treat the tables from the different databases as belonging to the same server so I don't have to switch between multiple windows. The other benefit of this is being able to perform joins and other update operations.

Linked servers enable me to do just do that. It's easy to add a linked server in SQL Server by using the following sproc:

sp_addlinkedserver [server]

There are some other params that can be supplied to the add sproc if you are dealing with non-SQL server but if you mainly deal with SQL Servers then your life is much easier. To display the current linked servers use the following sproc:

sp_linkedservers

To delete use: sp_dropserver [server]

Now comes the fun part - how do we actually query data from a linked server. It's pretty simple as long as you follow the proper naming format:

select * from [server].[linkedserverdb].[dbo].[table]

So, for example, if I wanted to perform a diff on the Client table in different databases then I would do:

select a.clientid, b.clientid from [dbo].[Client] as a

full join [server].[Northwind].[dbo].[Client] as b

on a.ClientId = b.ClientId

This will display the same and missing client IDs in both tables.