Case insensitivity (was Re: browse keys (@bk))

[Brian K. White]

Fairlight wrote:
> On Wed, Jul 21, 2004 at 12:39:42AM -0400, Kenneth Brody may or may
> not have proven themselves an utter git by pronouncing:
>> "Jay R. Ashworth" wrote:
>> [...]
>>> Ok, *now* I'm just disgusted.
>>>
>>> WARNING, to anyone remaining who might expect sane behavior:
>>> indexes on * format fields are case insensitive, too.
>> [...]
>>
>> If "SMITH"="Smith", then I would certainly hope that they appear
>> together in indexes.
>
> <devils_advocate>
>
> Assume you had...I dunno, customer service plans for long distance,
> or any kind of service in any service industry.
>
> Say you had a system where they interface with some other system and
> -cannot- (at least easily, or -will- not, which is more likely)
> re-allocate the field lengths.  Say they made the field for their
> plans 4 digits long, and in the format:  ###A
>
> Now, you have 999 * 26 possible combinations there.  But assume that
> over time they actually run out of space for new plan types, but for
> recordkeeping purposes they can't actually remove old ones.
>
> If they can differentiate between 'A' and 'a', they just made their
> possible pool size 999 * 52.  Their other application may be able to
> handle it, but fP could not -if what I've seen presented, as well as
> how I interpreted it is correct-.  It would apparently not
> differentiate between '456M' and '456m'.  That could be Very Bad in a
> business transaction, especially if the difference in pricing is a

That is why such things are handled with account numbers, invoice numbers,
check numbers, etc...
instead of by "account name" and "part description"

You simply don't put letters in your unique identifier fields if at all
avoidable, and where not avoidable, don't expect case sensativity (as a
general rule, not just fp, like inventory model numbers, mac addresses &
other hex values, government form numbers, etc...) and finally, if there is
a case where a unique id field has letters and must be case sensative, like
your example which is certainly plausible, then that is simply a special
case and requires special pains. No biggy. You doctor up the fp app to make
the compares more exact. You don't make fP more cumbersome 99% of the time
so that it will be less cumbersome 1% of the time. This is not a data
integrity issue, it's an ease of use issue and as a consequence a end-user &
programmer efficiency and proficiency issue. Perfect integrity can be
programmed either way.

That efficiency and proficiency is thing is really all that seperates one
app from another these days. It is now _the_most_important_ factor since
almost any program and language these days will hit all the same basics and
be functional.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani