>2. The ludicrous situation of having to create 'shadow' columns +
>BI/BU triggers in order to provide case-insensitive searches.

- Declaring fields where case is insignificant with a case
- insensitive collation should do the trick.
- It is isn't necessary to desirable to declare a whole database
- as case insensitive.

>Can we pleeeeaaaase have this option at database creation time also?

- Unlikely. Maybe a default collation, but declaring a whole
- database one way or the other strikes me as overkill.

No, it's not overkill; it's the opposite. It's:

1. Relatively _simple_ to implement (one would assume).
2. Found to be *profoundly missing by new users*.
3. Embraced by main competitors.
4. *Highly desired* by existing users.
5. Eradicates shadow column/trigger 'non-sense'. Hallelulyah.
6. 'Declaring fields where case is insignificant with a case
insensitive collation should do the trick.'
Column-by-column declarations? Yes, that's some 'trick' indeed.
We are not getting any younger - think of the extra typing alone!
What did McEnroe say '...You cannot be serious!"
This, IMO, is *not a real world perspective*.

- It is isn't necessary to desirable to declare a whole database
- as case insensitive.

Ohhhh yes it is. But I don't know enough to know if a default
collation is sufficient to satisfy the needs.

>3. Domains *used throughout entire system* would be great.

-- Could you elaborate?

That would be the ability to allow declared domains to be referenced
wherever a datatype is possible.
ie. sp prams + vars, trigger vars, checks, etc, etc.

>5. The ability to turn off the 'bitmapping' of multiple indexes.

- You've given us a prospective solution but left the problem
- unstated. Give us the problem. Maybe there's a better solution.

My (possibly flawed) understanding is that this is a mechanism where
multiple indexes are 'merged' (where possible) when deciding/executing
a query. Often it works to good and intended effect but occasionally
it results in inhibited performance.

Tom