This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello, I'm using a linq query but an exception is thrown : var query = from user in uow.Users it seems Equals method is not supported. Any changes of adding Equals (with overloads) support to latest builds? |
|
|
I've added support for .Equals, and it will be included in nightly builds dated 18 Aug 2009 and above. However, this does not include support for the StringComparison overload. It's not in general possible to translate this overload into SQL, because the string matching strategy (culture, case-sensitivity, etc.) is determined by a database (or, at a finer level, table or column) setting -- the collation setting as SQL Server calls it -- not the SQL query. The same limitation exists in LINQ to SQL. If you're talking to a particular database that does have SQL support for specifying how to perform string matching, let us know and we'll see if we can support it for that database (no promises I'm afraid). |
|
|
I've been looking into this a bit further and although I have found a way to specify a specific collation in a SQL Server query, and have prototyped using this from the LightSpeed core API, I don't think it's going to be possible to translate the String.Equals(string, StringComparison) overload into this SQL. The reason is that the SQL Server syntax requires us to specify a named collation, e.g. LATIN1_GENERAL_CI_AS (Latin-1 character set, case insensitive, accent sensitive). Short of writing an exhaustive lookup table, I don't think it's possible to translate from a StringComparison and a culture to a collation name. Because SQL Server requires the full collation name, we can't just tell it "use whatever collation you're set up with, but case-insensitive" (which I suspect would suffice for you, though even that might go awry if the user's CurrentCulture was different from the column collation). We could probably try to support the overload for StringComparison.InvariantCulture, InvariantCultureIgnoreCase and Ordinal (but not OrdinalIgnoreCase). If that would be useful to you, let us know and we will investigate further. Alternatively, if using a localised culture is important to you, and you are willing to handle translating user cultures into SQL Server collation strings and to forgo LINQ, we can provide you with the core API updates to support this. If you need this functionality on any database other than SQL Server then please tell us which. |
|
|
I see your point...as you said it, I think it is best to put it on column's collation. Thanks for the investigation but I think supporting .Equals for now is enough.
|
|