I'm getting this... it seems like it might be a related bug. NHibernate.HibernateException : The connection.driver_class must be specified in the NHibernate configuration section. at NHibernate.Connection.ConnectionProvider.ConfigureDriver(IDictionary`2 settings) in ConnectionProvider.cs: line 104 at NHibernate.Connection.ConnectionProvider.Configure(IDictionary`2 settings) in ConnectionProvider.cs: line 64 at NHibernate.Connection.ConnectionProviderFactory.NewConnectionProvider(IDictionary`2 settings) in ConnectionProviderFactory.cs: line 50 at NHibernate.Tool.hbm2ddl.ManagedProviderConnectionHelper.Prepare() in ManagedProviderConnectionHelper.cs: line 25 at NHibernate.Test.Tools.hbm2ddl.SchemaMetadataUpdaterTest.SchemaMetadataUpdaterFixture.CanRetrieveReservedWords() in SchemaMetadataUpdaterFixture.cs: line 20
On Fri, Apr 22, 2011 at 4: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 >>> 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 > >
