I'd like to add a little bit of followup on this issue. The original blog author posted a new entry the day after I started this thread. The author indicates that prepare_sql does alleviate the issue. http://scarydba.wordpress.com/2009/03/11/a-fix-for-nhibernates-parameter-problem/
In that entry the author points to the following: http://testdrivendevelopment.wordpress.com/2009/03/10/nhibernate-queries-sql-server-execution-plans/ Also related to this topic: The issue came up right out of the gate on the Herding Code episode 38 podcast that was published on March 13th. http://herdingcode.com/?p=171 On Mar 10, 4:30 pm, Daniel Auger <[email protected]> wrote: > So, it looks like the author of the blog post was putting the blame in > the wrong spot. You are right, the NH team can't fix Sql Server for > MS. > > Fabio, that request could make for an entertaining conversation. ;) > > On Mar 10, 3:38 pm, Fabio Maulo <[email protected]> wrote: > > > Daniel, if you have time please send the same request to the team are > > developing your RDBMS and ask they why the system is using a different query > > plan only because a parameter has a different length... at the end the > > query-plan should be based on tables and fields involved in the query and > > not on a parameter value especially when the parameter is not involved in > > the SELECT clause. > > > 2009/3/10 Daniel Auger <[email protected]> > > > > Excellent information. Thanks! > > > > On Mar 10, 2:07 pm, Fabio Maulo <[email protected]> wrote: > > > > try to set prepare_sql to true and, btw, it is a specific "problem" of a > > > > specific RDBMS. > > > > I know that many people think that NH can solve anything but we can't... > > > > If an RDBMS has a strange way to paginate result, we can do something > > > > but > > > we > > > > can't change the RDBMS. > > > > If WCF has a bug for distributed transaction we can apply, may be, a > > > > workaroud but the bug is in WCF. > > > > If a RDBMS change its behavior when you use "OR" clause instead "IN" and > > > the > > > > "OR" has better performance then "IN" the real problem is not in NH but > > > in > > > > that RDBMS. > > > > > We are few, poor and ugly and commercial companies (as Microsoft or > > > ORACLE) > > > > has more power to fix their issues. > > > > > 2009/3/10 Daniel Auger <[email protected]> > > > > > > I hadn't even considered the scariness of that :). > > > > > > Are you implying this behavior only happens with primary keys? I was > > > > > under the impression that any of the varchar parameters could > > > > > potentially cause another execution plan to be created. > > > > > > On Mar 10, 12:35 pm, Gustavo Ringel <[email protected]> wrote: > > > > > > It is using nvarchar as a primary key, i hope that was what scared > > > you. > > > > > > > Gustavo. > > > > > > > On Tue, Mar 10, 2009 at 5:59 PM, Daniel Auger < > > > [email protected] > > > > > >wrote: > > > > > > > > I came across this today: > > > >http://scarydba.wordpress.com/2008/04/29/nhibernate-recompiles-and-ex. > > > > > .. > > > > > > > > I'm wondering how people are dealing with this, or if it is seen > > > > > > > as > > > a > > > > > > > non issue. > > > > > -- > > > > Fabio Maulo > > > -- > > Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
