The issue is that for most drivers, length really doesn't matter for the type you are using. Those are orthogonal concepts.The problem with the scenario you outline is that for SQL CE, it _still_ doesn't matter, but you have to set a SQL CE value as the param type to get it to work. That is why I think that taking your code and spinning it into a full driver project would be the best thing. That driver project could take a dependency on the SQL CE assembly and use it
On Sat, Sep 27, 2008 at 10:48 PM, Artur Dorochowicz < [EMAIL PROTECTED]> wrote: > > I'm sorry, but you will need to be more explicit. > I just don't see how playing with dialect or driver could correct the > problem. My earlier code is not a fix for a bug, it's just a > workaround that happens to work in my case. > I also checked with SqlClientDriver and the actual problem IMHO is > that arguments that NH feeds into IDriver.GenerateCommand(... > SqlType[] parameterTypes) are too generic (BinaryBlob becomes Binary, > StringClob becomes String, no lengths are set). I'm probably missing > something, but without more specific information driver cannot > reliably set command parameter types. And frankly saying, it really > surprises me that that happens to work OK for drivers included in NH > (well, not for SqlServerCe driver). > > > On 26 Wrz, 20:22, "Ayende Rahien" <[EMAIL PROTECTED]> wrote: > > Basically, it is taking the existing SqlCeDriver and moving it (and the > > dialect) into their own project, which will allow to fix this bug and > create > > a set of tests that run against the dialect. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
