So we have to change the SqlClientDrive... Have you time to check something ? ARG!!! somebody have changed the SqlClientDriver methods to static... I'll fix it later... Well... copy&paste our SqlClientDriver implementation and change the SetParameterSizes implementation setting the parameter type to SqlDbType.Time. We have to check if something wrong happen for MsSQL2005 and MsSQL2000. If nothing wrong happen we can maintain just one implementation. Were it fail, we have to implement another drive.
btw, Neal, the fact remain: we have to push ppl in Microsoft to respect their rules When setting command parameters, the SqlDbType and DbType<http://msdn.microsoft.com/en-us/library/system.data.dbtype(v=VS.90).aspx> are linked. Therefore, setting the DbType changes the SqlDbType to a supporting SqlDbType. On Wed, Apr 20, 2011 at 6:01 PM, Neal Groothuis <[email protected]>wrote: > The SqlDbType enum is System.Data.SqlDbType, in the System.Data > assembly. > > On Apr 20, 4:56 pm, Fabio Maulo <[email protected]> wrote: > > In which assembly is the SqlType.Time ? > > > > On Wed, Apr 20, 2011 at 5:54 PM, Neal Groothuis < > [email protected]>wrote: > > > Fabio, > > > > > I don't see a way to practically get "Microsoft to follow their > > > rules", especially after they've said that, yes, it's a bug, but they > > > believe that fixing it in existing versions of .NET would cause more > > > harm than good. > > > > > What's gained by forcing users to have to come up with ugly hacks when > > > the problem can be accommodated easily and cleanly in the core of > > > NHibernate by overriding a method and adding two lines? > > > > > - Neal > > > > > On Apr 20, 2:55 pm, Fabio Maulo <[email protected]> wrote: > > > > In practice... > > > > When an OSS RDBMS does not follow DbType rules we ask them to fix the > > > > problem. > > > > Microsoft said "good bye" to Oracle data-provider and now Oracle have > to > > > > follow all rules defined by Microsoft. > > > > > > We all should push Microsoft to follow his rules at first. > > > > > > NOTE: the same is for the DbProviderFactories its famous "invariant" > name > > > > and the first one breaking the rule who was... again Microsoft for > SQLCe > > > > versions. > > > > > > On Wed, Apr 20, 2011 at 3:49 PM, Fabio Maulo <[email protected]> > > > wrote: > > > > > NH-2661 was closed. > > > > > Microsoft said: > > > > > "Thanks for reporting this issue. This is a bug in our product, but > > > after > > > > > carefully investigating the issue, we have decided not to fix the > bug. > > > " > > > > > > > We say: > > > > > We are not the workaround fabric. If one of your customer, who pay > to > > > have > > > > > your product, say that you have a bug and then you admit that you > have > > > a > > > > > bug, then you have to fix it. > > > > > > > On Wed, Apr 20, 2011 at 3:36 PM, Neal Groothuis < > > > [email protected]>wrote: > > > > > > >> Hi Fabio, > > > > > > >> I've raised two: NH-2660 and NH-2661, with failing tests attached. > > > > >> I've also got potential solutions for both. The Set() method on > the > > > > >> custom TimeType in the test for NH-2661 is one possible fix for > > > > >> NH-2660, and I've included a possible solution to NH-2661 in the > > > > >> comments on the issue. > > > > > > >> Please let me know if you have questions or if I can help further! > > > > > > >> - Neal > > > > > > >> On Apr 19, 8:21 am, Fabio Maulo <[email protected]> wrote: > > > > >> > mmmm perhaps yes. > > > > >> > There is a problem in the Set. > > > > >> > Have you a failing test ? > > > > >> > If yes please file a JIRA ticket asap. > > > > >> > Thanks. > > > > > > >> > On Tue, Apr 19, 2011 at 9:17 AM, Fabio Maulo < > [email protected]> > > > > >> wrote: > > > > >> > > public class MsSql2008Dialect : MsSql2005Dialect > > > > >> > > { > > > > >> > > protected override void RegisterDateTimeTypeMappings() > > > > >> > > { > > > > >> > > base.RegisterDateTimeTypeMappings(); > > > > >> > > RegisterColumnType(DbType.DateTime2, "DATETIME2"); > > > > >> > > RegisterColumnType(DbType.DateTimeOffset, "DATETIMEOFFSET"); > > > > >> > > RegisterColumnType(DbType.Date, "DATE"); > > > > >> > > RegisterColumnType(DbType.Time, "TIME"); > > > > >> > > } > > > > > > >> > > On Mon, Apr 18, 2011 at 7:11 PM, Neal Groothuis < > > > > >> [email protected]>wrote: > > > > > > >> > >> Hey all, > > > > > > >> > >> I have a table with two TIME columns on a SQL Server 2008 > > > database. > > > > >> > >> I'm running into problems when I try to query against them, > and I > > > > >> > >> think this is a bug in the Set() methods for the > > > TimeAsTimeSpanType, > > > > >> > >> TimeSpanType, and TimeType classes. > > > > > > >> > >> All of these methods add the value that's passed to the Set() > > > method > > > > >> > >> to the parameter array as a DateTime object, but at least on > this > > > > >> MSDN > > > > >> > >> page (http://msdn.microsoft.com/en-us/library/cc716729.aspx), > it > > > > >> shows > > > > >> > >> that the .NET type that's associated with DbType.Time should > be > > > > >> > >> TimeSpan, not DateTime. This is preventing me from running > > > queries > > > > >> > >> against these columns, because I always get an operand type > > > clash: > > > > >> > >> "The data types time and datetime are incompatible in the > less > > > than > > > > >> > >> operator." (I'm doing a comparison between the parameter that > I'm > > > > >> > >> passing in and one of the TIME columns.) > > > > > > >> > >> I'll likely try to work around this tomorrow by creating my > own > > > time > > > > >> > >> type class with the correct type being placed into the > command > > > array. > > > > >> > >> Can anyone else offer any insights into this? If not, I'll > also > > > > >> raise > > > > >> > >> it as an issue in the project's JIRA instance. > > > > > > >> > >> - Neal > > > > > > >> > >> -- > > > > >> > >> 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. > > > > > > >> > > -- > > > > >> > > 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. > > > > > > > -- > > > > > 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. > > > > -- > > 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. > > -- 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.
