I saw two posts on creating a custom type in NHibernate to map to the SQL Server TimeStamp column by implementing the IUserVersionType interface (reference here and here), but that didn't tell the whole story. First, there is the bug in Beta 1 that held me up longer than I wanted it to (see the bug and the fix here). With that out of the way, using the Timestamp SQL Server column mapped to a byte[] worked. (Note: bug is resolved as of Beta 2)

However, when using NHibernate to generate the table, the field got created as a varbinary(8000).

The solution seemed simple. I created a new class that derived from the MsSql2005Dialect class. I then added DbType.Object to the registered columns:

This maps the DbType.Object to the TimeStamp field in SQL. I picked the Object type since it wasn't being used, and not likely to be used. If yourimplementation uses this type, then you will have to pick another type.

I then modified my custom type to return DbType.Object as the sole SqlType returned from the property:

Then I changed my configuration to use my custom type instead of the NHibernate MsSql2005Dialect. So, the config line looks like this:

MyUtilityClass.NHibernate.MsSql2005TSDialect, MyUtilityClass

When I ran the unit test to create my table, it worked like a champ. Then I ran the rest of my unit tests, and all of the updates failed. ADO.Net was reading DbType.Object as a Variant, setting the parameter type to "variant", and then the generated SQL was failing. Back to the drawing board.

The answer I came up with is admittedly a hack, but it solved my problem for now. Here is my (hacky) solution:

When the SqlTypes(IMapping mapping) method gets called in the CustomTypeclass for table creation and other DDL tasks, the container for the mapping parameter is NHibernate.Cfg.Configuration. When that method gets called for non-table creation (ie CRUD) operations, the container is not.

So, I defined two SqlTypes in my custom class, one for CRUD operations (SqlType.Binary) and one for DDL operations (SqlType.Object).

Not the most graceful, admittedly, but it solved my issue, and now all of my unit tests are green, I don't have to use triggers to check for database data updates outside of the NHibernate universe, and I can continue on in my coding of the POC.

Note: I created another class in NHibernate called CustomType2 (I know, real original) that inherits from CustomType. Code shown here: