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
Description: Binary data
_______________________________________________ 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]
