That makes sense to me (have the driver select the 'best' dialect and then permit the user to override if they want some 'non-best' behavior).
Steve Bohlen [email protected] http://blog.unhandled-exceptions.com http://twitter.com/sbohlen On Fri, Apr 22, 2011 at 6:43 PM, Fabio Maulo <[email protected]> wrote: > mmm... perhaps is not so a big problem. > When the user will have the ADO.NET exception he will try to file a JIRA > or a question in nhusers and we can help him. > Another possible thing to do is in releasenotes... > I think I have already fixed the last problem with the default-driver set > by the dialect, so we can invite all users to remove the the set of > connection.driver_class and trust in NH (at least for MsSQL). > > Thoughts ? > > > On Fri, Apr 22, 2011 at 7:18 PM, Stephen Bohlen <[email protected]> wrote: > >> MsSql2008DialectEx? >> >> (kidding!) >> >> Steve Bohlen >> [email protected] >> http://blog.unhandled-exceptions.com >> http://twitter.com/sbohlen >> >> >> >> On Fri, Apr 22, 2011 at 6:15 PM, Fabio Maulo <[email protected]>wrote: >> >>> Hi. >>> Thanks to one Microsoft's team we have to implement another drive for >>> MsSqlServer >>> >>> http://connect.microsoft.com/VisualStudio/feedback/details/381934/sqlparameter-dbtype-dbtype-time-sets-the-parameter-to-sqldbtype-datetime-instead-of-sqldbtype-time >>> >>> >>> <http://connect.microsoft.com/VisualStudio/feedback/details/381934/sqlparameter-dbtype-dbtype-time-sets-the-parameter-to-sqldbtype-datetime-instead-of-sqldbtype-time>Our >>> two related issues are NH-2660 and NH-2661. >>> The user is using our "nice" TimeType (I have used with others RDBMS and >>> it work fine); in practice those DataProviders work with DateTime normally >>> and they take care about the possible conversion from DateTime when the >>> parameter type is DbType.Time. >>> >>> Now... >>> For Sql2000 and Sql2005 the DbType.Time expect a DateTime so, our >>> dear TimeType, work as expected. >>> Even for Sql2008 our TimeType work well, at least to store and read >>> values but when we have to run a query, with a value comparison in the where >>> clause, the DataProvider/Sql2008 is not so intelligent and we have a >>> wonderful ADO.NET exception. >>> >>> Because seems that we are the "workaround fabric" we have to find a >>> solution. >>> In practice we have to implement a SqlClient2008Driver where: >>> 1) when the DbType is DbType.Time we have to cast the parameter to >>> SqlParameter >>> and set it to SqlDbType.Time >>> 2) the value of the parameter have to be converted to a TimeSpan >>> >>> In theory it should be not a big problem because we have special drivers >>> for other RDBMS versions... >>> In theory it should be not a big problem because we have can set the >>> default driver in the MsSql2008Dialect... >>> >>> In practice: can you imagine how many users already have the NH >>> configuration with the explicit set of NHibernate.Driver.SqlClientDriver and >>> the MsSql2008Dialect ? >>> >>> "Che famo ?", "de que nos disfrazamos ?" >>> >>> Thoughts ? >>> >>> -- >>> Fabio Maulo >>> >>> >> > > > -- > Fabio Maulo > >
