The schemaupdater need the driver. It can be set through the conf. or the dialect. In that test I'm cleaning the conf. to be sure that the dialect has a default driver.
-- Fabio Maulo El 25/04/2011, a las 02:39, Patrick Earl <[email protected]> escribió: > 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 >> >>
