Little tip I thought I'd share...as of the date of this posting (7/2008), when building connection strings to access a MaxDB instance, the password must be changed to all uppercase.

For anyone who's wondering, it is possible to connect to MaxDB with ASP.Net/C#.  Use the System.Data.Odbc library and a DSN to connect with only a few lines of code.

- Tim Medora

Most ASP.Net developers quickly learn that web.config file settings percolate from the top down.  This is commonly used to provide global configuration for a single web application, but it's pretty easy to forget that web.config settings can be inherited across different virtual directories.

For example:

1) Create a website in IIS.
2) Create a virtual directory for a second site underneath the IIS website.
3) Reference a type in the web.config for site #1, such as in a HttpHandler block.
4) Unless the second site has the type referenced in #3 (or it is in the GAC), second site will now immediately throw an exception, "Cannot load type xxx.xxx.xxx".

In web.config #1
<httpHandlers>
   <add verb="GET" path="*.css.ashx" type="NFC.PublicWeb.UILogic.PathResolver,NFC.PublicWeb"/>
</httpHandlers>

This issue is caused because every virtual directory underneath the top-level website is inheriting settings from the top-most web.config.  Many of these inherited settings would go unnoticed, but as soon as the child virtual directory hits something it can't handle, it immediately throws a show-stopping (as all config errors are) exception.

Quick Solution?
Wrap application specific blocks of code in the LOCATION tag.  Obviously this must be used judiciously, but it's a useful fix to a sneaky problem.

Check out this brief whitepaper by Chris Szabo on a more elegant way of determining if the data encapsulated by an object is dirty or not.

Typical practice is to always save the object, dirty or not, which can be wasteful in a high-traffic scenario.  Alternatively, many developers maintain an IsDirty flag, which does the job, but isn't that elegant.  It also doesn't account for data that has "changed" but might actually be the same, such as when a user enters a value into a field that is bound to an object, and then undoes the operation.

http://www.netfusioncorporation.com/Downloads/2008/Intelligent%20Data%20Persistence.pdf

- Tim Medora