> I'm just slightly bothered by the fact that in all this discussion of hash indexes, I've yet to read any messages describing a
> real-world use-case where they're a better solution than the alternatives. Maybe I missed a message here or there covering
> that, but I'm still baffled as to why you'd want to send a big blob over the wire to the engine, so the engine can do a hash or
> CRC or whatever on it, decide it's a duplicate, and then do what? Raise a key violation and reject the insert? As Jim stated in
> a prior message, if you want to do something about the duplication, there will need to be code involved. So how does automating
> the creation of the hash simplify this?

The only time I have ever had a use for them was on OLTP databases where we used Hash Clustering.

> I'd much rather see the focus remain on the things marked "High" on the roadmap- Asynchronous statement cancellation,
> monitoring, in-database user management, temporary tables, SMP support, cross-database queries, etc. We (DRB Systems) are even
> willing to increase our sponsorship to help fund some of these things- all of which I can think of real-world use-cases for
> (that apply to our use of Firebird.)

1. Monitoring - being worked on.
2. in user databse management - Vulcan has it
3. Temporary tables - done - talk to Vlad :-)
4. SMP Support - Vulcan Merge

The others - well - I let others comment :-)

Paul