As I understood some text, that "thing" known as JDataStore let's you
define indexes with several different properties.
Declaring an attribute of this kind (case/nocase) in the field means the
field is fixed to this attribute. This may be desirable for some application
whereas for flexibility, it can turn into a nightmare. I prefer a set of
named indexes or new collation orders/drivers to handle the
upper/lower/nocase/accented issue. The behavior should be overridable on the
ORDER BY clause.
CASE and NOCASE are nice words but they seem to be used as the CASE-OF
Pascal statements. I would be better to have a peek at the SQL99 revision
(for the ones that are able to digest it) before using a word that's
reserved for other use. Contrarily to C++, where "&" and "*" may mean
several things, SQL reserved words seem to mean only one thing.
BTW, can I know why Interbase only allows a database-wide charset and not a
whole default collation order?

C.
---------
Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente
http://members.xoom.com/cvalde

> -----Original Message-----
> From: David Berg [mailto:DaveBerg@...]
> Sent: Miércoles 29 de Marzo de 2000 12:48
> To: IB-Architect@onelist.com
> Subject: RE: [IB-Architect] Syntax for case insensitive sort
>
>
> From: "David Berg" <DaveBerg@...>
>
> An alternative to declaring case insensitivity in the order by
> clause is to
> declare it as an attribute of the field. This has a number of advantages:
>
> (1) Indexes that include the field are case insensitive. This makes a BIG
> difference in performance when doing case insensitive sorts or queries.
>
> (2) Order by clauses are automatically case insensitive (and can use
> indexes).
>
> (3) Comparisons (<,>,=) are case insensitive (perhaps this should be an
> option).
>
> (4) Unique constraints are case insensitive. So I can't have "Interbase"
> and "INTERBASE" both in a unique index.