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

[Fairlight]

Four score and seven years--eh, screw that!  At about Wed, Jul 21, 2004 at
02:18:38PM -0400, Brian K. White blabbed on about:
> That is why such things are handled with account numbers, invoice
> numbers, check numbers, etc... instead of by "account name" and "part
> description"

And you would expect Cingular to look up their rate plan details from a
rate plan by what common field (just by way of recent example)?

> 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

I wholly disagree.  I can't even enumerate the large number of "unique"
identifiers I've seen in -many- industries, which make use of letters.  Try
UPS shipping numbers, for an off-the-cuff example.

> 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 you're saying you should not only have to write the lookup, but then
force the lookup to do an explicit COMPARE inside a GETNEXT loop, and
disregard any that aren't matching sensitively?

Possible.  I wouldn't consider it desirable, though.

Aren't there cases though where say, you go into IUA and specify a
selection set, or just enter criterion in *clerk, and you wouldn't have
an opportunity to do this with code?  (I think I've used selection sets
-once-, so I'm asking.)  That's the kind of instance I'm thinking could be
disastrous--not automated lookups, which could be coded around as above.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html