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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
