Samuel, thanks a lot. D'oh, I definitely should have noticed (and checked) the other application! My bad.
All the best, OC On 25. 2. 2016, at 19:10, Samuel Pelletier <[email protected]> wrote: > Hi OC, > > Case insensitivity are locale specific, there is no such thing as universal > case insensitive. The built in case insensitive is only for a-z and A-Z. > > I build a collation file for latin accents where all e are equals > (eéèêëEÉÈÊË), same for o and i and cçCÇ. It is attached to this message. > > Collations are edited using the FBUnicodeManager app installed with the > FBManager on Mac. I do not thing the tool exists on other OS. > > The collation file need to be in the Collations directory and defined in the > database using > CREATE COLLATION "Schema"."CollationName" FOR "information_schema"."sql_text" > FROM EXTERNAL('collationFile.coll1'); > > After, you can alter column to use your collation. > > Regards, > > Samuel > > >> Le 25 févr. 2016 à 11:29, OC <[email protected]> a écrit : >> >> Ha, this reminds me of one old problem I've bumped into and did not find a >> solution yet. >> >> FrontBase contains a CaseInsensitive.coll1 collation file, which would work >> just about perfectly... if it supported all accounted characters. Alas, it >> does not; therefore, whilst a case insensitive like with e.g., "é" works, >> with e.g., "š" it does not. >> >> I've tried to write to the FB support long ago, but got no answer. >> >> Does somebody perhaps either have a proper CaseInsensitive.coll1 for >> FrontBase, or at least a description of its format, so that one could fix >> the file oneself? >> >> Thanks a lot, >> OC >> >> >> On 25. 2. 2016, at 2:12, Chuck Hill <[email protected]> wrote: >> >>> If you always want the comparison to be case insensitive, then you should >>> be able to specify a database collation for the column that is >>> insensitive. Then just just a regular equals qualifier. If you want it >>> case sensitive sometimes and insensitive others, that is a different >>> problem. >>> >>> Chuck >>> >>> From: <[email protected]> on >>> behalf of Lon Varscsak <[email protected]> >>> Date: Wednesday, February 24, 2016 at 5:08 PM >>> To: Paul Hoadley <[email protected]> >>> Cc: WebObjects Development <[email protected]> >>> Subject: Re: Use case for a "case insensitive equals" qualifier >>> >>> Hmm, it would be interesting if there was an alternative, but really the >>> problem lies in the database. Any wildcard type searches (at least that >>> start with a wildcard) are not likely to use indexes and cause a table >>> scan. If your database supported the concept of having case-insensitive >>> indexes, then I would think it would be pretty trivial to implement in your >>> own qualifier. In Sybase (the database I use mostly) you can create a >>> functional index (an index based on a function), but it’s the equivalent >>> creating a second column that’s always lower and maintaining an index on >>> it. The difference being that the database maintains it for you (which is >>> usually annoying for EOF). >>> >>> I’ve always wanted a better way to do this too. >>> >>> -Lon >>> >>> On Wed, Feb 24, 2016 at 5:13 PM, Paul Hoadley <[email protected]> wrote: >>> Hello, >>> >>> Say you have a web application where the login identifier is the user’s >>> email address. This works in the conventional way: the user supplies that >>> address at sign-up, and it serves two in-app functions: login identifier, >>> and actual email address to which notifications can be sent. This is a >>> fairly common pattern among some large, modern web apps. >>> >>> It turns out that not everyone understands case sensitivity. We are seeing >>> login failures in the wild because a user that signed up as >>> “[email protected]” is now trying to log in with “[email protected]”, >>> or vice versa. Here are some facts: >>> >>> 1. It would seem to be at least reasonably common for modern web apps that >>> use email addresses as login identifiers to ignore case at login time. (For >>> example, I tested a couple I had open in browser tabs: Strava and Bitbucket >>> ignore case.) >>> >>> 2. Although the domain part of an email address is case-insensitive, my >>> understanding is that the relevant RFCs suggest that you shouldn’t make >>> assumptions about the local part. While everything I’ve read claims that in >>> practice it will make no difference, let’s assume that we need to preserve >>> the address as entered at sign-up. (It’s fail-safe to do so, whether we >>> strictly need to or not.) >>> >>> So, 1 is our aim: ignore case on the login identifier at login time. But >>> because of 2, we don’t want to, say, normalise the email address given at >>> sign-up to lower case and just store that, on the off chance that it makes >>> a difference for mail delivery for that particular user. (Again, it >>> probably won’t, but let’s assume that it could for the exercise.) >>> >>> What are our options for finding the right User entity at login time? >>> >>> 1. We can jump in and naively use a CaseInsensitiveLike qualifier, but then >>> a user can stick ‘?’ and ‘*’ wildcards in the input. We could strip those >>> out, but they’re actually both valid characters in the local part. I >>> stopped short of trying to escape them, as this route is starting to seem a >>> little dangerous. >>> >>> 2. We could track both the supplied and a lower-cased version of the >>> identifier in separate attributes. This has the advantage of presumably >>> working, but it’s awkward, requiring special attention to changing the >>> normalised attribute when the user-supplied one changes. >>> >>> Can anyone suggest a better way? What I really need is a >>> CaseInsensitiveEquals qualifier, like Java’s equalsIgnoreCase(). Is there >>> such a thing? Would it be easily implemented? >>> >>> >>> -- >>> Paul Hoadley >>> http://logicsquad.net/ >>> >>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/lon.varscsak%40gmail.com >>> >>> This email sent to [email protected] >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list ([email protected]) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz >>> >>> This email sent to [email protected] >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com >> >> This email sent to [email protected] > <FrenchCaseInsensitive.coll1> _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
