Archive for the ‘SQL’ Category

NHibernate – SQL2005 Dialect

July 20, 2006

I had a random error happening the other day when I was running an NHibernate based app I was working on – the problem was the error (“Unable to perform find”) would only happen every now and it wasnt consistantly occurring in the same place. After a bit of digging I read a few other people where having similar issues – running on Sql2005 – something to do with the way 2k5 works with returning rows in certain block sizes… anyway I grabbed the Sql2005 dialect, compiled a dll and chucked it in – as I said the errors seemed to be sparatic… hopefully its fixed now but if anyone else is having the same problem then maybe give this a shot 🙂

 I originally got the dialect file off a link from Ayende Rahien’s blog:

I can’t find it now but I’m sure google might show you some love 🙂 If not then flick me an email and I’ll send you a copy…

In the config file you need to change the dialect setting:

<add key=”hibernate.dialect” value=”NHibernate.Dialect.Extension.MsSql2005Dialect, NHibernate.Dialect.Extension” />

Note the fully qualified class name and then the assembly name (the assembly you compile containing the new dialect will need to be referenced in the project or signed and placed in the gac) 🙂



March 4, 2006

The base for the dataset generator I released the the other day uses Sql SMO (the replacement for Sql DMO) to extract the bits and pieces it needs from the database (things like the table schema – What are the names of the columns?, What foreign keys are on a column?, Is the column a primary key? etc) Sql SMO in .Net 2.0 extents the meta data model exposed by Sql DMO and seems a little more intuitive to use. The problem was the dataset generator seemed a little slow at getting the job done – Was it the file access? Was it the string manipulation? Where was the biggest performance hit coming in? This can be very hard to find (you have to guess) and can waste a lot of time improving your program without a tool like a profiler.

The profiler I was using was the Jet Brains Dot Trace 1.1. This is a simple application which launchs your application and then monitors the calls that are going on and how long they take. The report it gives back allow you to drill down and find out what is really going on behind the scenes. The thing I really liked is that it doesnt really seem to interfer with the execution time of your program (not noticably) so it doesnt take long just to fire it up and check out whats going on. The little performance fixes here and there (these can be hard to do even with a profiler – but refactoring with tests should come in handy there 😀 ) can really make a big difference to how useful/good your final program really is 🙂 Its probibly something that a lot of people already know about but I just thought I’d mention it – If your trying to improve the perfromance of your .Net app then a profiler can be one really handy tool – Dot Trace seems to be a good one out there – I’d recommend it 🙂

With the dataset generator I found that the calls to Sql SMO get_Type() were causing the biggest performance hit (after removing a few obvious bits and pieces here and there). I did a few fixes but nothing too major – just not on the highest list of priorites at the moment – it did high light a few interesting bits and pieces in Sql SMO though.